Здравствуйте, neFormal, Вы писали:
F>и какие же?.

Есть такое ощущение — чтобы добавление к концу строки фразы в духе 'or report_error_and_exit()' не требовало никаких дополнительных действий.

Собсно вот: http://eli.thegreenplace.net/2007/06/02/logical-operators-in-perl-and-ruby/

Здравствуйте, neFormal, Вы писали:

M>>>>Да-да-да. Несмотря на то, что and и && — это одно и то же, и or и || — это одно и то же, у них разные приоритеты
DOO>>>Вообще-то это заимствовано из перла
Г>>...и повторяется в Руби. Есть основания, кагбэ.

F>и какие же?.

По-бытовому говоря, &&, ||, ! обеспечивают логическую арифметику, а and, or, not — структурирование кода.

Например:

if(cond1 || cond2 && cond3 && !cond4) #первый вариант

if(x = test1() and y = test2()) #второй вариант

Здравствуйте, neFormal, Вы писали:

F>Собственно, сабж..

Переменные регистро-зависимые, а функции и ключевые слова нет:

// php 5.2.6

$test = 3;
$TEST = 5;

var_dump( $test ); // 3
VAR_DUMP( $TEST ); // 5
VAR_dump( $Test ); // NULL

ExIt;

function hello()
{
    print 'hello';
}

function Hello()
{
    print 'hello';
}
// PHP Fatal error:  Cannot redeclare hello()

Я буду говорить о PHP-не как о языке, а как о платформе.

Отсутствие строгой типизациии приводит к жутким граблям:

1.
function multiply($x) 
{
     $result = $x * $y;
     // Здесь программист забыл вернуть результат из функции!
     // Главное, что никаких warning'ов, а там и до пятницы недалеко.    
}

2.
class MyClass
{
    var $x;
    public function myMethod($a) {
            
        $x = $a; // Упс, здесь надо было написать $this->x = $a, но мы забыли про $this - ерунда  
                 // транслятор молчит значит усё в порядке!                
    }
}

3.
function sum($integer1, $integer2) 
{    
     return (int)$integer + (int)$integer2;
}

$sum =  sum(1, array(1, 2, 3)); // Cколько будет целое плюс массив? Транслятору пофиг. 
                                // Примечание: приводим тип потому что не доверяем входным данным от пользователя.

4.
function doSomething($x, $y, $z) // Какого типа $x, $y, $z? Угадай сам! 
{
     
}

5.
function makeMeHapy() // Эта функция должна была называться makeMeHappy. Ошибка обнаружится в багрепорте на следующее утро.
{
     
}

6.
function putToDatabase($integer) 
{
     //Для того чтобы избежать sql-injection это  надо постоянно кастить к ожидаемому типу
     //Где же пресловутая краткость динамических языков?
     return mysql_query("SELECT * FROM MyTable WHERE Id = " . (int)$integer);
}

Достает, что использование $this-> обязательно — из-за этого трудно делать некоторые рефакторинги.

Нет перегрузки операторов.

Нет перегрузки методов.

Убогие по современным меркам IDE.

Более 40(!) фреймворков, большинство из которых не имеет ни документации ни поддержки и сделаны на коленке. Вот уж где понимаешь разницу между количеством и качеством.

Коммуния состоит из программистов низкого уровня. Я не фашист и верю в то, что где-то есть хорошие PHP-программисты, и я верю в инопланетян, но просто ни разу не встречал ни тех ни других.

В России PHP-коммуния довольно-таки хамская (я имею ввиду один популярный PHP-ресурс).

Поддержка Unicode появится только в версси 6 (в Java это было в 1995 году.)

Отсутствие неймспейсов явно не способствовало развитию грамотной экосистемы.

Раздрай в соглашениях: в PHP используется старый перловсий стиль с подчеркиваниями, а в PEAR — camel case.

Вот что успел вспомнить.

Entropy wrote:

> Отсутствие строгой типизациии приводит к жутким граблям:
Это вообще тут не причём. Это прелести динамического программирования. Во всех динамических языках будут те же проблемы. Это дело решается юнит-тестами.
Кстати, с компилируемыми языками нередко возникают подобные проблемы, особенно в web-программировании. Всё равно не всё можно проверить компилятором. Всегда остаётся HTML, SQL и прочие нетипизируемые штуки.

> return mysql_query("SELECT * FROM MyTable WHERE Id = " . (int)$integer);
А так писать нельзя. Нужно писать: query("SELECT * FROM MyTable WHERE Id = ?").bind($integer).execute();
А вот недостаток PHP можно упомянуть лишь то, что он поощряет такой стиль и во многих учебниках именно учат так писать, да ещё отстутствует нормальный фреймворк для работы с субд, да ещё и автоматическое квотирование запроса символом "\".

Здравствуйте, ., Вы писали:

.>Entropy wrote:

>> Отсутствие строгой типизациии приводит к жутким граблям:
.>Это вообще тут не причём. Это прелести динамического программирования.

Это не динамическое программирование это dynamic typing или, как это называют в PHP, type jungling. Именно об этом (об отсутствии строгой типизациии) я и говорю.

>>> Во всех динамических языках будут те же проблемы.
Вот поэтому я терпеть не могу динамическую типизацию, в том числе в PHP.

>>> Это дело решается юнит-тестами.
Ни черта это не решается юнит-тестами. Это только в сказках так. Во-первых в реальной жизни не так много PHP-программеров пользующихся юнит тестами. Вы видели плагины у Wordpress, многo среди них протестировано? Во-вторых, может попасться (я сказал "может попасться"? я имел ввиду "100% попадется") стороння библиотека без юнит-тестов, которую надо поддерживать. Или вам дадут стрый движок портала, разрабатываемый с 2001 года на PHP 4, программистами, которые давно уволились. Вы думаете мне легче от того, что "Во всех динамических языках будут те же проблемы", когда их можно было просто избежать? Реальный мир жесток.


.>>>Кстати, с компилируемыми языками нередко возникают подобные проблемы, особенно в web-программировании. Всё равно не всё можно проверить компилятором.
Нет уж, пардоньте, ошибиться в названии метода никак нельзя. Не все, но многое проверяется. Я уже не говорю о нормальном авторефаторинге, которого у динамически-типизируемых языков никогда не будет (тока не говорите про комментарии-подсказки — на это надеяться не стоит).

>>> Всегда остаётся HTML, SQL и прочие нетипизируемые штуки.
Это правда, на стыке языков всегда проблемы. Вы HTML-вывод тоже юнит-тестируете? Позвольте не поверить.

>> return mysql_query("SELECT * FROM MyTable WHERE Id = " . (int)$integer);
.>А так писать нельзя. Нужно писать: query("SELECT * FROM MyTable WHERE Id = ?").bind($integer).execute();
И как мне это поможет? Инъекции не будет? Ну да, но это никак не запретит мне передать неверный тип данных в метод bind и никто ничего не заметит. Юнит-тесты? Да их ведь тоже надо отлаживать, как ни странно, и, в случае пойманной тестом ошибки, придется дольше бегать по коду, пытаясь отыскать место ее возникновения.

Да, вот еще вспомнил: нет перечислений.

Здравствуйте, ., Вы писали:
>> Отсутствие строгой типизациии приводит к жутким граблям:
.>Это вообще тут не причём. Это прелести динамического программирования. Во всех динамических языках будут те же проблемы. Это дело решается юнит-тестами.

То, о чем Вы и Ваш собеседник говорите, совершенно ортогонально динамической/статической типизации. Правила, не позволяющие лишний раз прострелить себе ногу не обязательно связаны с типами. Просто в php нет ни того, ни другого.

function multiply($x) 
{
     $result = $x * $y;
     // Здесь программист забыл вернуть результат из функции!
     // Главное, что никаких warning'ов, а там и до пятницы недалеко.    
}

Невозможно в scheme. Поскольку, грубо говоря все, что не биндит переменные — выражение, "забыть вернуть" что-то нельзя.

class MyClass
{
    var $x;
    public function myMethod($a) {
            
        $x = $a; // Упс, здесь надо было написать $this->x = $a, но мы забыли про $this - ерунда  
                 // транслятор молчит значит усё в порядке!                
    }
}

Практически невозможно в scheme. Нечаянно прибиндить что-то "не туда" можно разве что с помощью макроса, да и то сложно.

function sum($integer1, $integer2) 
{    
     return (int)$integer + (int)$integer2;
}

$sum =  sum(1, array(1, 2, 3)); // Cколько будет целое плюс массив? Транслятору пофиг. 
                                // Примечание: приводим тип потому что не доверяем входным данным от пользователя.

В scheme подобная ситуация выльется в эксепшн в рантайме (т.е. соответствующий тест будет зафейлен).

function doSomething($x, $y, $z) // Какого типа $x, $y, $z? Угадай сам! 
{
     
}

Вообще, при объявлении функций их стоит аннотировать типами аргументов. Очень полезная практика.

function makeMeHapy() // Эта функция должна была называться makeMeHappy. Ошибка обнаружится в багрепорте на следующее утро.
{
     
}

В scheme в принципе возможно, но компиляторы выдают варнинги, поскольку вероятность внезапного появления биндинга в лексической области видимости в рантайме — на уровне статистической погрешности.

Entropy wrote:

>> > Отсутствие строгой типизациии приводит к жутким граблям:
> .>Это вообще тут не причём. Это прелести динамического программирования.
> Это не динамическое программирование это dynamic typing или, как это
> называют в PHP, type jungling. Именно об этом (об отсутствии строгой
> типизациии) я и говорю.
Ну да, я это и имел в виду. А таких языков куча, яваскрипт, питон, руби, перл... И даже в С/С++ это вылазит в неком виде.

>> >> Во всех динамических языках будут те же проблемы.
> Вот поэтому я терпеть не могу динамическую типизацию, в том числе в PHP.
Дело вкуса. С другой стороны есть приятные моменты — необходимость компиляции отстутствует.

>> >> Это дело решается юнит-тестами.
> Ни черта это не решается юнит-тестами. Это только в сказках так.
> Во-первых в реальной жизни не так много PHP-программеров пользующихся
> юнит тестами.
В реальной жизни вообще мало квалифицированных программеров.
Просто отсутсвие хороших юнит-тестов сказывается на качестве кода сильнее, чем "неправильный" язык.

> Вы видели плагины у Wordpress, многo среди них протестировано? Во-вторых, может попасться (я сказал "может попасться"?
> я имел ввиду "100% попадется") стороння библиотека без юнит-тестов,
> которую надо поддерживать. Или вам дадут стрый движок портала,
> разрабатываемый с 2001 года на PHP 4, программистами, которые давно
> уволились. Вы думаете мне легче от того, что "Во всех динамических
> языках будут те же проблемы", когда их можно было просто избежать?
> Реальный мир жесток.
А если вам дадут движок портала, разрабатываемый с 2001 на С#? Или не дай боже на С? Точно будет легче?

> .>>>Кстати, с компилируемыми языками нередко возникают подобные
> проблемы, особенно в web-программировании. Всё равно не всё можно
> проверить компилятором.
> Нет уж, пардоньте, ошибиться в названии метода никак нельзя. Не все, но
> многое проверяется. Я уже не говорю о нормальном авторефаторинге,
> которого у динамически-типизируемых языков никогда не будет (тока не
> говорите про комментарии-подсказки — на это надеяться не стоит).
Ну да, с авторефакторингом проблемы. Хотя, насколько я знаю, нормальный рефакторинг есть только в яве, да в шарпе более менее.

>> >> Всегда остаётся HTML, SQL и прочие нетипизируемые штуки.
> Это правда, на стыке языков всегда проблемы. Вы HTML-вывод тоже
> юнит-тестируете? Позвольте не поверить.
Честно говоря, не пришлось. Но надеюсь займусь в ближайшем будущем, нет в этом ничего невозможного.
А вообще говоря, каждый уважающий себя фреймворк это должен позволять. Скажем, wicket.

>> > return mysql_query("SELECT * FROM MyTable WHERE Id = " . (int)$integer);
> .>А так писать нельзя. Нужно писать: query("SELECT * FROM MyTable WHERE
> Id = ?").bind($integer).execute();
> И как мне это поможет? Инъекции не будет? Ну да, но это никак не
> запретит мне передать неверный тип данных в метод bind и никто ничего не
> заметит. Юнит-тесты? Да их ведь тоже надо отлаживать, как ни странно, и,
> в случае пойманной тестом ошибки, придется дольше бегать по коду,
> пытаясь отыскать место ее возникновения.
Так ты же сказал, что оно из html-запроса приходит. Где-то да придётся эту проверку вставить. И в случае php никто тебя не заставляет проверять уже в уровне dao — проверь при разборе входных параметров.

> Да, вот еще вспомнил: нет перечислений.
мелочи жизни.

Mr.Cat wrote:

> Во всех динамических языках будут те же проблемы. Это дело решается
> юнит-тестами.
> То, о чем Вы и Ваш собеседник говорите, совершенно ортогонально
> динамической/статической типизации. Правила, не позволяющие лишний раз
> прострелить себе ногу не обязательно связаны с типами. Просто в php нет
> ни того, ни другого.
Да просто прострелить ногу можно из всего. Не типы, так их приведение, не приведение, так downcasting...
Поэтому рассчитывать на то, что раз скомпилилось, значит работает, лучше не стоит. А важнее покрыть всё тестами.

> Невозможно в scheme. Поскольку, грубо говоря все, что не биндит
> переменные — выражение,
Да там всё выражение. Или я что-то не помню?
Биндинг переменной может быть последним элеметом, но шанс такого имхо такой же, как и забыть "return".

>"забыть вернуть" что-то нельзя.
Зато можно вернуть не то.

> Практически невозможно в scheme. Нечаянно прибиндить что-то "не туда"
> можно разве что с помощью макроса, да и то сложно.
Просто язык требует объявления переменных. Вот это да, имхо важно. Хотя, скажем, в питоне не так, но это ему не мешает быть "хорошим" языком.

> В scheme подобная ситуация выльется в эксепшн в рантайме (т.е.
> соответствующий тест будет зафейлен).
Просто в языке нет автоматического приведения типов. Но я не уверен, что это всегда и везде правильная стратегия.

> В scheme в принципе возможно, но компиляторы выдают варнинги, поскольку
> вероятность внезапного появления биндинга в лексической области
> видимости в рантайме — на уровне статистической погрешности.
А '?

Здравствуйте, ., Вы писали:
.>Биндинг переменной может быть последним элеметом, но шанс такого имхо такой же, как и забыть "return".
Наверное, все-таки меньше. Вроде не все реализации это позволяют (mzscheme ругается, что нет выражения, chicken пропускает).

>>"забыть вернуть" что-то нельзя.
.>Зато можно вернуть не то.
Увы. Вот тут уже пошли недостатки динамической типизации.

.>Просто язык требует объявления переменных. Вот это да, имхо важно. Хотя, скажем, в питоне не так, но это ему не мешает быть "хорошим" языком.
Ну, я уже слышал критику в адрес питона по этому поводу. Хотя в питоне-то еще ничего. Настоящая жесть с областями видимости — в матлабе.

.>А '?
Да, я че-то какой-то набор слов написал. Я имел в виду, что благодаря лексической области видимости, факт того, что переменная в рантайме будет не определена, можно выявить в компайл-тайм.

MC>То, о чем Вы и Ваш собеседник говорите, совершенно ортогонально динамической/статической типизации. Правила, не позволяющие лишний раз прострелить себе ногу не обязательно связаны с типами. Просто в php нет ни того, ни другого.
Ладно, согласен, правильнее было бы написать не "отсутствие строгой типизации", а "причуды PHP".

>>> Отсутствие строгой типизациии приводит к жутким граблям:
.>>Это вообще тут не причём. Это прелести динамического программирования.

E>Это не динамическое программирование это dynamic typing или, как это называют в PHP, type jungling. Именно об этом (об отсутствии строгой типизациии) я и говорю.

Не надо путать динамическую типизацию со слабой, а статическую — о строгой. РНР — динамически типизируемый язык со слабой типизацией.


>>>> Во всех динамических языках будут те же проблемы.
E>Вот поэтому я терпеть не могу динамическую типизацию, в том числе в PHP.

Erlang вон тоже динамически типизируем, но такие же "фишки" в нем не пройдут, потому что он строго типизирован

И вообще:

                      ^ (строгая тип.)
                      |
      Erlang          |    
                      |  
                      |    Java, C#, Haskell
                      |
                      |
----------------------------------------------------->
(динам. тип.)         |               (статич. тип.)
                      |
                      |     
    Javascript        |
                      |         C/C++
    PHP               |
                      |
                      | (слабая тип.)

Левый нижний квадрант — это худшая комбинация

Здравствуйте, Mr.Cat, Вы писали:

MC>Вообще, при объявлении функций их стоит аннотировать типами аргументов. Очень полезная практика.
Эта практика была бы полезной, если бы комилятор насильно заставлял аннотировать типы аргументов. Это все равно что сказать: "Воообще детям полезно ходить в школу. Очень полезная практика." В рельной жизни в школу ходят только из-под палки. В PHP уже есть type hinting, когда можно явно указывать типы, но во-первых он не обязательный, во-вторых он не действует на примитивные типы. Вместо того, чтобы опускать тип аргумента, я думаю, лучше было бы вводить ключевое слово-тип, например, dynaimc.

function myFunc(int x, MyClass y, dynamic z)
{
}

Здравствуйте, Entropy, Вы писали:

E>Я буду говорить о PHP-не как о языке, а как о платформе.
E>Отсутствие строгой типизациии приводит к жутким граблям:

Как уже сказали, это проблемы не конкретно отсутствия строгой типизации, а реализации системы типов PHP в целом.

E>Убогие по современным меркам IDE.

Для Eclipse есть PDT из которой выросла Zend Studio, в Netbeans также есть расширение для PHP, для Visual Studio есть VS.PHP. Чего еще не хватает-то?

E>Более 40(!) фреймворков, большинство из которых не имеет ни документации ни поддержки и сделаны на коленке. Вот уж где понимаешь разницу между количеством и качеством.

На хабре вон, Yii хвалят, вроде достаточно добротный и документированный FW. Zend документирован по самые уши + куча сторонних статей в т.ч. от серьезных дядей (например цикл туториалов на ibm.com)

E>Коммуния состоит из программистов низкого уровня. Я не фашист и верю в то, что где-то есть хорошие PHP-программисты, и я верю в инопланетян, но просто ни разу не встречал ни тех ни других.

Хороших PHP-программистов мало, потому как по мере своего профроста они уходят либо на Python, либо на Ruby, либо вообще в .NET

Здравствуйте, Entropy, Вы писали:

E>Я буду говорить о PHP-не как о языке, а как о платформе.

И раз уж мы заговорили о платформе, то качество кода в исполнении php-group оставляет желать лучшего, а выпуск патчей и реагирование на сообщения об обнаруженных уязвимостях, вообще "радует". Например, на сегодняший день:

1. Под виндой, дергая методы COM-объектов можно обойти ограничения safe-mode. Патч отсутствует.
2. Переполнения буфера и повреждения памяти в tidy_parse_string(), snmpget(), msql_connect(), win_browse_file(), в нескольких ntuser_*(), str_replace(), iptcembed(), mssql_connect() и iis_getservicestate(). Патчи отсутствуют.
3. race condition в crypt(), что делает небезопасным ее использование в многопоточной среде. Закрыта лишь частично.
4. DOS в gdPngReadData(). Закрыта лишь частично.
5. Повышение привилегий в ibase_connect(). Патч отсутствует.

Это при том, что некоторым из перечисленных уязвимостей уже больше года

А о культуре безопасного кода на PHP я вообще молчу, она просто отсутствует, как таковая. Яркий пример (чтоб далеко не ходить):

.>А так писать нельзя. Нужно писать: query("SELECT * FROM MyTable WHERE Id = ?").bind($integer).execute();
И как мне это поможет? Инъекции не будет? Ну да, но это никак не запретит мне передать неверный тип данных в метод bind и никто ничего не заметит.

Вот это натянутое "ну да", вкупе с продемонстрированным стремлением использовать конкатенацию строк в SQL-запросах очень настораживает, но не удивляет, поскольку в PHP-среде, дай бог чтобы 3 из 10 разработчиков вообще беспокоили подобные "мелочи"

KV>Для Eclipse есть PDT из которой выросла Zend Studio, в Netbeans также есть расширение для PHP, для Visual Studio есть VS.PHP. Чего еще не хватает-то?

Надо чтоб как у Resharper было, плюс визуальное редактирование собственных компонентов. А болокнотом с подсветкой, дебаггером и единственным рефакторингом типа "Rename" сейчас никого не удивишь.

KV>На хабре вон, Yii хвалят, вроде достаточно добротный и документированный FW. Zend документирован по самые уши + куча сторонних статей в т.ч. от серьезных дядей (например цикл туториалов на ibm.com)

Вот именно, что этиx фрейморков, которыx хвалят, до фига и больше, при этом неизвестно, кто из них будет перспективным, а кто завтра загнется. Я видел немало подающих надежды перспективных проектов, которые сейчас пылятся на Sourceforge. Плюс они плохо (если вообще) совместимы друг другом.

Но главное, в PHP нет компонентного программирования. Типа Java Beаns — нет универсальной спецификации, чтобы можно было сделать визуальные редакторы. Все компоненты заточены только под свой собственный фреймворк/CMS. При таком их количестве не представляется возможным хоть как-то стандартизировать создание визуальных компонентов (я не имею ввиду редактирование шаблонов — а ля Dreamweaver). В ASP.NET или Java есть мейнстрим, в PHP — кто в лес, по дрова.

Здравствуйте, Entropy, Вы писали:

KV>>Для Eclipse есть PDT из которой выросла Zend Studio, в Netbeans также есть расширение для PHP, для Visual Studio есть VS.PHP. Чего еще не хватает-то?

E>Надо чтоб как у Resharper было, плюс визуальное редактирование собственных компонентов.

Я правильно понимаю, что в контексте PHP под "собственным компонентом" здесь подразумеваются html-шаблоны? Да упаси боже, в wysiwyg что-то верстать И тем не менее, как минимум в Zend это есть.

E>А болокнотом с подсветкой, дебаггером и единственным рефакторингом типа "Rename" сейчас никого не удивишь.

Это Visual Studio блокнот с подсветкой?

KV>>На хабре вон, Yii хвалят, вроде достаточно добротный и документированный FW. Zend документирован по самые уши + куча сторонних статей в т.ч. от серьезных дядей (например цикл туториалов на ibm.com)

E>Вот именно, что этиx фрейморков, которыx хвалят, до фига и больше, при этом неизвестно, кто из них будет перспективным, а кто завтра загнется. Я видел немало подающих надежды перспективных проектов, которые сейчас пылятся на Sourceforge. Плюс они плохо (если вообще) совместимы друг другом.

Ну если выделенное, то тогда zend fw. Он загнется только если вместе с PHP.

E>Но главное, в PHP нет компонентного программирования. Типа Java Beаns — нет универсальной спецификации, чтобы можно было сделать визуальные редакторы. Все компоненты заточены только под свой собственный фреймворк/CMS. При таком их количестве не представляется возможным хоть как-то стандартизировать создание визуальных компонентов (я не имею ввиду редактирование шаблонов — а ля Dreamweaver). В ASP.NET или Java есть мейнстрим, в PHP — кто в лес, по дрова.

А что в чистом PHP помимо выделенного еще может быть / должно быть "визуальным компонентом"?

Здравствуйте, Курилка, Вы писали:

К>Из недавнего — microtime

Позвольте заметить несостоятельность примера

1. по данному URL написано "microtime() возвращает структуру, а число возвращает microtime(true)"
что не есть верно, т.к. microtime() возвращает не структуру, а строку соответственно от этой "неточности" и дальнешнее следствие.

2. из-за не раз упомянутой выше слабой динамической типизации PHP — Вы можете вычитать и строки, но
согласно правилам привидения типов (или как еще назвать операции подобные) в PHP, перед вычитанием вышеупомянутых строк они будут приведены к числам, соответственно ничего необычного и неправильного в упомянутом примере нет.
Все логично, первая строка преобразуется из (string)"0.20532600 1228884374" в (float)0.20532600 и вторая соответственно, посему при вычитании и получаем такой результат.


P.S.: это "замечание" не претендует на истину а лишь является моим мнением на основе известных мне фактов.

Здравствуйте, bGust, Вы писали:

G>Здравствуйте, Курилка, Вы писали:

К>>Из недавнего — microtime

G>Позвольте заметить несостоятельность примера

G>1. по данному URL написано "microtime() возвращает структуру, а число возвращает microtime(true)"
G>что не есть верно, т.к. microtime() возвращает не структуру, а строку соответственно от этой "неточности" и дальнешнее следствие.

Суть в нарушении Principle of least astonishment, строка там или структура — это непринципиально с этой точки зрения, принципиально продемонстрированное неправильное понимание работы функции (а за правильным надо или лезть каждый раз в доки, или "зубрить").
Ты же "докапываешься" до не совсем точных деталей, выкинув из рассмотрения "слона", так что замечание считаю несостоятельным