Comments 21
Интересный подход к синтаксису. Жаль
or и and без подчёркивания использовать не получится. Путаница неизбежна. Даже в примерах автор путается и пишет без подчёркивания.
Кстати помнится был RFC чтобы научить позволить использовать зарезервированные слова в именах методов, но он так и не прошел. Обидно…
Лично я как выходец из С, все что начинается с нижней риски считаю чем-то что трогать не нужно, но в данном случае больше ничего не придумать.
Лично я как выходец из С, все что начинается с нижней риски считаю чем-то что трогать не нужно, но в данном случае больше ничего не придумать.
ну можно было бы использовать для именования функций похожие по смыслу слова:
or -> whether, else, either
или сокращения:
and -> nd
:)
or -> whether, else, either
или сокращения:
and -> nd
:)
Ага, whatever :)
вот сокращения Это точно неинтуитивно. Представьте вам попался код с такими методами, вы без документации ничего не поймете. Насчет синонимов, то во-первых я знаю много людей которые whether напишут weather 1 раз из 10-ти, а вот слово either грамматически чато идет после предыдущего «or», и тем у кого английский родной будет очень непривычно так писать. Else — это вообще никуда не подойдет, кстати тоже зарезервированное слово.
Ну и всякое по мелочи: хардкод
SET NAMES utf8 и отсутствие экранирования таблиц.«set names utf8» — это в духе того что в классе Request хардкод Content-Encoding UTF8. С другой стороны мир был бы гораздо проще если бы все перешло на ЮТФ еще несколько лет назад. Вспоминаю как где-то в 2009м приходилось по многим сайтам выбирать кодировку вручную так они и cp1251 и KOI8-R ставили, при чем сайт сам был на УТФ как потом оказывалось =)
А вот таблицы екранируються, есть пример прям в тесте парсера:
github.com/dracony/PHPixie-DB/blob/3.0/tests/db/DB/Driver/PDO/Mysql/MysqlParserTest.php
А вот таблицы екранируються, есть пример прям в тесте парсера:
github.com/dracony/PHPixie-DB/blob/3.0/tests/db/DB/Driver/PDO/Mysql/MysqlParserTest.php
Кстати а что нас ждеть с базами в Yii 2.0? А то здесь что-то о ней особо никто не писал еще. Интересно все-таки =)
Документация ещё не до конца готова, но вот:
github.com/yiisoft/yii2/blob/master/docs/guide/database-basics.md — это про построение запросов и нижний уровень.
github.com/yiisoft/yii2/blob/master/docs/guide/active-record.md — это про AR.
Кроме уже описанных штук для SQL недавно сделали бэкенды для Elasticsearch, Sphinx, Redis, MongoDB. Работает как на уровне запросов, так и ActiveRecord.
github.com/yiisoft/yii2/blob/master/docs/guide/database-basics.md — это про построение запросов и нижний уровень.
github.com/yiisoft/yii2/blob/master/docs/guide/active-record.md — это про AR.
Кроме уже описанных штук для SQL недавно сделали бэкенды для Elasticsearch, Sphinx, Redis, MongoDB. Работает как на уровне запросов, так и ActiveRecord.
И все-таки, зачем вы переизобрели велосипед с квадратными колесами?
Все эти ORM, API, мегатонны модных слов и продвинутых терминов…
Все это просто не работает.
Все эти ORM, API, мегатонны модных слов и продвинутых терминов…
Все это просто не работает.
ORM отлично работает, очень удобно. API… вы знаете, что это такое вообще?
Удобно до тех пор, пока сутра тебе не приходит смс от Nagios'а, в котором ты видишь LA 60 на 4-хпроцовой машине с SSD и не можешь понять ни один запрос к базе. А при попытках что-то исправить твой ORM предусмотрительно отбивает тебе руки. Вот до этих пор — удобно! А после сидишь и шерсть на пятой точке рвешь от осознания собственной беспомощности и расплаты за удобство, когда твои клиенты, твой хлеб, твои деньги просто уходят только потому что тебе когда-то было удобно.
Кто-нибудь, объясните пожалуйста дураку, почему разработчики фреймворков так любят изобретать собственные ORM с привязкой к их фреймворкам? Почему нельзя реализовать ORM как standalone пакет, как Doctrine например?
у всякого программиста есть свой синдром NIH
Ну вот тут же написано что можно буднт использовать повсюду.
А ответ на ваш вопро,- потому что любой фрейиворк силбно зависит от ОРМа и если использовать либу извне то что поьом делать если в нее например со времннем нельзя будет добавить какую-то фичу без правки кода самой библиотееи и тд
А ответ на ваш вопро,- потому что любой фрейиворк силбно зависит от ОРМа и если использовать либу извне то что поьом делать если в нее например со времннем нельзя будет добавить какую-то фичу без правки кода самой библиотееи и тд
А ответ на ваш вопро,- потому что любой фрейиворк силбно зависит от ОРМНикогда прежде не слышал ничего подобного в отношении фреймворков, только в отношении CMS или CMF. Мне кажется в идеале фреймворк должен предоставлять интерфейсы абстрагирования взаимодействия модулей с ORM таким образом, чтобы к нему можно было прикрутить любую ORM просто реализовав необходимые интерфейсы-адаптеры.
Это конечно да, но я думаю что кгда кто-то начинает писать фреймворк у него есть четкие цели которые он хочет сделать по другому, в ином случае нет никакого смысла писать его в принципе. Например тут имеем другой синтаксис доступа к БД с дополнительными фичами которых раньше не было ( пермутация логических запросов в Монго).
Мне кажется, что если фреймворк заточен под конкретную ORM, то этот фреймворк как минимум не заслуживает внимания
Если даже взять симфони где можно приерутить другие ОРМ, например Пропел, то все равно получается что все модули (например Форма) просят свой адаптер е нему. То есть уж так сильно абстрагироватся не пооучится. А если нелтзя абстрагироватся то лучше уж чтоб все писали под один и тот же.
То есть ваша идея прикольная но в практике не видал такого
То есть ваша идея прикольная но в практике не видал такого
Sign up to leave a comment.
Закончен новый модуль базы данных для PHPixie