Оптимальность работы алгоритмов не зависит от языков и их синтаксисов. Очень плохой пример у вас. С точки зрения оптимальности работы, да и читабильность так себе. Должно было быть:
Что значит «уродливо»? На вкус и цвет? Я лично не вижу никакого уродства в символе \. По мне любой другой бы подошел, и :::, и… Лишь бы это не был ::, потому что это будет взрывать мозг, как интерпретатору, так и человеку, который в этом коде будет разбираться.
Если вы читали протокол, то там ясно написано, почему не может быть оставлен символ :: Там дело даже не в контекстных возможностях интерпретатора, а то, что придется делать autoad всегда.
Я хотел вам сказать, что в _реальной_ жизни не надо генерировать массив с опупенным количеством элементов, что бы взять из него только одно. Если такое надо, то так получается, что для этого существую другие альтернативы. Например:
Образчик абсолютно надуманного примера. Если вы возвращаете одно значение, то зачем в виде массива? Если возвращаете несколько значений в массиве, то предполагается использование их всех.
Я уже дал вам подсказку (наверно единственный случай), когда из массива значений мочет понадобиться только одно — explode().
И правильно сказал! Единственный случай, где «тянет» так обратиться к массиву, это при использовании explode(). И то только от ленности и никак не улучшает, а только ухудшает чтение кода после вас. В остальном таких позывов не появляется.
Чем проще интерпретатор, тем быстрее и надежнее он работает. Если в нем до сих пор не было контекстного разбора, то и незачем его вводить из-за такой незначительной темы, как неймспейсы. Естественно проще поменять синтаксис. А какой там будет символ, ну не все ли равно? Можно подумать что после официально ввода неймспейсов, это будет самый популярный оператор в программах. Как не было его, так и не будет в подавлающем большинстве кода.
> те разделить логику и представление, замечательно
Логика и представление уже давно отделены. Мы здесь работаем исключительно с представлением и его (представления) логикой. Логику представления никуда отделить нельзя и не надо. Ее можно лишь замаскировать. Как такое делается в «кучерявых» шаблонах ясно, а как сделать это наиболее элегантно в native PHP — тема данной статьи.
Возможно у вас другое понятие об элегантности, но в моем мире кусок HTML кода, заключенный в кавычки и передаваемый параметром куда-то — это не корректно. Я нашел достаточно дешевый способ как этого избегать и с вами им поделился. А теперь вы поясните вашу позицию, почему данный метод не имеет права на существование. Я не спрашиваю, что вы предлагаете взамен, поскольку вас «шаблон в кавычках», как я понимаю нисколько не смущает.
В статье как раз рассказывается, как я попытался убрать из шаблона код и оставить только метки. Метки — неотъемлемая часть шаблона, даже если они сделаны в native PHP синтаксисе. Посмотрите, где вы видите код у меня? Только не формально, а содержательно. Как {var}, так и <?=$var?> это семантически не код, а метки. Так же как {block ...} и <? form:: element(...)?> не код, а метки блоков в разных синтаксисах. Вы же опять тяните одеяло назад именно к самому настоящему коду, на несколько строк, с присвоениями и т. д.
Даже если код вынесен в один блок, это делает шаблон еще менее удобным в работе. Теперь придется приводить в соответствие имя поля и переменной, которые отделены возможно десятками или сотнями строк друг от друга. Тот идентификатор, который можно было написать один раз, у вас надо повторить дважды. В таком случае лучше уж QuickForm.
Дело в том, что та реализация завязана на используемую в фреймворке надстройку над HTTP. (Надстройка эта тоже очень нестандартная и вызвала бы бурю негодования, попади сюда.) Так например, там отсутствует второй параметр для form:: element, добавленый здесь, чтобы не смущать умы. Если требуется реализация, втыкаемая в любое «стандартное» место, то да, надо писать заново.
У вас совершенно правильная догадка. Буферизируется блок текста, обрамленный двумя вызовами:
form:: element('name', $name)
и
form:: element()
Закрывающий тег блока может быть опущен, если за ним следует другой открывающий тег:
form:: element('name', $name)
и
form:: element('country', $country, $countries)
и
form:: element()
Содержимое буфера анализируется на предмет того, что нас интересует. В данном случае теги элементов формы. Но применять данную методу можно и не только для форм, а везде в «трудных» местах, чтобы сохранить чистый и опрятный HTML в шаблоне.
Вы не поверите, если узнаете, что в back-end'е данной системы лежат хелперы Symfony (или почти они). То есть эти хелперы обернуты совершенно иным интерфейсом. Вы просто похоже пока не поняли сути этого интерфейса.
Забавно, что только после третьего своего комментария вы наконец стали догадываться, о чем речь в статье. Да, именно так. Но строчек там может быть не одна.
QuickForm — пройденный этап. Это как раз чистой воды хелпер с шаблоном в кавычках, о котором мы предостерегали. Чисто шовинистический программисткий подход без мысли о дизайнере и дизайне, как полноценной части разработки.
phpsavant это хорошо. Больше плюрализма, хорошего и разного!
$this->mega_model->find(«user_name»);
Если вы читали протокол, то там ясно написано, почему не может быть оставлен символ :: Там дело даже не в контекстных возможностях интерпретатора, а то, что придется делать autoad всегда.
fstat() -vs- filectime(), filemtime() и т. п.
Я уже дал вам подсказку (наверно единственный случай), когда из массива значений мочет понадобиться только одно — explode().
Ну если он на этой «тачке» нужен просто для поиграться, то пусть круг разработчиков PHP станет немного чище и профессиональнее.
Использование поговорки на умиляет голословности утверждения.
Бывает, бывает! Еще ох как бывает!
> те разделить логику и представление, замечательно
Логика и представление уже давно отделены. Мы здесь работаем исключительно с представлением и его (представления) логикой. Логику представления никуда отделить нельзя и не надо. Ее можно лишь замаскировать. Как такое делается в «кучерявых» шаблонах ясно, а как сделать это наиболее элегантно в native PHP — тема данной статьи.
Возможно у вас другое понятие об элегантности, но в моем мире кусок HTML кода, заключенный в кавычки и передаваемый параметром куда-то — это не корректно. Я нашел достаточно дешевый способ как этого избегать и с вами им поделился. А теперь вы поясните вашу позицию, почему данный метод не имеет права на существование. Я не спрашиваю, что вы предлагаете взамен, поскольку вас «шаблон в кавычках», как я понимаю нисколько не смущает.
Даже если код вынесен в один блок, это делает шаблон еще менее удобным в работе. Теперь придется приводить в соответствие имя поля и переменной, которые отделены возможно десятками или сотнями строк друг от друга. Тот идентификатор, который можно было написать один раз, у вас надо повторить дважды. В таком случае лучше уж QuickForm.
form:: element('name', $name)
и
form:: element()
Закрывающий тег блока может быть опущен, если за ним следует другой открывающий тег:
form:: element('name', $name)
и
form:: element('country', $country, $countries)
и
form:: element()
Содержимое буфера анализируется на предмет того, что нас интересует. В данном случае теги элементов формы. Но применять данную методу можно и не только для форм, а везде в «трудных» местах, чтобы сохранить чистый и опрятный HTML в шаблоне.
phpsavant это хорошо. Больше плюрализма, хорошего и разного!
<label>Label: <input type=text ...></label>