Comments 30
Забавно, еще никогда Штирлиц не был так близок к define("true", false) ;)
namespace PHP6 {
function strlen($string) {
return mb_strlen($string);
}
}
Кстати константы NULL, TRUE, FALSE, ZEND_THREAD_SAFE or ZEND_DEBUG_BUILD — нельзя переопределить.
>… изменение парадигмы программирования на PHP.
Мне кажется, что сильновато называть появление namespace изменением парадигмы программирования.
>… фреймворки начали переписывать свой код на новый лад.
Из-за одного появления namespace — вряд ли…
>… но также открывает огромную дыру в безопасности приложения.
Поясните.
P.S. Про тесты и namespace уже упоминали на хабре.
Мне кажется, что сильновато называть появление namespace изменением парадигмы программирования.
>… фреймворки начали переписывать свой код на новый лад.
Из-за одного появления namespace — вряд ли…
>… но также открывает огромную дыру в безопасности приложения.
Поясните.
P.S. Про тесты и namespace уже упоминали на хабре.
>Мне кажется, что сильновато называть появление namespace изменением парадигмы программирования.
Не буду навязывать вам свою точку зрения.
>Из-за одного появления namespace — вряд ли…
ИМХО нейспейсы дали повод наплевать на обратную совместимость, тут мало кто устоял от «рефакторинга». Опять же судя по коду, да, кое где появились Closure, goto и т.д. Но таких мест единицы.
>Поясните.
Если ктото сможет заинклюдить такой файлик вам в приложение, будете долго искать проблему.
Другой пример, что неймспейсы выбранные разработчиками для разных плагинов одной большой системы (Wordpress, Magento), могут случайно пересечься. При одинаковых именах классов вы получаете Fatal Error, но при одинаковых неймспейсах — все ок, тоесть опять можно незаметно влиять на работу другого компонента.
> P.S. Про тесты и namespace уже упоминали на хабре.
Вы, правы, упустил из виду.
Не буду навязывать вам свою точку зрения.
>Из-за одного появления namespace — вряд ли…
ИМХО нейспейсы дали повод наплевать на обратную совместимость, тут мало кто устоял от «рефакторинга». Опять же судя по коду, да, кое где появились Closure, goto и т.д. Но таких мест единицы.
>Поясните.
Если ктото сможет заинклюдить такой файлик вам в приложение, будете долго искать проблему.
Другой пример, что неймспейсы выбранные разработчиками для разных плагинов одной большой системы (Wordpress, Magento), могут случайно пересечься. При одинаковых именах классов вы получаете Fatal Error, но при одинаковых неймспейсах — все ок, тоесть опять можно незаметно влиять на работу другого компонента.
> P.S. Про тесты и namespace уже упоминали на хабре.
Вы, правы, упустил из виду.
Подсознательно писал PHP 5.3 only код с \ для стандартных функций. Теперь понял что поняло подсознание читая ман. :)
А зачем вы так делаете? Для меня, вот, это не очевидно. Скажем (выше хороший пример привели), захочется бескровно проект на UTF-8 перевести, переименовав стандартные функции для работы со строками? Что будете делать?
Чтобы избежать неоднозначностей. Не люблю «сначала ищется тут, потом там, потом сям». Во-первых — какой-никакой, но оверхид, во-вторых — возможность непредусмотренного мною вмешательства в код.
Имхо, проблема большинства php программистов в том, что они пишут код который работает только там, где он был написан и только при тех параметрах, которые были установлены в окружении на тот момент.
Я вас понимаю как человек, но это самый что, ни наесть костыль и такие вещи делаются за закрытыми дверями без лишнего шума. Мы ведь хотим быть хорошими программистами, а значит наш подход это грамотное проектирование. Мы должны стараться писать код, который будет однозначным, рабочим и гибким, а не надеяться на такие костыли. Если проблема в какой-то библиотеке, то лучше написать патч и отправить разработчикам, если в вашем коде, то лучше сделать реплейс. Вероятно, что вы не последний человек которому придется обслуживать ваш код, как быть с ними? К тому же при каких-то глобальных изменениях такие штуки обычно ломаются\теряются\забываются.
Я вас понимаю как человек, но это самый что, ни наесть костыль и такие вещи делаются за закрытыми дверями без лишнего шума. Мы ведь хотим быть хорошими программистами, а значит наш подход это грамотное проектирование. Мы должны стараться писать код, который будет однозначным, рабочим и гибким, а не надеяться на такие костыли. Если проблема в какой-то библиотеке, то лучше написать патч и отправить разработчикам, если в вашем коде, то лучше сделать реплейс. Вероятно, что вы не последний человек которому придется обслуживать ваш код, как быть с ними? К тому же при каких-то глобальных изменениях такие штуки обычно ломаются\теряются\забываются.
Имхо, проблема php в том, что код, который под него пишется, работает только там, где он был написан и только при тех параметрах, которые были установлены в окружении на тот момент.
Т.е. проблема Пэхапэ в том, что в нем есть куча ручек, которые по замыслу должны были позволить его настроить, а на деле это ручки, чтобы сломать любой код. И разработчикам приходится делать нехилый оверхед, чтобы их код работал на всех возможных конфигурация Пэхапэ.
Т.е. проблема Пэхапэ в том, что в нем есть куча ручек, которые по замыслу должны были позволить его настроить, а на деле это ручки, чтобы сломать любой код. И разработчикам приходится делать нехилый оверхед, чтобы их код работал на всех возможных конфигурация Пэхапэ.
Наверное я не так выразился. Не нужно делать код который будет работать на всех конфигурациях, достаточно чтобы код сам устанавливал нужные ему опции или сообщал что ему нужно, что на практике применяется очень немногими. Взять тот же Symfony, Wordpress там не большой оверхед.
Дело в том, что эти все ручечки зачастую не ломают код, но могут его сильно подпортить и человек может долгое время находится в неведении. В результате данные будут либо некорректны, либо повреждены.
Дело в том, что эти все ручечки зачастую не ломают код, но могут его сильно подпортить и человек может долгое время находится в неведении. В результате данные будут либо некорректны, либо повреждены.
Как вы себе это представляете? Вот библиотека, которой нужны одна положения ручек, вот библиотека, которой другие. Вот мое приложение, которое общается с двумя этими библиотеками. Как эти библиотеки должны выставлять нужные ручки? В начале каждого public метода, который я могу вызвать? А мне ставить все под себя после вызова любого public метода?
Не буду так делать. Потому что в куче библиотек подразумевается, что strlen возвращает длину _в байтах_.
Когда увидел заголовок «Переопределение...» проскочила мысль в голове «Перегрузка операторов? Наконец-то!».
but if you ever actually do this, then…
...WAT…
...WAT…
Если кто-то смог загрузить свой скрип на сервер или сделал инъекцию, то ему даже не нужно внедряться в ваш код, что бы переопределить функцию и поставить namespace, он и так может сделать все, что хочет, проблема безопасности тут высосана из пальца. Кстати, в JS можно все переопределять, все глобальные функции — это методы объекта window, и ничего, еще никто не умер от этого, а многие фреймворки активно используют такую возможность.
А запутать код можно и так, все же знаю:
define(«true», rand(0,1), TRUE);
Неймспесы и описанные возможности — однозначно шаг вперед. Но фреймворки отказались от поддержки 5.2, потому что эта версия устарела и даже не обновляется.
Я бы сказал избавились от костылей 5.2 и сменили наименование классов с Zend_Date_Date на \Zend\Date\Date. Это, конечно намного наглядней и удобней, особенно, если использовать use, но, на мой взгляд, использовать неймспейсы можно было более осмысленно, хотя для этого пришлось бы переписать «код на новый лад».
А запутать код можно и так, все же знаю:
define(«true», rand(0,1), TRUE);
Неймспесы и описанные возможности — однозначно шаг вперед. Но фреймворки отказались от поддержки 5.2, потому что эта версия устарела и даже не обновляется.
переписывать свой код на новый лад
Я бы сказал избавились от костылей 5.2 и сменили наименование классов с Zend_Date_Date на \Zend\Date\Date. Это, конечно намного наглядней и удобней, особенно, если использовать use, но, на мой взгляд, использовать неймспейсы можно было более осмысленно, хотя для этого пришлось бы переписать «код на новый лад».
>Если кто-то смог загрузить свой скрип
Взлом сервера это не инъекция, а говорил как раз об инъекции. К примеру, обновился плагин или у вас инклудится файл из внешней среды.
> отказались от поддержки 5.2, потому что эта версия устарела и даже не обновляется
Из ваших слов так между ними целая пропасть. Реально несовместимых изменений можно по пальцам пересчитать. И касательно ZF это уж точно не повод для того, чтобы наплевать на тисячи людей его использующих и оставить их без поддержки. У меня к примеру несколько патчей висят со статусом «Waiting approve from maintainer» больше полугода.
>Я бы сказал избавились от костылей 5.2 и сменили наименование классов с Zend_Date_Date на \Zend\Date\Date
Между прочим Zend_Date как был неким подобием God Pattern, так и остался. Обычное переименование. Где использование SPL DateTime/DatePeriod/DateInteval? Избавились они от костылей ага…
Взлом сервера это не инъекция, а говорил как раз об инъекции. К примеру, обновился плагин или у вас инклудится файл из внешней среды.
> отказались от поддержки 5.2, потому что эта версия устарела и даже не обновляется
Из ваших слов так между ними целая пропасть. Реально несовместимых изменений можно по пальцам пересчитать. И касательно ZF это уж точно не повод для того, чтобы наплевать на тисячи людей его использующих и оставить их без поддержки. У меня к примеру несколько патчей висят со статусом «Waiting approve from maintainer» больше полугода.
>Я бы сказал избавились от костылей 5.2 и сменили наименование классов с Zend_Date_Date на \Zend\Date\Date
Между прочим Zend_Date как был неким подобием God Pattern, так и остался. Обычное переименование. Где использование SPL DateTime/DatePeriod/DateInteval? Избавились они от костылей ага…
> Взлом сервера это не инъекция
У меня написано или инъекция. Разницы, на мой взгляд, нет. можно, конечно придумать пример, когда так бы инъекция сработала, а иначе нет, но он будет очень надуманным и смысла писать с "\" я не вижу, хотя многие авторитетные люди так делают, но я думаю это для строгости или есть другая причина.
> Из ваших слов так между ними (5.2 и 5.3) целая пропасть.
Я такого не говорил, скорее утверждал обратное: неймспейс — не аргумент, как впрочем и доработанный ООП, что, на мой взгляд, даже более важно. Хотя это касается «фич» языка, в целом, доработок и оптимизаций много, тот же is_file() в разы быстрее стал работать.
> оставить их (пользователей ZF) без поддержки
Первый ZF будет работает и на 5.3, его можно продолжать использовать. И с чего вы взяли, что они отказываются от поддержки ZF?
А поддержка PHP 5.2 да, официально планово прекращена. Эта версия поддерживалась почти два года параллельно с 5.3, по-моему, нормальный показатель.
>Между прочим Zend_Date как был неким подобием God Pattern, так и остался.
Согласен, избавились от некоторых костылей, что-то встречал и в ZF, но уже даже не вспомню. Скорее всего, связано со статичными классами.
У меня написано или инъекция. Разницы, на мой взгляд, нет. можно, конечно придумать пример, когда так бы инъекция сработала, а иначе нет, но он будет очень надуманным и смысла писать с "\" я не вижу, хотя многие авторитетные люди так делают, но я думаю это для строгости или есть другая причина.
> Из ваших слов так между ними (5.2 и 5.3) целая пропасть.
Я такого не говорил, скорее утверждал обратное: неймспейс — не аргумент, как впрочем и доработанный ООП, что, на мой взгляд, даже более важно. Хотя это касается «фич» языка, в целом, доработок и оптимизаций много, тот же is_file() в разы быстрее стал работать.
> оставить их (пользователей ZF) без поддержки
Первый ZF будет работает и на 5.3, его можно продолжать использовать. И с чего вы взяли, что они отказываются от поддержки ZF?
А поддержка PHP 5.2 да, официально планово прекращена. Эта версия поддерживалась почти два года параллельно с 5.3, по-моему, нормальный показатель.
>Между прочим Zend_Date как был неким подобием God Pattern, так и остался.
Согласен, избавились от некоторых костылей, что-то встречал и в ZF, но уже даже не вспомню. Скорее всего, связано со статичными классами.
Неплохой вариант использовать для тестов. Остальное от лукавого.
Однако функцию eval() переопределить таким образом не получится
Sign up to leave a comment.
Переопределение функций в PHP 5.3