Comments 22
glasses — стаканёши же :)
А почему php 5.4 и выше? И не получится ли, что в итоге придётся писать экстеншн для php?
Исходил из той версии, которая позволяет использовать вариацию множественного наследования — трейты. Некоторые пункты в плане, например «свойства» — проще и чище реализуются именно через его подключение. После обработки библиотекой — в класс подключается вот такой трейт, который и будет реализовывать данную логику: github.com/SerafimArts/Chidori-2.1/blob/version-2.1/framework/Chidori/Traits/Properties.php
А `__get` и `__set` из трейта не будут конфликтовать с другими `__get`/`__set`?
Будет перегрузка, да, но в таких случаях можно проверять наличие этих методов в наследнике и дописывать в директиву use, например следующее:
use Properties {
Properties::__set as BLAH;
Properties::__get as BLAH;
}
а в существующих методах наследника добавлять: `$this->BLAH();`, где BLAH — произвольно сгенерированное имя.
use Properties {
Properties::__set as BLAH;
Properties::__get as BLAH;
}
а в существующих методах наследника добавлять: `$this->BLAH();`, где BLAH — произвольно сгенерированное имя.
На счёт расширения — я категорически против. Видел уже довольно много действительно крутых расширений, которые умерли просто потому, что: а) выходит новая версия языка — расширение заточено под старую. б) Очень редко кто берётся за развитие заброшенного кем-то расширения. в) Большинство площадок не позволяет ставить сторонние расширения.
Плюс, хочу отметить, что пока не сталкивался с особыми проблемами, когда потребуется именно расширение — всё реализуется именно средствами самого языка, только зачастую это неудобно писать, да и выглядит коряво.
Плюс, хочу отметить, что пока не сталкивался с особыми проблемами, когда потребуется именно расширение — всё реализуется именно средствами самого языка, только зачастую это неудобно писать, да и выглядит коряво.
Вцелом выглядит как такой себе CoffeeScript для PHP.
Думаю, проект взлетит, если как и кофи, будет решать насущные проблемы, а не вводить новые элементы ради новых элементов.
Первое, что имхо, надо сделать — сократить синтаксис. Коль это синтаксический сахар, то в примере, не слишком сладко получается.
Код не слишком удобен для чтения, и не слишком читабельный. Эти вещи можно бы сначала оптимизировать, а потом двигаться дальше, предлагая какие коснтукции реально могут упростить жизнь и какие есть пракические примеры их использования.
Думаю, проект взлетит, если как и кофи, будет решать насущные проблемы, а не вводить новые элементы ради новых элементов.
Первое, что имхо, надо сделать — сократить синтаксис. Коль это синтаксический сахар, то в примере, не слишком сладко получается.
Код не слишком удобен для чтения, и не слишком читабельный. Эти вещи можно бы сначала оптимизировать, а потом двигаться дальше, предлагая какие коснтукции реально могут упростить жизнь и какие есть пракические примеры их использования.
Хлам — очень веский довод. Сейчас постарался взглянуть с другой стороны — Вы правы. Сам пример выглядит монстрообразно, почти как битрикс в расцвете сил. Постараюсь на днях решить эту проблему — акцентировать на самом главном, указать моменты, упрощающие жизнь, вынести на обсуждение потребность в них.
В любом случае кофе — полностью заменяет синтаксис и для непосвящённого человека — выглядит более чем устрашающе. В данном варианте — вместо того, что бы полностью переписывать весь синтаксис или писать что-то в комментариях (как это делается в aspect) — реализовать тот синтаксис, который был бы понятен любому PHP разработчику, без углублений в тонкости реализации.
В любом случае кофе — полностью заменяет синтаксис и для непосвящённого человека — выглядит более чем устрашающе. В данном варианте — вместо того, что бы полностью переписывать весь синтаксис или писать что-то в комментариях (как это делается в aspect) — реализовать тот синтаксис, который был бы понятен любому PHP разработчику, без углублений в тонкости реализации.
Эх, подлил я масла в огонь со своими фильтрами )
Однако приятно, что мои слова помогли изучить такую интересную технику. Реализация получилась весьма интересная, однако надо учесть много факторов, таких как опкод-кэшеры, корректную работу со стримами и прочее. А то в реальном применении все свалится благополучно, потому что код будет закэширован опкод-кэшером.
Однако приятно, что мои слова помогли изучить такую интересную технику. Реализация получилась весьма интересная, однако надо учесть много факторов, таких как опкод-кэшеры, корректную работу со стримами и прочее. А то в реальном применении все свалится благополучно, потому что код будет закэширован опкод-кэшером.
На счёт опкод-кешеров — сомневаюсь, разработка велась на php 5.5 (встроенный Zend Optimizer+), но на EAccelerator и проч. — не проверял. Сам кеш реализован простой сверкой filemtime файла в кеше и существующего файла.
На счёт корректной работы со стримами — немного не понял. Проверял на «Hello World» Yii 1.1 приложении — всё работало замечательно, но не стал указывать это в статье, т.к. ни замеров скорости, но полных тестов не проводил, да и «хелло ворлд» — не показатель. В любом случае в репозитории есть пример типизации в параметрах методов — полностью рабочий, без ошибок.
На счёт корректной работы со стримами — немного не понял. Проверял на «Hello World» Yii 1.1 приложении — всё работало замечательно, но не стал указывать это в статье, т.к. ни замеров скорости, но полных тестов не проводил, да и «хелло ворлд» — не показатель. В любом случае в репозитории есть пример типизации в параметрах методов — полностью рабочий, без ошибок.
Имхо, самый большой недостаток-это ругань IDE на этот сахар. Не имея нормальной поддержки для этих конструкций на уровне IDE, сама разработка уже не покажется сахаром.
Документация и тем более комментарии в коде на русском — это, мягко говоря, плохая практика
Ну там всего два комментария на русском в последнем пуше, можно простить, учитывая то, что остальное подавляющее большинство на английском. На счёт документации сложнее — я страдаю болезнью «медвежий английский», так что будет проблематично описывать тонкости и уж тем паче написать какое-нибудь руководство на языке, отличного от русского. Единственный вариант — нанять переводчика, но пока я не готов к таким расходам, а гугл транслейт выглядит довольно по-детски.
может совпадение, но действительно первые два файла, которые я глунял были с русскими комментариями :) больше не смотрел, поскольку с мобилы читал :) по поводу английского, надо писать как получится, а народу если понравится, то поймут и поправят, чтоб было красиво и понятно ;)
Пока библиотека не станет хоть немного популярна — никто править не будет — это говорит хотя бы о том, что вчера обнаружил фантастическую багу, которая ломала всё, если в операторе include\require присутствует что-нибудь отличное от строки, не думаю что если бы хоть один человек скачал и попробовал — этого бы не обнаружил =) А тут всего лишь комментарии.
Sign up to leave a comment.
Cинтаксический сахар для PHP