Комментарии 113
Бред какой-то, писать препроцессор с мануалом на 2 страницы ради одной плюшки.
Так не катит, что-ли?
function array_get($array, $key) { return $array[$key]; } array_get(array('a' => 1, 'b' => 2), 'a')
Так не катит, что-ли?
+4
Соглашусь, но работа это, скорее, ради концепции, а не ради эффективности :)
+1
А вот так не судьба?
Тоже безумный код, но все лучше, чем препарсер для парсера городить. Возвращайте потомка 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, а не вектора.
0
какое странное рассуждение
бред какой-то, писать целых 20 классов вместо mysql_connect() и mysql_select_db() ;)
у препроцессора могут появиться новые фичи, ничего плохого он не делает и тормозить не заставляет, почему бы и не сделать?
а документация там проще, чем у хабрахабра
бред какой-то, писать целых 20 классов вместо mysql_connect() и mysql_select_db() ;)
у препроцессора могут появиться новые фичи, ничего плохого он не делает и тормозить не заставляет, почему бы и не сделать?
а документация там проще, чем у хабрахабра
+1
у препроцессора могут появиться новые фичиМогут, или появятся? В данном топике говориться лишь об одной, реализуемой другими средствами намного проще.
0
Какими же? Расскажите, может я туплю. Или вы предлагаете использовать костыли по всей программе?
Я сейчас думаю о реализации свойств с сеттерами и геттерами. Это просто сделать без токенайзера наследованием от класса с __get и __set, но PHP не поддерживает множественное наследование, что делает такое решение ограниченным.
По крайней мере, можно было бы создавать автоматические методы вида getName() и т.п.
Тем более, насколько я помню, запаршенный скрипт, который создает нормальные сеттеры и геттеры свойствам, будет быстрее скрипта с «магическими» функциями. Даже если я и ошибаюсь, и PHP творит «магию» быстро, медленнее мои геттеры-сеттыры точно не будут, зато у них прибавит в универсальности.
И я не понимаю, почему вы ругаетесь :) Чего плохого в моем решении?
Я сейчас думаю о реализации свойств с сеттерами и геттерами. Это просто сделать без токенайзера наследованием от класса с __get и __set, но PHP не поддерживает множественное наследование, что делает такое решение ограниченным.
По крайней мере, можно было бы создавать автоматические методы вида getName() и т.п.
Тем более, насколько я помню, запаршенный скрипт, который создает нормальные сеттеры и геттеры свойствам, будет быстрее скрипта с «магическими» функциями. Даже если я и ошибаюсь, и PHP творит «магию» быстро, медленнее мои геттеры-сеттыры точно не будут, зато у них прибавит в универсальности.
И я не понимаю, почему вы ругаетесь :) Чего плохого в моем решении?
-1
Смотрю на название блога — «Ненормальное программирование».
Да… статья на 100% соответствует тематике :)
Да… статья на 100% соответствует тематике :)
+6
ну вот :( я думал, я так, пошутил
не вижу ничего ненормального в желании бесплатно улучшить синтаксис неплохого языка :)
не вижу ничего ненормального в желании бесплатно улучшить синтаксис неплохого языка :)
0
Есть некоторая разница: улучшение синтаксиса языка != написание надстроек.
Возможно решение и неплохое, но от прочтении статьи осталось неприятное ощущение. ИМХО 90% статьи — вот какой я, не минусуйте меня.
Плюс добила фраза(или я юмора не понял):
Делал я это, разумеется, от скуки и никакой поддержки или обоснования необходимости существования не обещаю.
Если сам автор не видит необходимости существования то к чему столько воды.
Возможно решение и неплохое, но от прочтении статьи осталось неприятное ощущение. ИМХО 90% статьи — вот какой я, не минусуйте меня.
Плюс добила фраза(или я юмора не понял):
Делал я это, разумеется, от скуки и никакой поддержки или обоснования необходимости существования не обещаю.
Если сам автор не видит необходимости существования то к чему столько воды.
0
Не думаю, что есть такая уж необходимость в таком улучшении. В конце концов, если функция возвращает больше данных, чем надо Вам — может стоит задуматься о добавлении новой или изменении используемой?
+1
Ну, скажем, у Zend_Framework многие функции возвращают массивы, особенно те, что с бд работают. Да и нативные php-функции тоже не всегда ограничиваются одним значениям. Не писать же обертки.
В конце концов, такая функциональность очевидна и удобна. Она есть где угодно, кроме PHP :)
В конце концов, такая функциональность очевидна и удобна. Она есть где угодно, кроме PHP :)
+1
>> Не писать же обертки.
А Вы чем тогда занимаетесь? Одна большая глобальная обертка :)
Возможно, если бы я с ZF работал, такая необходимость бы возникала… В конце концов, стремление к «не стоит прогибаться под изменчивый мир» само по себе похвально ;)
А Вы чем тогда занимаетесь? Одна большая глобальная обертка :)
Возможно, если бы я с ZF работал, такая необходимость бы возникала… В конце концов, стремление к «не стоит прогибаться под изменчивый мир» само по себе похвально ;)
+2
Эта одна большая прозрачная обертка под кучу применений и на все времена :)
0
Да ну нафиг… Прозрачно — это когда пользователь не начинает ковыряться в мануалах и исходниках, увидев непонятную запись superFunction($foo, $bar)[2]. Особенно, если после подключения начнутся глюки, связанные с новыми внезапно обнаружившимися «фичами», которые автор еще не обнаруживал.
Куча применений — сомневаюсь. Повторюсь, часто ли приходится запрашивать целый массив значений, чтобы потом использовать только одно из них? Может, что-то не так спроектировано?
Куча применений — сомневаюсь. Повторюсь, часто ли приходится запрашивать целый массив значений, чтобы потом использовать только одно из них? Может, что-то не так спроектировано?
+1
У вас пользователи читают код? ;))
Чтобы разрешить эту конструкцию в вашем приложении, сколько бы народу над ним не работало, надо ее установить, а потом сказать: «Чуваки! Конструкция новая!». Всё. Им не надо будет думать, как она работает.
Если вы хотите использовать ее в своем собственном фреймворке, который должны получать сторонние, независимые от вас программисты, тогда придется в справке к нему написать, что, мол, не забудьте про папочку для моего кеша. Или «компилировать» его, т.е. распаршивать специально перед передачей в нативный php-синтаксис. Во обоих случаях ничего сложного, а во втором это еще и никак не коснется конечных юзеров. Код просто превратится в тот, который предлагает homm.
И да, такое бывает. Проектирую в таких случаях не я, а сторонние разработчики, из-за любви к массивам которых аккуратная цепочка методов превращается в три, а то и больше строк
Чтобы разрешить эту конструкцию в вашем приложении, сколько бы народу над ним не работало, надо ее установить, а потом сказать: «Чуваки! Конструкция новая!». Всё. Им не надо будет думать, как она работает.
Если вы хотите использовать ее в своем собственном фреймворке, который должны получать сторонние, независимые от вас программисты, тогда придется в справке к нему написать, что, мол, не забудьте про папочку для моего кеша. Или «компилировать» его, т.е. распаршивать специально перед передачей в нативный php-синтаксис. Во обоих случаях ничего сложного, а во втором это еще и никак не коснется конечных юзеров. Код просто превратится в тот, который предлагает homm.
И да, такое бывает. Проектирую в таких случаях не я, а сторонние разработчики, из-за любви к массивам которых аккуратная цепочка методов превращается в три, а то и больше строк
-3
Для избавления от «трех и больше строк» вполне подойдет arr_get(), предложенная в первом комментарии.
И в третий (последний) раз повторюсь — почему Вам из всего массива может понадобиться только одно значение? Неужели все остальное там настолько неинтересно?
И в третий (последний) раз повторюсь — почему Вам из всего массива может понадобиться только одно значение? Неужели все остальное там настолько неинтересно?
0
Хорошо, подойдет. Итак, чем плохо мое решение, которое просто ставит везде arr_get() сама, позволяя мне не думать об этом, а писать куда более читабельный код:
stat('uploads')['blksize']
Понятия не имею, зачем бы мне понадобилось узнавать именно это, но по другому это можно сделать только через левую ногу
arr_get(stat('uploads'), 'blksize'), ага. Ха-ха.
Можно я не буду повторять свой ответ, когда вы зададите вопрос в четвертый раз? Потому что мне нужно конкретное значение. Одно. Так уж вышло.
stat('uploads')['blksize']
Понятия не имею, зачем бы мне понадобилось узнавать именно это, но по другому это можно сделать только через левую ногу
arr_get(stat('uploads'), 'blksize'), ага. Ха-ха.
Можно я не буду повторять свой ответ, когда вы зададите вопрос в четвертый раз? Потому что мне нужно конкретное значение. Одно. Так уж вышло.
-3
а IDE'шки будут высвечивать ошибки на каждой строке с применением такого кодинга
+4
НЛО прилетело и опубликовало эту надпись здесь
подобные желания — от кривого проектирования.
функция не должна возвращать больше данных, чем требуется клиентскому коду.
функция не должна возвращать больше данных, чем требуется клиентскому коду.
+4
>Введи ещё в PHP поддержку функционального программирования…
А лямбда функции, это разве не из этой области =)?
А лямбда функции, это разве не из этой области =)?
+1
Такой ответ значит, что Вы просто не понимаете, что значит такая конструкция. А она, между прочим, логична и не может вызывать проблем.
0
подобные желания — от кривого проектирования.
функция не должна возвращать больше данных, чем требуется клиентскому коду.
функция не должна возвращать больше данных, чем требуется клиентскому коду.
+2
Точно. Кругом кривые руки, иначе 640 килобайт памяти…
-3
не надо мои слова перевирать.
ps: минусаторы, ну чо, давайте подискутируем на тему godlike классов/методов/функций, а? или слабо? :-)
ps: минусаторы, ну чо, давайте подискутируем на тему godlike классов/методов/функций, а? или слабо? :-)
0
Не надо писать холиварные посты, никто и минусовать не будет.
-4
это не холиварные посты.
это констатация того факта, что подобные статьи рождаются от написания godlike-кода.
если вы считаете что это нормально — то лично с вами я спорить не буду, ваша точка зрения мне понятна.
это констатация того факта, что подобные статьи рождаются от написания godlike-кода.
если вы считаете что это нормально — то лично с вами я спорить не буду, ваша точка зрения мне понятна.
0
Констатирую факт — вы уныло троллите.
-6
так и запишем:
в 2009г проектирование костылей — хорошо. а указывание на то, что это принципиально неверный ход и, мягко говоря, пагубная практика — троллинг.
спасибо.
в 2009г проектирование костылей — хорошо. а указывание на то, что это принципиально неверный ход и, мягко говоря, пагубная практика — троллинг.
спасибо.
+3
Уважаемый троль, я не собираюсь приводить аргументы того, что вы неправы. Если вы ДЕЙСТВИТЕЛЬНО хотите кому-то что-то сообщить, то это вам придется изложить аргументацию.
С уважением
Капитан Очевидность
С уважением
Капитан Очевидность
-9
habrahabr.ru/blogs/crazydev/73358/#comment_2109282
и давайте, как-нибудь, обращаться, чуть-чуть повежливее. я же вас не называю гоблином или гремлином?
и давайте, как-нибудь, обращаться, чуть-чуть повежливее. я же вас не называю гоблином или гремлином?
+2
А я называю и буду до тех пор, пока вы не изволите обосновать свою критику. Критика без аргументации — обычный троллинг.
И нет, «кривое проектирование» — недостаточная аргументация.
И нет, «кривое проектирование» — недостаточная аргументация.
-8
Вы принципиально отвергаете вторую строку коммента, на который я сослался?
0
Что вы. Просто вы ее не обосновали. С чего вы решили что функция возвращает больше данных?
Навскидку
function returnCoordinates() { return array($x, $y) }
А если немного подумать можно найти десятки примеров, когда возврат массива был бы удобным.
Навскидку
function returnCoordinates() { return array($x, $y) }
А если немного подумать можно найти десятки примеров, когда возврат массива был бы удобным.
-1
Зачем возвращать массив с 2 переменными, если вы не используете одну из них?
0
Потому что в одном случае может понадобиться одна, а в другом вторая. Вместо написания дополнительной логики по возврату маркера какая именно вовщращена более выгодно и читаемо вернуть массив. Это значительно упростит восприятие кода. Для этого синтаксис и улучшают.
Иначе по вашему такой тип как объекты вообще не нужен — уж там то сколько «лишних» полей.
Иначе по вашему такой тип как объекты вообще не нужен — уж там то сколько «лишних» полей.
-1
т.е. вместо того, чтобы написать функции, которые возвращают разные данные, вы всё валите в кучу, чтобы потом с честью разобрать на клиентской стороне…
не удивляйтесь потом, что ваши интерфейсы вот так выглядят:
не удивляйтесь потом, что ваши интерфейсы вот так выглядят:
-2
подытоживая мысль, я не против [] вообще, я против решение архитектурных проблем с помощью этой конструкции.
эта проблема, например, отлично решена в pathinfo()
ещё больше уточняя: проблемы нужно решать на локальном уровне, в каждом частном случае используя более подходящий метод: разделение методов, введение аргументов, а не выдумывая «волшебный костыль»-панацею.
эта проблема, например, отлично решена в pathinfo()
ещё больше уточняя: проблемы нужно решать на локальном уровне, в каждом частном случае используя более подходящий метод: разделение методов, введение аргументов, а не выдумывая «волшебный костыль»-панацею.
0
Да кто сказал что она призвана решать архитектурные проблемы? Вы опять вместо того чтобы спокойно дискутировать начинаете троллить. Что вы мне эту картинку-боян запостили. Или думаете тут кто-то его не видел? Или ваши аргументы от него станут более весомыми? Или думаете я срочно признаю что вы правы?
В общем как я и говорил изначально дискутировать с вами — пустая трата времени. И не потому что вы что-то не так говорите, аргументы то увас верные, просто вы постоянно пытаетесь насрать собеседнику на голову.
В общем как я и говорил изначально дискутировать с вами — пустая трата времени. И не потому что вы что-то не так говорите, аргументы то увас верные, просто вы постоянно пытаетесь насрать собеседнику на голову.
-1
при чём тут насрать? я просто призвал не делать костыли на костыли.
а картинка тут очень, имхо, уместна. она явно демонстрирует ваше:
«function returnCoordinates() { return array($x, $y) }
А если немного подумать можно найти десятки примеров, когда возврат массива был бы удобным. „
когда вместо того, чтобы написать маленькую функцию, а потом ещё одну — вы предлагаете на каждый чих в неё добавлять по элементу массива (а что, от этого ещё никто не умирал). а потом в итоге API превращается в 3 метода, которые в различных комбинациях аргументов возвращают различные комбинации результатов.
собственно я свою мысль выразил. вы тоже. предлагаю закончить спор. тем более, что автор темы здесь даже и не попытался высказаться.
а картинка тут очень, имхо, уместна. она явно демонстрирует ваше:
«function returnCoordinates() { return array($x, $y) }
А если немного подумать можно найти десятки примеров, когда возврат массива был бы удобным. „
когда вместо того, чтобы написать маленькую функцию, а потом ещё одну — вы предлагаете на каждый чих в неё добавлять по элементу массива (а что, от этого ещё никто не умирал). а потом в итоге API превращается в 3 метода, которые в различных комбинациях аргументов возвращают различные комбинации результатов.
собственно я свою мысль выразил. вы тоже. предлагаю закончить спор. тем более, что автор темы здесь даже и не попытался высказаться.
+1
Заодно стоит написать разработчикам PHP что все глобальные массивы пользователь zerkms считает унылым говном и «кривым проектированием».
-2
суперглобальные — нет.
глобальные — да.
глобальные — да.
+1
А почему нет? Ведь это так ужасно по-вашему. «Кривое проектирование». «Лишние данные».
0
с каких пор средства доступа к переменным окружения стали лишними данными?
0
Задайте тот же вопрос относительно результатов пользовательских функций и получите ответ на тему спора.
Можете заодно поразмыслить почему функциям типа
preg_match* приходится иметь дополнительный изменяемый параметр для ВОЗВРАТА собственно найденных подстрок.
Можете заодно поразмыслить почему функциям типа
preg_match* приходится иметь дополнительный изменяемый параметр для ВОЗВРАТА собственно найденных подстрок.
-1
НЛО прилетело и опубликовало эту надпись здесь
потому, что это удобно
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)?
0
кстати поаплодируем, как вы клёво перевели тему на глобальные переменные.
+1
> Иначе по вашему такой тип как объекты вообще не нужен — уж там то сколько «лишних» полей.
Не нужно путать теплое с мягким, в случае объекта возвращается ссылка, а не создается его копия.
Не нужно путать теплое с мягким, в случае объекта возвращается ссылка, а не создается его копия.
0
Где же троллинг? zakerms четко сформулировал претензию. Вы ее опровергаете, но при этом не пишете ничего осмысленного.
$filename = pathinfo($path)[1]; // ← так писать действительно плохо (опустим тот момент, что этот код не работает)
$filename = basename($path); // ← лучше писать так
$filename = pathinfo($path)[1]; // ← так писать действительно плохо (опустим тот момент, что этот код не работает)
$filename = basename($path); // ← лучше писать так
-2
Ой ну я вас прошу. Вы что группами ходите?
-7
В пяти Ваших постах этой ветви нет ни одного аргумента, зато есть искрометная фраза «я не собираюсь приводить аргументы того, что вы неправы» :) Кто тут троллит?
0
Вам в топик про чайник рассела
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
Я не собираюсь доказывать что чайника нет
-2
Вот если бы вы не оспаривали тот факт, что чайник есть (как откровенный бред), вопросов бы не было.
Получается, спорить, что его нет — Вы готовы, а доказывать, что его нет — не собираетесь. Спор ради спора и есть троллинг.
Впрочем, выше Вы все же начали писать хоть что-то, относящееся к теме, продолжу чтение там.
Получается, спорить, что его нет — Вы готовы, а доказывать, что его нет — не собираетесь. Спор ради спора и есть троллинг.
Впрочем, выше Вы все же начали писать хоть что-то, относящееся к теме, продолжу чтение там.
0
НЛО прилетело и опубликовало эту надпись здесь
Что ж такого антипаттернового в этом, уважаемый?
-3
Интересно, почему?
Посмотрите в сторону ORM'ов, там записи БД возвращаются как? в массиве. Это лишь один из примеров.
Посмотрите в сторону ORM'ов, там записи БД возвращаются как? в массиве. Это лишь один из примеров.
-1
За использование массивов вместо объектов убивать надо. Без дополнения кода в IDE писать устаешь безумно.
-1
Посмотрите в сторону ORM'ов, там записи БД возвращаются как? в массиве.Счас. В объектах.
0
Forth'еры с удовольствием поржали бы над вашим утверждением.
0
НЛО прилетело и опубликовало эту надпись здесь
С каких это пор ООП стал последней инстанцией в методиках абстрагирования и обощения?
ООП в Форте реализуется тривиально. Равно как и любая другая парадигма, вплоть до логического программирования.
ООП в Форте реализуется тривиально. Равно как и любая другая парадигма, вплоть до логического программирования.
+1
А не проще:
$array = foo ( $param1, $param2, 2 ) #2 — номер элемента массива и непонятно для чего такие извращения?
$array = foo ( $param1, $param2, 2 ) #2 — номер элемента массива и непонятно для чего такие извращения?
+1
действительно непонятно для чего такие извращения указывать номер элемента возвращаемого массива
а если я хочу вернуть весь массив? а если меня интересуют элементы 2 и 3?
не нужно мучать язык, он просто не приспособлен для этого.
решаемая автором задача бесполезная.
+2 у вашего коммента показывает что уровень быдлокодеров в этом треде зашкаливает
а если я хочу вернуть весь массив? а если меня интересуют элементы 2 и 3?
не нужно мучать язык, он просто не приспособлен для этого.
решаемая автором задача бесполезная.
+2 у вашего коммента показывает что уровень быдлокодеров в этом треде зашкаливает
0
Нет хуже «быдлокодера», который себя считает не «быдлокодером».
А вообще вернула функция весь массив, далее разбераете так как вам необходимо:
$array = foo ( $param1, $param2 );
$array = $array #… хоть как
А вообще вернула функция весь массив, далее разбераете так как вам необходимо:
$array = foo ( $param1, $param2 );
$array = $array #… хоть как
0
нормальный логичный API, класс.
а в другой функции не реализуют этот опциональный аргумент — и в итоге имеем что имеем в пхп целиком.
половина функций через подчеркивания, половина слитно, часть в виде verb+noun часть noun+verb, и как результат для использования каждой конкретной функции нужно лезть в документацию или исходный код.
а в другой функции не реализуют этот опциональный аргумент — и в итоге имеем что имеем в пхп целиком.
половина функций через подчеркивания, половина слитно, часть в виде verb+noun часть noun+verb, и как результат для использования каждой конкретной функции нужно лезть в документацию или исходный код.
0
а если я хочу вернуть весь массив?
Вызываете без третьего аргумента.
а если меня интересуют элементы 2 и 3?
Вызываете без третьего аргумента, а потом делаете array_s(p)lice, ну или что душе угодно.
0
НЛО прилетело и опубликовало эту надпись здесь
зачем возвращать массивы? возвращайте stdClass и можно будет делать так
superFunction($foo, $bar)->element2
superFunction($foo, $bar)->element2
0
Изврат же, сударь, если уж на то пошло, добавьте в php нормальный синтаксис для масивов ($array = [k1: 'v1', k2: 'v2']) и анонимных функций ($f = { |x| return x; };), возможность делать методы-обертки для нативных типов (типа «string».length() ) и вообще, сделайте мне Руби на php :)
А кеширование пропарсеныых файлов — это дублирование работы опкешера.
А кеширование пропарсеныых файлов — это дублирование работы опкешера.
0
Проект на чисто поиграться самому. Никакой практической пользы он принести не в состоянии, а ведет только к лишнему усложнению кода.
И думаю, в проекте такое может использовать только недалекий человек. Почему? Ну собственно представте, что код после вас будет кто-то другой поддерживать.
Есть язык, есть стандарты кодирования, и если каждый начнет выдумывать такие решения, этож можно дойти до своего языка, который будет собираться в PHP :).
Если нужны такие возможности, выучите язык, где они есть и не мучайтесь.
И думаю, в проекте такое может использовать только недалекий человек. Почему? Ну собственно представте, что код после вас будет кто-то другой поддерживать.
Есть язык, есть стандарты кодирования, и если каждый начнет выдумывать такие решения, этож можно дойти до своего языка, который будет собираться в PHP :).
Если нужны такие возможности, выучите язык, где они есть и не мучайтесь.
+2
Довольно типичная ситуация. Каждый программист должен пройти через такие грабли. Думаю всем хотелось или до сих пор хочется поиграться с подобного рода кодогенерацией (как-бы мета программирование). Только не каждый осознает, что это рождает кучу одному автору понятных абстракций.
Синтаксис языка — это стандарт, который должен гарантировать, что любой знакомый с этим синтаксисом во первых разберется в существующем коде, во вторых сам напишет то, что поймут другие. Внесение подобных изменений в синтаксис лишь усложнят понимание кода и в конечном счете удобство работы с ним.
Синтаксис языка — это стандарт, который должен гарантировать, что любой знакомый с этим синтаксисом во первых разберется в существующем коде, во вторых сам напишет то, что поймут другие. Внесение подобных изменений в синтаксис лишь усложнят понимание кода и в конечном счете удобство работы с ним.
0
ужасно интересно, как вы читаете слово «фаил» — в рифму с «таял» или с «поил»? или у вас просто нет буквы «й» на клавиатуре? — она с угла все-таки, может и отломаться.
собственно, вам все выше уже сказали: PHP — не Python и не Ruby; за (относительную) скорость и простоту работы приходится расплачиваться уродливым синтаксисом. ну а вы делаете наоборот — ради малюсенького улучшения синтаксиса приносите в жертву и скорость (скармливать парсеру, причем на PHP, свой код при каждом изменении — спасибо большое), и предсказуемость. не надо этого — чем переделывать PHP, выучите лучше нормальный язык.
собственно, вам все выше уже сказали: PHP — не Python и не Ruby; за (относительную) скорость и простоту работы приходится расплачиваться уродливым синтаксисом. ну а вы делаете наоборот — ради малюсенького улучшения синтаксиса приносите в жертву и скорость (скармливать парсеру, причем на PHP, свой код при каждом изменении — спасибо большое), и предсказуемость. не надо этого — чем переделывать PHP, выучите лучше нормальный язык.
-1
спасибо, поржал (Ц)
парсер для парсера, написанный на парсере — как я понимаю, подобная конструкция не кажется вам чрезмерной
парсер для парсера, написанный на парсере — как я понимаю, подобная конструкция не кажется вам чрезмерной
+4
странно что все циклятся на этом. По-моему представленная статья больше proof of concept и прикольный эксперимент. Конечно, в реальной разработке применять его было бы просто самоубийственно.
+2
ещё пара десятков тыщ мильонов велосипедов, когда вы пройдёте стадии неприятия, отторжения, цинизма, вы, скорее всего, начнёте воспринимать велосипедистов с ироничным удивлением: «ну надо же! велосипеды всё ещё изобретают!»
нет здесь ни эксперимента, ни прикола.
каждый пхпшник за свою карьеру должен написать дейтинг, изобрести парсер, и гордиться самописной цмской (Ц)
нет здесь ни эксперимента, ни прикола.
каждый пхпшник за свою карьеру должен написать дейтинг, изобрести парсер, и гордиться самописной цмской (Ц)
0
Не знаю, не знаю…
Для чужого когда имхо лучше написать обертки в виде наследующих классов. Для своего — лучше уж вернуть объект вместо массива.
Но вообще гонять данные туда-сюда не хорошо — где-то в архитектуре нелады.
Для чужого когда имхо лучше написать обертки в виде наследующих классов. Для своего — лучше уж вернуть объект вместо массива.
Но вообще гонять данные туда-сюда не хорошо — где-то в архитектуре нелады.
0
немного холивора:)
0
0
Иногда хочется подобного, но препарсер не вариант.
Любой такой препарсер как минимум затрудняет отладку, анализ кода средой и т.п. Достанут ведь красные метки, если ошибки подсвечиваются.
Вообще, задача получить результат в виде массива возникает не так часто, чаще всего когда дело касается коллекции, но в этом случае как правило любая хорошо спроектированная библиотека содержит удобный интерфейс для получения элементов. Еще есть конструкци list(), которая в некоторых случаях может упростить получение элементов.
Если уж приходится часто приходится работать с разультатом в виде массива конкретной функции/метода, проще написать обертку.
Любой такой препарсер как минимум затрудняет отладку, анализ кода средой и т.п. Достанут ведь красные метки, если ошибки подсвечиваются.
Вообще, задача получить результат в виде массива возникает не так часто, чаще всего когда дело касается коллекции, но в этом случае как правило любая хорошо спроектированная библиотека содержит удобный интерфейс для получения элементов. Еще есть конструкци list(), которая в некоторых случаях может упростить получение элементов.
Если уж приходится часто приходится работать с разультатом в виде массива конкретной функции/метода, проще написать обертку.
0
Автору 10 баллов! Предлагаю написать язык программрования на php. Без этого никак, поверьте. Я ведь создаю не движок для сайта, я создаю код. На сайт мне вообще похуй, потому-что я программирую только ради кода.
0
Если вам лень писать лишние строки для извлечения элемента возвращаемого массива и хочется, чтобы работало так:
$secondElement = superFunction(foo, bar)[2];
, то можно попробовать применить функцию list:
list(,, $secondElement) = superFunction(foo, bar);
Я делаю так. Имхо, очень удобно и не нужно никаких препроцессоров.
$secondElement = superFunction(foo, bar)[2];
, то можно попробовать применить функцию list:
list(,, $secondElement) = superFunction(foo, bar);
Я делаю так. Имхо, очень удобно и не нужно никаких препроцессоров.
0
конечно же, переменную стоило обозвать $thirdElement :)
0
кстати хороший аналог перлового
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() — его «расчленяет»
-1
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Добро пожаловать в 2013 год, тут у нас php 5.4 уже умеет делать такое нативно
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP: массивы, возвращаемые функцией