Comments 10
Как автор конкурента YaLinqo (статья на Хабре), должен заметить, что подход с построением лямбд любопытный, но совершенно нечитаемый. И это ещё лямбды простые… Теряется, как мне кажется, основное преимущество LINQ — повышение читаемости кода. Вместо добавления выразительности изобретается новый язык.
В своей реализации я забил на разбор выражений и, соответственно, на возможность прикручивания баз данных. Должен заметить, что построение нормальных SQL-запросов по выражению — это весьма хитрая задача, которую нужно решать долго и упорно. Я, решив, что моя кривая реализация ни кому не нужна при изобилии нормальных ORM'ов, пошёл по простому пути: «строковые лямбды», родные замыкания, родные «указатели» на функции (через строки и массивы).
Вообще, есть конкурирующие библиотеки с разбором выражений, но они, к сожалению, слишком неполноценны (см. сравнение в моей статье). Возможно, успели появиться ещё конкуренты, но я их не видел.
Мне тоже так хотелось сделать, но теория разбилась о практику (после попытки использовать одну из уже имеющихся библиотек): в PHP ключи в массивах нужны очень часто. Так как в дотнетовом LINQ у итераторов нет понятия ключей, то перенос интерфейса один-в-один слишком часто делает использование библиотеки невозможным.
Явное вынесение всех классов итераторов мне понравилось, потому что это в духе уже имеющегося в PHP функционала. Правда те редкие случаи, когда я использовал родные итераторы, убедили меня в том, что читаемость кода с ручным построением цепочек итераторов кошмарная.
P.S. Вы б нормальное уникальное имя библиотеке дали что ли. Название «linq_php» близко к именам уже существующих библиотек «LINQ for PHP» и «PHPLinq». Желательно избегать лишней путаницы.
В своей реализации я забил на разбор выражений и, соответственно, на возможность прикручивания баз данных. Должен заметить, что построение нормальных SQL-запросов по выражению — это весьма хитрая задача, которую нужно решать долго и упорно. Я, решив, что моя кривая реализация ни кому не нужна при изобилии нормальных ORM'ов, пошёл по простому пути: «строковые лямбды», родные замыкания, родные «указатели» на функции (через строки и массивы).
Вообще, есть конкурирующие библиотеки с разбором выражений, но они, к сожалению, слишком неполноценны (см. сравнение в моей статье). Возможно, успели появиться ещё конкуренты, но я их не видел.
сигнатура LINQ методов, идентичная C#
Мне тоже так хотелось сделать, но теория разбилась о практику (после попытки использовать одну из уже имеющихся библиотек): в PHP ключи в массивах нужны очень часто. Так как в дотнетовом LINQ у итераторов нет понятия ключей, то перенос интерфейса один-в-один слишком часто делает использование библиотеки невозможным.
Явное вынесение всех классов итераторов мне понравилось, потому что это в духе уже имеющегося в PHP функционала. Правда те редкие случаи, когда я использовал родные итераторы, убедили меня в том, что читаемость кода с ручным построением цепочек итераторов кошмарная.
P.S. Вы б нормальное уникальное имя библиотеке дали что ли. Название «linq_php» близко к именам уже существующих библиотек «LINQ for PHP» и «PHPLinq». Желательно избегать лишней путаницы.
Спасибо за комментарии. Конкуренция — это хорошо. На мой вкус предложенный способ для простых лямбд (сложить, умножить, сравнить) читаем, а для сложных (большие математические выражения) есть идеи как её упростить. Если дальше повышать сложность лямбд, то уже имеет смысл писать анонимную функцию, а не лямбду. Вероятность того, что она сможет быть переведеная в SQL скорее всего низкая. Согласен, еще одну ORM писать не имеет смысл. Думаю, правильней написать декоратор существующей ORM, допустим, доктрины.
В PHP ключи в массивах удобно, но их использование тоже ограничено. PHP не дает использовать сложные ключи (массивы, объекты). Так что здесь при выгрузке в массив ключи игноририруются, а при выгрузке в Dictionary нет. У него есть метод
keys() для вытаскивания простого или сложного ключа для текущего элемента через RelationInterface или \OuterInterface. Это более в духе дотнетовского LINQ. Там тоже нет ключей в IEnumerable<T>, но есть функция для получения ключа для элемента в join, orderBy,…
В конце обязательно надо добавить бенчмарки по сравнению с чистым SQL и написать вывод: «детишки, никогда не пользуйтесь этим тормозным говном и ему подобным, пишите на чистом SQL».
Ликуйте: в этой версии SQL не поддерживается.
А бенчмарки итераторов PHP уже существуют, что мерять-то. Нервным рекомендуется не смотреть. :D
А бенчмарки итераторов PHP уже существуют, что мерять-то. Нервным рекомендуется не смотреть. :D
В версии чего SQL не поддерживается? Я про чистый php.
Рекомендуется сразу выучить нормальный SQL, на котором можно строить запросы любой сложности и без ограничений, и затем не переучиваться и не переписывать весь тормозной код с этих обёрток на SQL, когда проект станет highload.
Насмотрелся я за всю жизнь на это тормозное говно, которое зачем-то лепят где-не попадя, и особенно там где случаются высокие нагрузки.
Рекомендуется сразу выучить нормальный SQL, на котором можно строить запросы любой сложности и без ограничений, и затем не переучиваться и не переписывать весь тормозной код с этих обёрток на SQL, когда проект станет highload.
Насмотрелся я за всю жизнь на это тормозное говно, которое зачем-то лепят где-не попадя, и особенно там где случаются высокие нагрузки.
Каждому своё, где нужна скорость обработки, где скорость разработки. В хорошем тоне разработки использование библиотек не отменяет требование понимания их работы. Если желания нет, то изучение SQL не поможет. Нормальная ORM покрывает большинство случаев. В редких случаях для сложных выборок, частых обновлений, вставок — SQL. Если у Вас таких случаев много, то что-то не то с архитектурой.
А мне кажется заманчивым вариантом — сделать свою подверсию языка PHP (типа LPHP), в котором можно будет «нативно» использовать всякие хитровымудренные структуры, и парсер, который будет транслировать LPHP в PHP. Конечно, мы потеряем поддержку на уровне IDE (хотя, на крайняк можно транслированный php подебажить), зато у нас появляется масса возможностей для оптимизации и добавления сахара. Конечно, основным камнем преткновения тут будет качественный парсер. Это типа как КофеJS и т.п.
Sign up to leave a comment.
Портируем C# LINQ на PHP