Comments 24
Спасибо за ссылки, только вот… PHPDeveloper — это какой-то агрегатор, туда, как я понял, надо постить ссылки на уже опубликованные где-то статьи. На PHP Master не нашёл никаких кнопок не то что для публикации, но и для регистрации. Это вообще что за сайт? Как туда статьи попадают, кто их пишет?
Та да, нету англо-Хабра, нету :(

PhpDeveloper — ссылка на блогпост, апрувится модератором.
PhpMaster — полноценная статья, которая будет проходить через редакторов, а потом даже деньгу заплатят.
Hacker News — агрегатор типа digg, наставят плюсиков
Reddit — (забыл о нем), но тоже популярный агрегатор
DZone — то же…

Потому, скорее всего, стоит написать где-то блогпост (или сделать сайт на gh-pages) и запостить его во все эти агрегаторы.

Есть Examples.php, но там эпический говнокод, польза которого в изучении сомнительна, потому что там почти нет содержательных примеров.

Для конкретных примеров можно смотреть тесты. Там много бессмысленных с практической точки зрения примеров, но есть и адекватные. У меня были позывы написать тесты с содержательными примерами (как в статье пример с товарами и категориями), но позывы, по-моему, ограничились одним тестом meaningful для generate, в котором генерируются частичная сумма натуральных чисел и числа Фибоначчи.

По-хорошему, надо бы адаптировать вступительные статьи для LINQ из MSDN. Там хорошо написано, содержательно. Но на это нужно дофига времени, я и так получаю 0 руб. 0 коп. за все дни, проведённые за библиотекой, а кушать хочется. Х)

В общем, надо будет заняться нормальной справкой для тех, кто не использовал LINQ в .NET. Только позже.
Я слышал, что LINQ даже для C# не отличается особо высокой производительностью (мягко говоря). Автор, расскажите пожалуйста, проводили ли вы измерения скорости работы своей библиотеки и какие вы видите области применения для этого монстра в мире PHP :)?
На синтетических тестах вида foreach-if-list.add vs. from-where-select-tolist на массивах с целыми числами — да, можно говорить о том, что у LINQ в .NET производительность не ахти. Потому что в такой синтетике вычисляется не производительность, а количество вызовов функций (в идеале, конечно, функции должны инлайниться, как в том же C++, но на тот момент этого не происходило — не знаю, исправили ли). Но такие тесты ничего общего с действительностью не имеют. Заметить LINQ в профайлере можно, только если у вас обрабатываются массивы целых чисел с миллионами элементов. Как понимаете, в реальных приложениях такое встретить нереально.

Теперь о PHP. Да, скорость работы будет меньше. Насколько конкретно — лично мне по большей части пофиг. Я PHP выбирал не за скорость работы, а за скорость разработки. Если окажется, что я не могу использовать библиотеку, которая добавляет мне читаемость и выразительность кода, удобство разработки, из-за того, что там два лишних вызова функций на каждом получении элемента, то я лучше буду писать на другом языке.

Синтетические тесты по PHP я видел. foreach(array) vs. foreach(ArrayIterator) vs. foreach(MyArrayIterator). Разница между первым и последним — раз в пять. Всё, больше никогда не используем итераторы? :) И я ещё молчу про foo() vs. call_user_func_array('foo', array())…

В целом, библиотека для тех, кто хочет удобства. Если вы пишете малонагруженный сайт, но страдаете перфекционизмом по части скорости выполнения — библиотека не для вас. Если вы пишете высоконагруженный сайт и не можете себе позволить железо (я бы осудил в этом случае выбор PHP, но, что называется, ССЗБ) — библиотека не для вас.

Соответственно, библиотека для тех, кому важнее выразительность, читаемость, поддерживаемость кода, чем скорость его работы.
Это здорово, но было бы интересно знать, где проходит граница между читаемостью и тормозами.
Так что поддержу просьбу youROCK о тестировании производительности в разных кейсах и с разными способами передачи колбэков.
"($cat, $prods) ==> [...]"

Если уж значения перечисляются через запятую, то мы имеем явный кортеж. Может тогда уж и опустить скобки, как излишество? Ну или сделать их опциональными.

Поэтому, где есть конфликты, методы переименованы (в списке методов в начале статьи оригинальные имена методов даны в скобках). В частности, run/forEach стали call/each.

В Python-либах такая проблема решается добавлением _ в конец имени. Вполне симпатично смотрится. В вашем случае будет что-то вида: run_, call_. Даже запоминать не нужно, на что заменять надо.
Если уж значения перечисляются через запятую, то мы имеем явный кортеж. Может тогда уж и опустить скобки, как излишество? Ну или сделать их опциональными.

Эти скобки из C#. Мечта такая: «Надеюсь, однажды случится чудо, и кавычки можно будет убрать». :) Без кавычек и без скобок код будет неоднозначным.

А так — скобки опциональные. Можно хоть ')$a(==>$a' писать — там trim.

В Python-либах такая проблема решается добавлением _ в конец имени.

Несимпатично. В C#, например, можно использовать ключевые слова как идентификаторы, если поставить @ в начале. Но что-то я не особо замечал, чтобы кто-то хоть раз писал @if или for.

По-моему, библиотеки LINQ не обязаны иметь одинаковые идентификаторы во всех языках. В них достаточно различий даже без названий методов.
Без кавычек и без скобок код будет неоднозначным.

a, b = b, a
вполне себе однозначный

Несимпатично

Возможно, это вопрос привычки, но не вижу, чем вариант с obj.run_() менее симпатичен, чем @obj.run().
Да и редакторы общего назначения смогут правильно «подсветить» первый вариант, но не второй.
Имею в виду, что код

foo('($a, $b) ==> $a + $b')

после убирания кавычек и скобок (в предположении, что синтаксис вдруг стал поддерживаться :) ) становится

foo($a, $b ==> $a + $b)

что может быть интерпретировано и как вызов foo с лямбдой с двумя аргументами, и как вызов foo с аргументом $a и лямбдой.
B C# для Linq существует возможность работать не только с массивами, но другими источниками данных.
Причем существует возможность самому написать такие расширения.
Например, Linq for XML, Linq for NHibernate и т.д.

Планируется ли поддержка таких расширений?
UFO landed and left these words here
UFO landed and left these words here
И что вы предлагаете?

а) пользоваться замыканиями;

б) не пользоваться LINQ?
UFO landed and left these words here
Ну так пишите с помощью любимых замыканий, никто вас не заставляет пользоваться этим синтаксисом.
UFO landed and left these words here
А, вы так, позлорадствовать над похапэшниками пришли? :) Ну ладно, ладно.
UFO landed and left these words here
UFO landed and left these words here
У меня одного имплементации LINQ для не .NET языков вызывают ассоциацию с попыткой прилепить танковую пушку к хиппимобилю? Такими темпами скоро LINQ для фортрана увидим.
Only those users with full accounts are able to leave comments. Log in, please.