Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 113
Бред какой-то, писать препроцессор с мануалом на 2 страницы ради одной плюшки.
Так не катит, что-ли?
function array_get($array, $key) {
return $array[$key];
}
array_get(array('a' => 1, 'b' => 2), 'a')Так не катит, что-ли?
Соглашусь, но работа это, скорее, ради концепции, а не ради эффективности :)
А вот так не судьба?
Тоже безумный код, но все лучше, чем препарсер для парсера городить. Возвращайте потомка stdClass, а не вектора.
$arr = array( 'a'=>'aaa', 'b', 'c' );
class t {
protected $fields;
function __construct( $array ) { $this->fields = $array; return $this; }
function __get( $key ) { return isset( $this->fields[ $key ] ) ? $this->fields[ $key ] : false; }
}
function p( $fields ) { return new t( $fields ); }
var_export( p( $arr )->a );Тоже безумный код, но все лучше, чем препарсер для парсера городить. Возвращайте потомка stdClass, а не вектора.
какое странное рассуждение
бред какой-то, писать целых 20 классов вместо mysql_connect() и mysql_select_db() ;)
у препроцессора могут появиться новые фичи, ничего плохого он не делает и тормозить не заставляет, почему бы и не сделать?
а документация там проще, чем у хабрахабра
бред какой-то, писать целых 20 классов вместо mysql_connect() и mysql_select_db() ;)
у препроцессора могут появиться новые фичи, ничего плохого он не делает и тормозить не заставляет, почему бы и не сделать?
а документация там проще, чем у хабрахабра
у препроцессора могут появиться новые фичиМогут, или появятся? В данном топике говориться лишь об одной, реализуемой другими средствами намного проще.
Какими же? Расскажите, может я туплю. Или вы предлагаете использовать костыли по всей программе?
Я сейчас думаю о реализации свойств с сеттерами и геттерами. Это просто сделать без токенайзера наследованием от класса с __get и __set, но PHP не поддерживает множественное наследование, что делает такое решение ограниченным.
По крайней мере, можно было бы создавать автоматические методы вида getName() и т.п.
Тем более, насколько я помню, запаршенный скрипт, который создает нормальные сеттеры и геттеры свойствам, будет быстрее скрипта с «магическими» функциями. Даже если я и ошибаюсь, и PHP творит «магию» быстро, медленнее мои геттеры-сеттыры точно не будут, зато у них прибавит в универсальности.
И я не понимаю, почему вы ругаетесь :) Чего плохого в моем решении?
Я сейчас думаю о реализации свойств с сеттерами и геттерами. Это просто сделать без токенайзера наследованием от класса с __get и __set, но PHP не поддерживает множественное наследование, что делает такое решение ограниченным.
По крайней мере, можно было бы создавать автоматические методы вида getName() и т.п.
Тем более, насколько я помню, запаршенный скрипт, который создает нормальные сеттеры и геттеры свойствам, будет быстрее скрипта с «магическими» функциями. Даже если я и ошибаюсь, и PHP творит «магию» быстро, медленнее мои геттеры-сеттыры точно не будут, зато у них прибавит в универсальности.
И я не понимаю, почему вы ругаетесь :) Чего плохого в моем решении?
Смотрю на название блога — «Ненормальное программирование».
Да… статья на 100% соответствует тематике :)
Да… статья на 100% соответствует тематике :)
ну вот :( я думал, я так, пошутил
не вижу ничего ненормального в желании бесплатно улучшить синтаксис неплохого языка :)
не вижу ничего ненормального в желании бесплатно улучшить синтаксис неплохого языка :)
Есть некоторая разница: улучшение синтаксиса языка != написание надстроек.
Возможно решение и неплохое, но от прочтении статьи осталось неприятное ощущение. ИМХО 90% статьи — вот какой я, не минусуйте меня.
Плюс добила фраза(или я юмора не понял):
Делал я это, разумеется, от скуки и никакой поддержки или обоснования необходимости существования не обещаю.
Если сам автор не видит необходимости существования то к чему столько воды.
Возможно решение и неплохое, но от прочтении статьи осталось неприятное ощущение. ИМХО 90% статьи — вот какой я, не минусуйте меня.
Плюс добила фраза(или я юмора не понял):
Делал я это, разумеется, от скуки и никакой поддержки или обоснования необходимости существования не обещаю.
Если сам автор не видит необходимости существования то к чему столько воды.
Не думаю, что есть такая уж необходимость в таком улучшении. В конце концов, если функция возвращает больше данных, чем надо Вам — может стоит задуматься о добавлении новой или изменении используемой?
Ну, скажем, у Zend_Framework многие функции возвращают массивы, особенно те, что с бд работают. Да и нативные php-функции тоже не всегда ограничиваются одним значениям. Не писать же обертки.
В конце концов, такая функциональность очевидна и удобна. Она есть где угодно, кроме PHP :)
В конце концов, такая функциональность очевидна и удобна. Она есть где угодно, кроме PHP :)
>> Не писать же обертки.
А Вы чем тогда занимаетесь? Одна большая глобальная обертка :)
Возможно, если бы я с ZF работал, такая необходимость бы возникала… В конце концов, стремление к «не стоит прогибаться под изменчивый мир» само по себе похвально ;)
А Вы чем тогда занимаетесь? Одна большая глобальная обертка :)
Возможно, если бы я с ZF работал, такая необходимость бы возникала… В конце концов, стремление к «не стоит прогибаться под изменчивый мир» само по себе похвально ;)
Эта одна большая прозрачная обертка под кучу применений и на все времена :)
Да ну нафиг… Прозрачно — это когда пользователь не начинает ковыряться в мануалах и исходниках, увидев непонятную запись superFunction($foo, $bar)[2]. Особенно, если после подключения начнутся глюки, связанные с новыми внезапно обнаружившимися «фичами», которые автор еще не обнаруживал.
Куча применений — сомневаюсь. Повторюсь, часто ли приходится запрашивать целый массив значений, чтобы потом использовать только одно из них? Может, что-то не так спроектировано?
Куча применений — сомневаюсь. Повторюсь, часто ли приходится запрашивать целый массив значений, чтобы потом использовать только одно из них? Может, что-то не так спроектировано?
У вас пользователи читают код? ;))
Чтобы разрешить эту конструкцию в вашем приложении, сколько бы народу над ним не работало, надо ее установить, а потом сказать: «Чуваки! Конструкция новая!». Всё. Им не надо будет думать, как она работает.
Если вы хотите использовать ее в своем собственном фреймворке, который должны получать сторонние, независимые от вас программисты, тогда придется в справке к нему написать, что, мол, не забудьте про папочку для моего кеша. Или «компилировать» его, т.е. распаршивать специально перед передачей в нативный php-синтаксис. Во обоих случаях ничего сложного, а во втором это еще и никак не коснется конечных юзеров. Код просто превратится в тот, который предлагает homm.
И да, такое бывает. Проектирую в таких случаях не я, а сторонние разработчики, из-за любви к массивам которых аккуратная цепочка методов превращается в три, а то и больше строк
Чтобы разрешить эту конструкцию в вашем приложении, сколько бы народу над ним не работало, надо ее установить, а потом сказать: «Чуваки! Конструкция новая!». Всё. Им не надо будет думать, как она работает.
Если вы хотите использовать ее в своем собственном фреймворке, который должны получать сторонние, независимые от вас программисты, тогда придется в справке к нему написать, что, мол, не забудьте про папочку для моего кеша. Или «компилировать» его, т.е. распаршивать специально перед передачей в нативный php-синтаксис. Во обоих случаях ничего сложного, а во втором это еще и никак не коснется конечных юзеров. Код просто превратится в тот, который предлагает homm.
И да, такое бывает. Проектирую в таких случаях не я, а сторонние разработчики, из-за любви к массивам которых аккуратная цепочка методов превращается в три, а то и больше строк
Для избавления от «трех и больше строк» вполне подойдет arr_get(), предложенная в первом комментарии.
И в третий (последний) раз повторюсь — почему Вам из всего массива может понадобиться только одно значение? Неужели все остальное там настолько неинтересно?
И в третий (последний) раз повторюсь — почему Вам из всего массива может понадобиться только одно значение? Неужели все остальное там настолько неинтересно?
Хорошо, подойдет. Итак, чем плохо мое решение, которое просто ставит везде arr_get() сама, позволяя мне не думать об этом, а писать куда более читабельный код:
stat('uploads')['blksize']
Понятия не имею, зачем бы мне понадобилось узнавать именно это, но по другому это можно сделать только через левую ногу
arr_get(stat('uploads'), 'blksize'), ага. Ха-ха.
Можно я не буду повторять свой ответ, когда вы зададите вопрос в четвертый раз? Потому что мне нужно конкретное значение. Одно. Так уж вышло.
stat('uploads')['blksize']
Понятия не имею, зачем бы мне понадобилось узнавать именно это, но по другому это можно сделать только через левую ногу
arr_get(stat('uploads'), 'blksize'), ага. Ха-ха.
Можно я не буду повторять свой ответ, когда вы зададите вопрос в четвертый раз? Потому что мне нужно конкретное значение. Одно. Так уж вышло.
а IDE'шки будут высвечивать ошибки на каждой строке с применением такого кодинга
подобные желания — от кривого проектирования.
функция не должна возвращать больше данных, чем требуется клиентскому коду.
функция не должна возвращать больше данных, чем требуется клиентскому коду.
>Введи ещё в PHP поддержку функционального программирования…
А лямбда функции, это разве не из этой области =)?
А лямбда функции, это разве не из этой области =)?
Такой ответ значит, что Вы просто не понимаете, что значит такая конструкция. А она, между прочим, логична и не может вызывать проблем.
подобные желания — от кривого проектирования.
функция не должна возвращать больше данных, чем требуется клиентскому коду.
функция не должна возвращать больше данных, чем требуется клиентскому коду.
Точно. Кругом кривые руки, иначе 640 килобайт памяти…
не надо мои слова перевирать.
ps: минусаторы, ну чо, давайте подискутируем на тему godlike классов/методов/функций, а? или слабо? :-)
ps: минусаторы, ну чо, давайте подискутируем на тему godlike классов/методов/функций, а? или слабо? :-)
Не надо писать холиварные посты, никто и минусовать не будет.
это не холиварные посты.
это констатация того факта, что подобные статьи рождаются от написания godlike-кода.
если вы считаете что это нормально — то лично с вами я спорить не буду, ваша точка зрения мне понятна.
это констатация того факта, что подобные статьи рождаются от написания godlike-кода.
если вы считаете что это нормально — то лично с вами я спорить не буду, ваша точка зрения мне понятна.
Констатирую факт — вы уныло троллите.
так и запишем:
в 2009г проектирование костылей — хорошо. а указывание на то, что это принципиально неверный ход и, мягко говоря, пагубная практика — троллинг.
спасибо.
в 2009г проектирование костылей — хорошо. а указывание на то, что это принципиально неверный ход и, мягко говоря, пагубная практика — троллинг.
спасибо.
Уважаемый троль, я не собираюсь приводить аргументы того, что вы неправы. Если вы ДЕЙСТВИТЕЛЬНО хотите кому-то что-то сообщить, то это вам придется изложить аргументацию.
С уважением
Капитан Очевидность
С уважением
Капитан Очевидность
habrahabr.ru/blogs/crazydev/73358/#comment_2109282
и давайте, как-нибудь, обращаться, чуть-чуть повежливее. я же вас не называю гоблином или гремлином?
и давайте, как-нибудь, обращаться, чуть-чуть повежливее. я же вас не называю гоблином или гремлином?
А я называю и буду до тех пор, пока вы не изволите обосновать свою критику. Критика без аргументации — обычный троллинг.
И нет, «кривое проектирование» — недостаточная аргументация.
И нет, «кривое проектирование» — недостаточная аргументация.
Вы принципиально отвергаете вторую строку коммента, на который я сослался?
Что вы. Просто вы ее не обосновали. С чего вы решили что функция возвращает больше данных?
Навскидку
function returnCoordinates() { return array($x, $y) }
А если немного подумать можно найти десятки примеров, когда возврат массива был бы удобным.
Навскидку
function returnCoordinates() { return array($x, $y) }
А если немного подумать можно найти десятки примеров, когда возврат массива был бы удобным.
Зачем возвращать массив с 2 переменными, если вы не используете одну из них?
Потому что в одном случае может понадобиться одна, а в другом вторая. Вместо написания дополнительной логики по возврату маркера какая именно вовщращена более выгодно и читаемо вернуть массив. Это значительно упростит восприятие кода. Для этого синтаксис и улучшают.
Иначе по вашему такой тип как объекты вообще не нужен — уж там то сколько «лишних» полей.
Иначе по вашему такой тип как объекты вообще не нужен — уж там то сколько «лишних» полей.
т.е. вместо того, чтобы написать функции, которые возвращают разные данные, вы всё валите в кучу, чтобы потом с честью разобрать на клиентской стороне…
не удивляйтесь потом, что ваши интерфейсы вот так выглядят:
не удивляйтесь потом, что ваши интерфейсы вот так выглядят:
подытоживая мысль, я не против [] вообще, я против решение архитектурных проблем с помощью этой конструкции.
эта проблема, например, отлично решена в pathinfo()
ещё больше уточняя: проблемы нужно решать на локальном уровне, в каждом частном случае используя более подходящий метод: разделение методов, введение аргументов, а не выдумывая «волшебный костыль»-панацею.
эта проблема, например, отлично решена в pathinfo()
ещё больше уточняя: проблемы нужно решать на локальном уровне, в каждом частном случае используя более подходящий метод: разделение методов, введение аргументов, а не выдумывая «волшебный костыль»-панацею.
Да кто сказал что она призвана решать архитектурные проблемы? Вы опять вместо того чтобы спокойно дискутировать начинаете троллить. Что вы мне эту картинку-боян запостили. Или думаете тут кто-то его не видел? Или ваши аргументы от него станут более весомыми? Или думаете я срочно признаю что вы правы?
В общем как я и говорил изначально дискутировать с вами — пустая трата времени. И не потому что вы что-то не так говорите, аргументы то увас верные, просто вы постоянно пытаетесь насрать собеседнику на голову.
В общем как я и говорил изначально дискутировать с вами — пустая трата времени. И не потому что вы что-то не так говорите, аргументы то увас верные, просто вы постоянно пытаетесь насрать собеседнику на голову.
при чём тут насрать? я просто призвал не делать костыли на костыли.
а картинка тут очень, имхо, уместна. она явно демонстрирует ваше:
«function returnCoordinates() { return array($x, $y) }
А если немного подумать можно найти десятки примеров, когда возврат массива был бы удобным. „
когда вместо того, чтобы написать маленькую функцию, а потом ещё одну — вы предлагаете на каждый чих в неё добавлять по элементу массива (а что, от этого ещё никто не умирал). а потом в итоге API превращается в 3 метода, которые в различных комбинациях аргументов возвращают различные комбинации результатов.
собственно я свою мысль выразил. вы тоже. предлагаю закончить спор. тем более, что автор темы здесь даже и не попытался высказаться.
а картинка тут очень, имхо, уместна. она явно демонстрирует ваше:
«function returnCoordinates() { return array($x, $y) }
А если немного подумать можно найти десятки примеров, когда возврат массива был бы удобным. „
когда вместо того, чтобы написать маленькую функцию, а потом ещё одну — вы предлагаете на каждый чих в неё добавлять по элементу массива (а что, от этого ещё никто не умирал). а потом в итоге API превращается в 3 метода, которые в различных комбинациях аргументов возвращают различные комбинации результатов.
собственно я свою мысль выразил. вы тоже. предлагаю закончить спор. тем более, что автор темы здесь даже и не попытался высказаться.
Заодно стоит написать разработчикам PHP что все глобальные массивы пользователь zerkms считает унылым говном и «кривым проектированием».
суперглобальные — нет.
глобальные — да.
глобальные — да.
А почему нет? Ведь это так ужасно по-вашему. «Кривое проектирование». «Лишние данные».
с каких пор средства доступа к переменным окружения стали лишними данными?
Задайте тот же вопрос относительно результатов пользовательских функций и получите ответ на тему спора.
Можете заодно поразмыслить почему функциям типа
preg_match* приходится иметь дополнительный изменяемый параметр для ВОЗВРАТА собственно найденных подстрок.
Можете заодно поразмыслить почему функциям типа
preg_match* приходится иметь дополнительный изменяемый параметр для ВОЗВРАТА собственно найденных подстрок.
потому, что это удобно
docs.python.org/library/re.html
java.sun.com/docs/books/tutorial/essential/regex/matcher.html
oreilly.com/windows/archive/csharp-regular-expressions.html
не понял. чем возвращать результат в двух(!) местах(bool + array) удобнее чем возвращать один результат (Match, Matcher, MatchObject)?
кстати поаплодируем, как вы клёво перевели тему на глобальные переменные.
> Иначе по вашему такой тип как объекты вообще не нужен — уж там то сколько «лишних» полей.
Не нужно путать теплое с мягким, в случае объекта возвращается ссылка, а не создается его копия.
Не нужно путать теплое с мягким, в случае объекта возвращается ссылка, а не создается его копия.
Где же троллинг? zakerms четко сформулировал претензию. Вы ее опровергаете, но при этом не пишете ничего осмысленного.
$filename = pathinfo($path)[1]; // ← так писать действительно плохо (опустим тот момент, что этот код не работает)
$filename = basename($path); // ← лучше писать так
$filename = pathinfo($path)[1]; // ← так писать действительно плохо (опустим тот момент, что этот код не работает)
$filename = basename($path); // ← лучше писать так
Ой ну я вас прошу. Вы что группами ходите?
В пяти Ваших постах этой ветви нет ни одного аргумента, зато есть искрометная фраза «я не собираюсь приводить аргументы того, что вы неправы» :) Кто тут троллит?
Вам в топик про чайник рассела
ru.wikipedia.org/wiki/%D0%A7%D0%B0%D0%B9%D0%BD%D0%B8%D0%BA_%D0%A0%D0%B0%D1%81%D1%81%D0%B5%D0%BB%D0%B0
Я не собираюсь доказывать что чайника нет
ru.wikipedia.org/wiki/%D0%A7%D0%B0%D0%B9%D0%BD%D0%B8%D0%BA_%D0%A0%D0%B0%D1%81%D1%81%D0%B5%D0%BB%D0%B0
Я не собираюсь доказывать что чайника нет
Вот если бы вы не оспаривали тот факт, что чайник есть (как откровенный бред), вопросов бы не было.
Получается, спорить, что его нет — Вы готовы, а доказывать, что его нет — не собираетесь. Спор ради спора и есть троллинг.
Впрочем, выше Вы все же начали писать хоть что-то, относящееся к теме, продолжу чтение там.
Получается, спорить, что его нет — Вы готовы, а доказывать, что его нет — не собираетесь. Спор ради спора и есть троллинг.
Впрочем, выше Вы все же начали писать хоть что-то, относящееся к теме, продолжу чтение там.
Что ж такого антипаттернового в этом, уважаемый?
Интересно, почему?
Посмотрите в сторону ORM'ов, там записи БД возвращаются как? в массиве. Это лишь один из примеров.
Посмотрите в сторону ORM'ов, там записи БД возвращаются как? в массиве. Это лишь один из примеров.
За использование массивов вместо объектов убивать надо. Без дополнения кода в IDE писать устаешь безумно.
Посмотрите в сторону ORM'ов, там записи БД возвращаются как? в массиве.Счас. В объектах.
Forth'еры с удовольствием поржали бы над вашим утверждением.
А не проще:
$array = foo ( $param1, $param2, 2 ) #2 — номер элемента массива и непонятно для чего такие извращения?
$array = foo ( $param1, $param2, 2 ) #2 — номер элемента массива и непонятно для чего такие извращения?
действительно непонятно для чего такие извращения указывать номер элемента возвращаемого массива
а если я хочу вернуть весь массив? а если меня интересуют элементы 2 и 3?
не нужно мучать язык, он просто не приспособлен для этого.
решаемая автором задача бесполезная.
+2 у вашего коммента показывает что уровень быдлокодеров в этом треде зашкаливает
а если я хочу вернуть весь массив? а если меня интересуют элементы 2 и 3?
не нужно мучать язык, он просто не приспособлен для этого.
решаемая автором задача бесполезная.
+2 у вашего коммента показывает что уровень быдлокодеров в этом треде зашкаливает
Нет хуже «быдлокодера», который себя считает не «быдлокодером».
А вообще вернула функция весь массив, далее разбераете так как вам необходимо:
$array = foo ( $param1, $param2 );
$array = $array #… хоть как
А вообще вернула функция весь массив, далее разбераете так как вам необходимо:
$array = foo ( $param1, $param2 );
$array = $array #… хоть как
нормальный логичный API, класс.
а в другой функции не реализуют этот опциональный аргумент — и в итоге имеем что имеем в пхп целиком.
половина функций через подчеркивания, половина слитно, часть в виде verb+noun часть noun+verb, и как результат для использования каждой конкретной функции нужно лезть в документацию или исходный код.
а в другой функции не реализуют этот опциональный аргумент — и в итоге имеем что имеем в пхп целиком.
половина функций через подчеркивания, половина слитно, часть в виде verb+noun часть noun+verb, и как результат для использования каждой конкретной функции нужно лезть в документацию или исходный код.
а если я хочу вернуть весь массив?
Вызываете без третьего аргумента.
а если меня интересуют элементы 2 и 3?
Вызываете без третьего аргумента, а потом делаете array_s(p)lice, ну или что душе угодно.
зачем возвращать массивы? возвращайте stdClass и можно будет делать так
superFunction($foo, $bar)->element2
superFunction($foo, $bar)->element2
Изврат же, сударь, если уж на то пошло, добавьте в php нормальный синтаксис для масивов ($array = [k1: 'v1', k2: 'v2']) и анонимных функций ($f = { |x| return x; };), возможность делать методы-обертки для нативных типов (типа «string».length() ) и вообще, сделайте мне Руби на php :)
А кеширование пропарсеныых файлов — это дублирование работы опкешера.
А кеширование пропарсеныых файлов — это дублирование работы опкешера.
Проект на чисто поиграться самому. Никакой практической пользы он принести не в состоянии, а ведет только к лишнему усложнению кода.
И думаю, в проекте такое может использовать только недалекий человек. Почему? Ну собственно представте, что код после вас будет кто-то другой поддерживать.
Есть язык, есть стандарты кодирования, и если каждый начнет выдумывать такие решения, этож можно дойти до своего языка, который будет собираться в PHP :).
Если нужны такие возможности, выучите язык, где они есть и не мучайтесь.
И думаю, в проекте такое может использовать только недалекий человек. Почему? Ну собственно представте, что код после вас будет кто-то другой поддерживать.
Есть язык, есть стандарты кодирования, и если каждый начнет выдумывать такие решения, этож можно дойти до своего языка, который будет собираться в PHP :).
Если нужны такие возможности, выучите язык, где они есть и не мучайтесь.
Довольно типичная ситуация. Каждый программист должен пройти через такие грабли. Думаю всем хотелось или до сих пор хочется поиграться с подобного рода кодогенерацией (как-бы мета программирование). Только не каждый осознает, что это рождает кучу одному автору понятных абстракций.
Синтаксис языка — это стандарт, который должен гарантировать, что любой знакомый с этим синтаксисом во первых разберется в существующем коде, во вторых сам напишет то, что поймут другие. Внесение подобных изменений в синтаксис лишь усложнят понимание кода и в конечном счете удобство работы с ним.
Синтаксис языка — это стандарт, который должен гарантировать, что любой знакомый с этим синтаксисом во первых разберется в существующем коде, во вторых сам напишет то, что поймут другие. Внесение подобных изменений в синтаксис лишь усложнят понимание кода и в конечном счете удобство работы с ним.
ужасно интересно, как вы читаете слово «фаил» — в рифму с «таял» или с «поил»? или у вас просто нет буквы «й» на клавиатуре? — она с угла все-таки, может и отломаться.
собственно, вам все выше уже сказали: PHP — не Python и не Ruby; за (относительную) скорость и простоту работы приходится расплачиваться уродливым синтаксисом. ну а вы делаете наоборот — ради малюсенького улучшения синтаксиса приносите в жертву и скорость (скармливать парсеру, причем на PHP, свой код при каждом изменении — спасибо большое), и предсказуемость. не надо этого — чем переделывать PHP, выучите лучше нормальный язык.
собственно, вам все выше уже сказали: PHP — не Python и не Ruby; за (относительную) скорость и простоту работы приходится расплачиваться уродливым синтаксисом. ну а вы делаете наоборот — ради малюсенького улучшения синтаксиса приносите в жертву и скорость (скармливать парсеру, причем на PHP, свой код при каждом изменении — спасибо большое), и предсказуемость. не надо этого — чем переделывать PHP, выучите лучше нормальный язык.
спасибо, поржал (Ц)
парсер для парсера, написанный на парсере — как я понимаю, подобная конструкция не кажется вам чрезмерной
парсер для парсера, написанный на парсере — как я понимаю, подобная конструкция не кажется вам чрезмерной
странно что все циклятся на этом. По-моему представленная статья больше proof of concept и прикольный эксперимент. Конечно, в реальной разработке применять его было бы просто самоубийственно.
ещё пара десятков тыщ мильонов велосипедов, когда вы пройдёте стадии неприятия, отторжения, цинизма, вы, скорее всего, начнёте воспринимать велосипедистов с ироничным удивлением: «ну надо же! велосипеды всё ещё изобретают!»
нет здесь ни эксперимента, ни прикола.
каждый пхпшник за свою карьеру должен написать дейтинг, изобрести парсер, и гордиться самописной цмской (Ц)
нет здесь ни эксперимента, ни прикола.
каждый пхпшник за свою карьеру должен написать дейтинг, изобрести парсер, и гордиться самописной цмской (Ц)
Не знаю, не знаю…
Для чужого когда имхо лучше написать обертки в виде наследующих классов. Для своего — лучше уж вернуть объект вместо массива.
Но вообще гонять данные туда-сюда не хорошо — где-то в архитектуре нелады.
Для чужого когда имхо лучше написать обертки в виде наследующих классов. Для своего — лучше уж вернуть объект вместо массива.
Но вообще гонять данные туда-сюда не хорошо — где-то в архитектуре нелады.
немного холивора:)
Иногда хочется подобного, но препарсер не вариант.
Любой такой препарсер как минимум затрудняет отладку, анализ кода средой и т.п. Достанут ведь красные метки, если ошибки подсвечиваются.
Вообще, задача получить результат в виде массива возникает не так часто, чаще всего когда дело касается коллекции, но в этом случае как правило любая хорошо спроектированная библиотека содержит удобный интерфейс для получения элементов. Еще есть конструкци list(), которая в некоторых случаях может упростить получение элементов.
Если уж приходится часто приходится работать с разультатом в виде массива конкретной функции/метода, проще написать обертку.
Любой такой препарсер как минимум затрудняет отладку, анализ кода средой и т.п. Достанут ведь красные метки, если ошибки подсвечиваются.
Вообще, задача получить результат в виде массива возникает не так часто, чаще всего когда дело касается коллекции, но в этом случае как правило любая хорошо спроектированная библиотека содержит удобный интерфейс для получения элементов. Еще есть конструкци list(), которая в некоторых случаях может упростить получение элементов.
Если уж приходится часто приходится работать с разультатом в виде массива конкретной функции/метода, проще написать обертку.
Автору 10 баллов! Предлагаю написать язык программрования на php. Без этого никак, поверьте. Я ведь создаю не движок для сайта, я создаю код. На сайт мне вообще похуй, потому-что я программирую только ради кода.
Если вам лень писать лишние строки для извлечения элемента возвращаемого массива и хочется, чтобы работало так:
$secondElement = superFunction(foo, bar)[2];
, то можно попробовать применить функцию list:
list(,, $secondElement) = superFunction(foo, bar);
Я делаю так. Имхо, очень удобно и не нужно никаких препроцессоров.
$secondElement = superFunction(foo, bar)[2];
, то можно попробовать применить функцию list:
list(,, $secondElement) = superFunction(foo, bar);
Я делаю так. Имхо, очень удобно и не нужно никаких препроцессоров.
конечно же, переменную стоило обозвать $thirdElement :)
кстати хороший аналог перлового
my ($foo, $bar, $elem) = superfunction();
но блин, почему ж так все через одно место.
в том же перле
my @array = (1,2,3);
my ($elem, $elem2) = @array;
т.е. работа со списками совершенно прозрачна, а тут ф-ция array() создает список, а list() — его «расчленяет»
my ($foo, $bar, $elem) = superfunction();
но блин, почему ж так все через одно место.
в том же перле
my @array = (1,2,3);
my ($elem, $elem2) = @array;
т.е. работа со списками совершенно прозрачна, а тут ф-ция array() создает список, а list() — его «расчленяет»
Добро пожаловать в 2013 год, тут у нас php 5.4 уже умеет делать такое нативно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP: массивы, возвращаемые функцией