Егор молодца, что тут сказать. Он их предупреждал "… мейнтейнеры Rails игнорировали баг… Егор теперь решил протестировать его"))
Вот и я хочу этим топиком узнать все + и — донного подхода.
И у рельс кстати есть два метода для настройки фильтрации attr_protected и attr_accessible. Слабенькая гибкость, но всё же.
Очень жаль, так как для меня только открылось понятие метапрограммирование, и ваш топик мне понравился, не смотря на то что есть много информации по нему. Не могу плюсануть, так как меня слили))
Обшибку исправил, спасибо.
В вашем топике вы динамически создаете методы с помощью каррирования. Примеры можно найти. Я же создаю переменные и свойства на основе пришедших данных, и чем это не метапрограммирование?
Кстати, пока писал этот коммент, пришло озарение где мой велосипед вроде бы уже используется и что пример с супглоб масивами был, мягко говоря, не очень. Так как многим из вас это напомнило register_globals.
Если это подтвердится, надеюсь вы поменяете своё мнение об этом подходе, или расстреляете меня до конца!))
Ну фильтры я уже не добавлял, просто в строке где присваивание, коментами предупредил о необходимости отфильтровать данные. Кстати спасибо data_filtering.
Ладно, знаю что всё сыро и убого)) Но вкратце пожалуйста перечислите костыли и подводные камушки! Так как я наивен и до сих пор думаю что это хорошее решение…
1. foeach работает немного медленнее с одномерными ассоциативными массивами, и на порядок медленнее с двумерными
2. ещё рас повторюсь, extract() не безопасен, он возобновляет давно похороненный register_globals!
3. очень даже легко отлаживать. я же в примере сделал выводы и реквеста и переменных, которые он создал. Если у Вас при отладке нет таких переменных или свойства не переприсвоены, просто проеверяем есть ли оное в супглоб массиве и всё.
register_globals тут даже и не пахнет, я же не зря упомянул, что будут инициализированы только public свойства класса, весь остальной мусор можно отфильтровать…
Так обычно и делают, дело в том что я решил сделать более универсальный метод. В котором не нужно париться с этими инициализациями (при условии использования классов). Мы скормили объект класса в в метод инициализации и всё, получили свойства с значениями (желательно что бы эти свойства уже были обьявленны в классе да бы избежать нотисов и ерорров).
extract() хорошая функция, но мы не контролируем инициализацию, то есть в моём случае, перед инициализацией, мы можем прогнать данные через фильтры проверки данных и очистки
Вот и я хочу этим топиком узнать все + и — донного подхода.
И у рельс кстати есть два метода для настройки фильтрации attr_protected и attr_accessible. Слабенькая гибкость, но всё же.
В вашем топике вы динамически создаете методы с помощью каррирования. Примеры можно найти. Я же создаю переменные и свойства на основе пришедших данных, и чем это не метапрограммирование?
Кстати, пока писал этот коммент, пришло озарение где мой велосипед вроде бы уже используется и что пример с супглоб масивами был, мягко говоря, не очень. Так как многим из вас это напомнило register_globals.
Если это подтвердится, надеюсь вы поменяете своё мнение об этом подходе, или расстреляете меня до конца!))
Но всё же не понятно, почему это не удобно и где кроется опасность?
2. ещё рас повторюсь, extract() не безопасен, он возобновляет давно похороненный register_globals!
3. очень даже легко отлаживать. я же в примере сделал выводы и реквеста и переменных, которые он создал. Если у Вас при отладке нет таких переменных или свойства не переприсвоены, просто проеверяем есть ли оное в супглоб массиве и всё.
register_globals тут даже и не пахнет, я же не зря упомянул, что будут инициализированы только public свойства класса, весь остальной мусор можно отфильтровать…