да, нас всех тоже интересует. слушаем.

Да вроде сейчас во всех фреймворках это можно встретить

Да вот везде встречается, только вот интересует мнение насколько это оптимально в плане ресурсов и скорости?

мне кажется что текучий интерфейс - это малость зло. пример в jQ (простой, только для примера)

$(el).css({width:100}).animate({height:120}); //сработает
a = $('#cmonitor').css('width').css({height:120}); //несработает
a = $('#cmonitor').css({height:120}).css('width'); //сработает

смысл в том, что не имея перед глазами список возможных возвращаемых результатов каждого метода класса, использование "текучки" превращается в танцы с бубном. в моем примере все просто и очевидно, понятно, что .css('width') надо поставить в конец очереди, но это только для примера, а если более сложные конструкции? вот и гадай, возвращает метод объект или нет?

да и "визуальная наглядность" довольно сомнительна. в длинных цепочках глаза разбегаются при анализе звеньев и их параметров.

чем хуже запись?

el = $(id);
el.css({width:100});
el.animate({height:120}); 
a = el.css('width');
el.css({height:120});

да ничем.

кто недоумевает как вообще это реализуется, достаточно просто показаны примеры тут: http://ru.wikipedia.org/wiki/Fluent_interface

Разницы, нет может в 5 классах, а при использование тысячи классов, возможно уже будет конкретная разница в скорости, ну не может быть, что дело только в подходе написания, конечно может самому какие тесты прогнать, но всё таки интересует кто сталкивался? Проще конечно без текучки быстрее читается, код лично для меня.

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

как по мне это просто разновидность говнокода поскольку абсолютно нечитаем.
по мере вызова цепочки может изменится объект вызова и человек который
то будет читать уже не поймет это функции изначального объекта или уже другой начался.

В примере: второй .css это какого объекта? первоначального или второй .css вернул какой то новый объект. И с какой стати css вообще возвразает какой то объект. Запдача данной функции установить свойство а не найти и вернуть данные, максимум что она может возвращать это true/false

При нормальном кодировании должно быть два, максимум три вызова.

Если больше надо делать промежуточные переменные. Компилятору все равно - он сгерерит одинаковый код на выходе, но такой код можно будет хотя бы прочитать и человеку не надо помнить что возвращает каждая функция
(особенно если переменным давать более вразумительные имена чем а).

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

по сути в памяти уже есть данный экземпляр и он уже не порождает новые, он только возвращает сам себя.
Все фрамефорки в нынешнее время написано по методу тогда этого же "гавнокода", если я не ошибаюсь, то даже Зенд фраемворк имеет такой же подход.
Каждый кодит так как он хочет, фломастеры у всех разные и разного вкуса. Только вот оптимально ли это в ресурсах и скорости, вот в чём вопрос? Стиль одно, ресурсы другое, можно кодить просто, только вот наплодить пачку переменых и в итоге память и скорость будет хромать, а можно обойтись несколькими переменными и будет скорость и ресурсоёмкость в порядке.

Не будет там проблем со скоросью и ресурсами. Железо гораздо дешевле стоимости программиста. Поэтому надо писать код нормально чтбы его можно было нормально читать и сопровождать.
И не надо кивать на другие фреймворки. Сайт на PHP весом в мегабайты исходников - маразм уже само по себе независимо от стиля кодирования.

Знаю некоторые фраемворки весом по 70 мегов в сопровождение цмс. Да код надо что бы был очень читабельный, а то потом будет печалька, в плане его поддерживания.

короче разница в скорости и в пожерании ресурсов на столько не значительная, что об этом не стоит даже говорить. Дополнительное "return $ths;" в set-Методах практически не пожерает ресурсов так как в php5 передается только ссылка на объект.

ОТ:
Я персонально не считаю Fluent плохим стилем и нахожу его довольно приятным при чтени и написании кода. Так же не могу припомнить, чтоб мои колеги по этому поводу возмущались. Единственное это чтоб seter были структурно отделены от geter методов.
типа:

 //set propertys
 $var ->setA('blja')
        ->setB('blum')
        ->setC(6);

a вот так, лучше не надо, так как тяжело визуально отделить сет методы от гет методов:

echo $var ->setA('blja')
              ->setB('blum')
              ->setC(6)
              ->getHTML();

Если к стате посмотреть на пример приведенный redreem сразу видна эта прооблема

 a = $('#cmonitor').css('width').css({height:120}); //несработает
a = $('#cmonitor').css({height:120}).css('width'); //сработает

просто из удобства Jquery разрешило разнообразные типы ретурна и к томуже использует метод css как set и get, что и приводит к тому что в css('width') работающему как get выдается число, а в css({height:120}) работающему как set по принципу Fluent выдается this.

SlavaFr

А что, других методов не бывает кроме set и get ? Ну например что нибудь типа реализации собственно бизне-слогики.
В любом случае интерфейс не читабелен и противоречит грамотному стилю програмирования - с какого перепугу сеттеры вообще что то должны возвращать? ихнее предназначение установить свойство а не возвращать чего то.

Почему текучка это гавнокод, вообще не понимаю? Есть стиль програмирование, текучка например хорошо при создание кучи полей из шаблонизатора, и моментами это экономия ресурсов.

SlavaFr
То что индусов до фига програмистов и они участвуют в проектах покруче дебильного Зенда не отменяет существования понятия "индусский код".