Метод, возвращающий весь объект

[miami]

Вот я и начал копать в гугле чтобы таких классов найти. Не стандартных, а юзерских, самописных. И что-то не нашёл. Один-два малюсеньких класса встретил где фигурирует return $this;

Есть ли возможность проверить код на ущербность? Я просто никогда тестов подобных не выделывал.

[miami]

Спасибо за наводку на Профайлинг, дальше по поводу этого я сам пошукаю ;)

Разрешите только чутка позадавать вопросов по «Если же подходить к программе с объектной точки зрения»…
А разве возвращаемая строка string «lol», или массив array(lol->rofl) не являются объектами? Или это только типы данных которые ничего общего с объектами не имеют :-/ Просто както раз мне случилось написать (случайно) $foo = new Array; и php кажись это скушал ;)

[point]

В PHP простые типы оттдельно, классы (объекты) отдельно. Возвращая строку «lol» ты возвращаешь именно строку.
Но есть фишки — можно преобразовать массив в объект и объект в строку.
А вообще, всё в мануалах написано :)

[point]

$foo = new Array;
такое не кушает, потому что array зарезервированное слово

[miami]

Не кушает… Наверное путаю с чем-то другим. Прошу прощения.

А массив в объект перегнать — было у меня два варианта функции: для рекурсивных массивов и обычных. А вот стандартных функций в мануале для этого не встретил.

[point]

$a = array('a'=>1,'b'=>2);$o = (object)$a; var_dump($o->a); var_dump($o->b);

[ashofthedream]

Посмотрите профайлер/дебаггер в Zend Studio Neon, у которого есть еще и плагинчек для ie и ff. Правда он платный (т.е. входит в комплект платной студии).

[cachealot]

посмотрите code igniter — кажеться видел у них как раз такую реализацию, и еще даже смотрел как она сделана, но сейчас уже боюсь не вспомню (

[Ins1ght]

> но по какой-то странной причине я не смог обнаружить в том же google подобных классов на PHP

да странно, ведь даже в Zend Framework есть такая техника

[point]

Советую посмотреть сюда:
codeutopia.net/blog/2008/01/21/pooquery-the-fluent-php-revolution/

[miami]

О, так это называется fluent programming style… :-]

[point]

Ага. Неуспел добавить, что гуглить в сторону fluent interfaces

[miami]

Спасибо большое

[miami]

pooQuery прикольная штука, но по-моему сложнее понять что делает

take('Hello World')->and->call('substr')->with(array(it(), 0, 5))
->and->take(call()->result)->and->display();

Куда яснее олд-скул ;)

$variable = 'Hello World';
$variable = substr($variable, 0, 5);
echo $variable;

[point]

Не стоит на нее смотреть как на серьезную production библиотеку. Скорее как на забаву, развлечение. К тому же, она наглядно показывает, как работают fluent interfaces. И можно в код поглядеть, возможно какие-то мысли пригодятся при разработке asList :)

[miami]

Пожалуй да ;)

[tenshi]

на строки всё-таки нужно разделять. такая техника всего-лишь позволяет сохранять контекст вызова без утомительного повторения имени переменной.
а написать в одну строку можно и без возвращения $this $-)

[miami]

Если вы про pooQuery, то это больше похоже на шутку. Запись более человекочитабельным образом.
Строчка кода может улыбнуть, но не оптимизировать — это точно =) Зато на классе pooQuery можно поучиться работе с fluent interfaces и созданию таковых.

[ashofthedream]

И только ради одной строчки в конце метода return $this, вы написали столько текста?

[miami]

Не только. Ещё для того чтобы одинаково просто было работать с массивом в качестве параметра, как и со стрингами )

[IntenT]

Если кодирование — самоцель, или «недостаточная производительность — это проблема железа», то конечно, можно и не такое накодить.

[miami]

Я решил так сделать потому, что точно знаю — одной операцией со списком я не обойдусь. Обычно требуется две-три операции сразу. На этом объекте построена большая часть моей программы а предмет операций бывает string, или array. Один мультифункциональный объектик получился ;)

А кодирование-самоцель — это как? Могу понять это только как «пишу скетчи, просто так, для себя». Нет, моя цель работа со списками и использование его в своей программе. Да, добавилась новая фичка — fluent interface. Приятно внедрить что-то новое, обсудить это со Знающими людьми и начать использовать его со спокойной душой. В принципе особых «против» я в обсуждении не увидел, значит в моём проекте может жить.

Огромное всем спасибо за поддержку и за конструктивную критику ещё большее спасибо.

[tvv]

Мое мнение — от такого подхода падает наглядность кода. Больше приходится в голове прокручивать, чтобы понять, что в коде происходит. Например у меня была бы постоянная путаница что возвращает метод — то ли этот же самый объект, или другой объект этого же класса, или вообще что-то другое. Хотя, возможно, это дело привычки…

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

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

[miami]

Хотя, возможно, это дело привычки…

Это дело IDE. Пользуясь например Zend Studio не возникает таких вопросов, ведь он из комментариев к коду узнаёт о входных и выходных параметрах, их типов и значении. Выдаёт все возможные варианты прямо при написании кода. Другими средствами я ещё не пользовался, поэтому больше ничего посоветовать не могу.

[sovnarkom]

method chaining, если я не ошибаюсь стал доступен только в PHP 5, ну и, как всегда… для сохранения проклятой обратной совместимости многие отказываются от этого…

Лично я — не большой фанат такого подхода, так как обычно возвращаемое значение часто нужно сначала проверять как на существование, так и на некоторые состояния… это не касается вашего примера и такой конвейер не вызывает негативных эмоций, хотя я и не вникал в его суть.

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

[miami]

Я вроде тоже не фанат method chaining, или как тут прозвучала версия — fluent interfaces, но приглянулось использовать вот для такой одной цели. Пока что других не было.

В Zend Studio есть один минус. Он не определяет переменных, в которых не совсем можно понять — что за класс там создан. К примеру после записи

$tags = (isset($_SESSION [PROJECT] ['tags'])) ? new Tags($_SESSION [PROJECT] ['tags']) : new Tags ("default");

или даже:

$tags = (true) ? new Tags( ) : new Tags ( );

Для $tags-> зенд не выведет подсказок. В общем да, наверное от IDE хочеться ещё большего, чтобы программу само писало лишь мозгом управляемо :))