вторую фразу я не понял :)
я имел в виду, что огромное (абсолютное) количество мата в коде на PHP, писаном русскими программистами, может быть вызвано огромным количеством самого кода
Хорошо, подойдет. Итак, чем плохо мое решение, которое просто ставит везде arr_get() сама, позволяя мне не думать об этом, а писать куда более читабельный код:
stat('uploads')['blksize']
Понятия не имею, зачем бы мне понадобилось узнавать именно это, но по другому это можно сделать только через левую ногу
arr_get(stat('uploads'), 'blksize'), ага. Ха-ха.
Можно я не буду повторять свой ответ, когда вы зададите вопрос в четвертый раз? Потому что мне нужно конкретное значение. Одно. Так уж вышло.
Чтобы разрешить эту конструкцию в вашем приложении, сколько бы народу над ним не работало, надо ее установить, а потом сказать: «Чуваки! Конструкция новая!». Всё. Им не надо будет думать, как она работает.
Если вы хотите использовать ее в своем собственном фреймворке, который должны получать сторонние, независимые от вас программисты, тогда придется в справке к нему написать, что, мол, не забудьте про папочку для моего кеша. Или «компилировать» его, т.е. распаршивать специально перед передачей в нативный php-синтаксис. Во обоих случаях ничего сложного, а во втором это еще и никак не коснется конечных юзеров. Код просто превратится в тот, который предлагает homm.
И да, такое бывает. Проектирую в таких случаях не я, а сторонние разработчики, из-за любви к массивам которых аккуратная цепочка методов превращается в три, а то и больше строк
Какими же? Расскажите, может я туплю. Или вы предлагаете использовать костыли по всей программе?
Я сейчас думаю о реализации свойств с сеттерами и геттерами. Это просто сделать без токенайзера наследованием от класса с __get и __set, но PHP не поддерживает множественное наследование, что делает такое решение ограниченным.
По крайней мере, можно было бы создавать автоматические методы вида getName() и т.п.
Тем более, насколько я помню, запаршенный скрипт, который создает нормальные сеттеры и геттеры свойствам, будет быстрее скрипта с «магическими» функциями. Даже если я и ошибаюсь, и PHP творит «магию» быстро, медленнее мои геттеры-сеттыры точно не будут, зато у них прибавит в универсальности.
И я не понимаю, почему вы ругаетесь :) Чего плохого в моем решении?
Ну, скажем, у Zend_Framework многие функции возвращают массивы, особенно те, что с бд работают. Да и нативные php-функции тоже не всегда ограничиваются одним значениям. Не писать же обертки.
В конце концов, такая функциональность очевидна и удобна. Она есть где угодно, кроме PHP :)
Короче, это 2 разных подхода: мой позволяет получить фаил легче и без лишнего, ваш — собрать любую библиотеку полностью без лишних телодвижений. Хватит холивара 8)
Я бы не сказал. Там, скажем, хелперов к виду больше, чем фаилов в некоторых библиотеках :)
Нет, мне ваше решение совсем не нравится. Чем плох фаил со списком классов? Возможно, метод его создания кривоват, но сама практика не так плоха. Тем более, похожим образом работает Zend_Loader_PluginLoader
короче, график обижает PHP несправедливо;)
я имел в виду, что огромное (абсолютное) количество мата в коде на PHP, писаном русскими программистами, может быть вызвано огромным количеством самого кода
По-моему, какие-то из них можно попросить не показывать отдельные типы ошибок
stat('uploads')['blksize']
Понятия не имею, зачем бы мне понадобилось узнавать именно это, но по другому это можно сделать только через левую ногу
arr_get(stat('uploads'), 'blksize'), ага. Ха-ха.
Можно я не буду повторять свой ответ, когда вы зададите вопрос в четвертый раз? Потому что мне нужно конкретное значение. Одно. Так уж вышло.
Чтобы разрешить эту конструкцию в вашем приложении, сколько бы народу над ним не работало, надо ее установить, а потом сказать: «Чуваки! Конструкция новая!». Всё. Им не надо будет думать, как она работает.
Если вы хотите использовать ее в своем собственном фреймворке, который должны получать сторонние, независимые от вас программисты, тогда придется в справке к нему написать, что, мол, не забудьте про папочку для моего кеша. Или «компилировать» его, т.е. распаршивать специально перед передачей в нативный php-синтаксис. Во обоих случаях ничего сложного, а во втором это еще и никак не коснется конечных юзеров. Код просто превратится в тот, который предлагает homm.
И да, такое бывает. Проектирую в таких случаях не я, а сторонние разработчики, из-за любви к массивам которых аккуратная цепочка методов превращается в три, а то и больше строк
Я сейчас думаю о реализации свойств с сеттерами и геттерами. Это просто сделать без токенайзера наследованием от класса с __get и __set, но PHP не поддерживает множественное наследование, что делает такое решение ограниченным.
По крайней мере, можно было бы создавать автоматические методы вида getName() и т.п.
Тем более, насколько я помню, запаршенный скрипт, который создает нормальные сеттеры и геттеры свойствам, будет быстрее скрипта с «магическими» функциями. Даже если я и ошибаюсь, и PHP творит «магию» быстро, медленнее мои геттеры-сеттыры точно не будут, зато у них прибавит в универсальности.
И я не понимаю, почему вы ругаетесь :) Чего плохого в моем решении?
В конце концов, такая функциональность очевидна и удобна. Она есть где угодно, кроме PHP :)
не вижу ничего ненормального в желании бесплатно улучшить синтаксис неплохого языка :)
бред какой-то, писать целых 20 классов вместо mysql_connect() и mysql_select_db() ;)
у препроцессора могут появиться новые фичи, ничего плохого он не делает и тормозить не заставляет, почему бы и не сделать?
а документация там проще, чем у хабрахабра
Нет, мне ваше решение совсем не нравится. Чем плох фаил со списком классов? Возможно, метод его создания кривоват, но сама практика не так плоха. Тем более, похожим образом работает Zend_Loader_PluginLoader
Я сначала думал вырезать через Zend_Codegenerator, но после исправления в нем второй ошибки решил перейти к дедовским методам )