Комментарии 30
А ведь у меня были планы на вечер…
+18
PHP 6 Pissing in the Wind
Не нравится мне этот Зеев, одно и то же везде толдычит: «мы не будем делать аксессоры, потому что PHP программистам придется учить еще одну фичу.»
Что это за подход вообще? Генераторы как мимо него протолкнули интересно.
Не нравится мне этот Зеев, одно и то же везде толдычит: «мы не будем делать аксессоры, потому что PHP программистам придется учить еще одну фичу.»
Что это за подход вообще? Генераторы как мимо него протолкнули интересно.
+3
Именно по этой причине масса PHP-программитов постоянно смотрят в сторону Python, Ruby и др.
По идее можно было бы сделать форк PHP, но похоже оно особо никому и не надо.
По идее можно было бы сделать форк PHP, но похоже оно особо никому и не надо.
+3
Вопрос скорее не в фичах, а в их реализациях.
Если бы самые крутые РНРшники, принимающие PSR, знали Си и могли хакать РНР как они захотят, то через 1-2 итерации мы получили бы Джаву. Ну и зачем?
Если бы самые крутые РНРшники, принимающие PSR, знали Си и могли хакать РНР как они захотят, то через 1-2 итерации мы получили бы Джаву. Ну и зачем?
+4
Вы неправы, по этой причине многие остаются на php, у приведённых языков как минимум две активные версии, потому что плохая совместимость, а на новой версии пхп работают мои проекты писанные более пяти лет назад под php 4.
Я всегда обновляю версию пыха на девелоперской машине на самую свежую, использую многие нововведения языка и spl, но я протива заполнеия языка сахором из за которого затем тяжело вводить новые фичи и против сырых фич. Очень жалею. что не додумали идею о неймспейсах, плюсь от зон видимости для замыканий и то, что $this в них появился лишь с 5.4, вместо того чтобы фичу внедрить сразу законченную и задем не думать об обратных совместимостях и не мучаться с use.
Лучше меньше, но разумно, чтобы не повторять косяки джавы, питона и руби, а брать от них лишь лучшее и хорошо продуманное.
Я всегда обновляю версию пыха на девелоперской машине на самую свежую, использую многие нововведения языка и spl, но я протива заполнеия языка сахором из за которого затем тяжело вводить новые фичи и против сырых фич. Очень жалею. что не додумали идею о неймспейсах, плюсь от зон видимости для замыканий и то, что $this в них появился лишь с 5.4, вместо того чтобы фичу внедрить сразу законченную и задем не думать об обратных совместимостях и не мучаться с use.
Лучше меньше, но разумно, чтобы не повторять косяки джавы, питона и руби, а брать от них лишь лучшее и хорошо продуманное.
+4
Но ведь можно сделать опцию PHP5_COMPATIBILITY_MODE = On для поддержки старых приложений.
А то получится, что лет через 10 на PHP останутся только те, кому за 40. А «свежая кровь» пойдет стороной. Я сам уже около 10 лет работаю в основном с PHP, но мне совершенно не понятно его будущее. В каком направлении он развивается? В направлении добавления костылей? Всё это весьма печально.
А то получится, что лет через 10 на PHP останутся только те, кому за 40. А «свежая кровь» пойдет стороной. Я сам уже около 10 лет работаю в основном с PHP, но мне совершенно не понятно его будущее. В каком направлении он развивается? В направлении добавления костылей? Всё это весьма печально.
0
Потом появится PHP53_COMPATIBILITY_MODE, PHP54_COMPATIBILITY_MODE, PHP6_COMPATIBILITY_MODE? Зачем, если сейчас у разработчиков прекрасно получается и без всяких лишних опций вводить новые фичи и оставлять старые. Так что свежая кровь только прибывает, буквально сегодня на хабре была статья об увеличении популярности пыха.
Сейчас же основное развитие не в синтаксическом сахаре, а в инструментарии написанном на пыхе: деплоймент, тестирование, отслеживание качества, оптимизации скорости, связь со сторонним софтом и бд, разного рода утилиты. здесь мы достаточно сильно проигрываем руби с рельсам и это вещи независящие от авторов самого пыха.
А аксессоры, это высосанная с пальца проблема из джава мира, в пыхе есть прекрасные волшебные __get __set __call.
Сейчас же основное развитие не в синтаксическом сахаре, а в инструментарии написанном на пыхе: деплоймент, тестирование, отслеживание качества, оптимизации скорости, связь со сторонним софтом и бд, разного рода утилиты. здесь мы достаточно сильно проигрываем руби с рельсам и это вещи независящие от авторов самого пыха.
А аксессоры, это высосанная с пальца проблема из джава мира, в пыхе есть прекрасные волшебные __get __set __call.
-1
> в пыхе есть прекрасные волшебные __get __set __call.
Геттеры гораздо более понятны, прозрачны и их легче рефракторить, допустить же при использовании ошибку гораздо сложнее, т.к. IDE сама может определить что такого свойства нет, в отличии от магических костылей.
> Зачем, если сейчас у разработчиков прекрасно получается и без всяких лишних опций вводить новые фичи и оставлять старые.
Это спорно, вспомнить хотя бы довольно давнее обновление после которого preg_quote начала вдруг экранировать "-", думаете это ничего не поломало? Лично исправлял проблему из-за этого. А отключение безопасного режима, который использовался многими древними скиптами? «Волшебные» кавычки? И к чему после этого разговоры о совместимости? Еще не понятен момент — какой смысл в древних проектах использовать новые версии?
Поэтому, ИМХО, лучше всего было оставить одну долгоживущую ветку для старого и существующего софта (с фиксом ошибок), а в текущей начать исправлять то, что нагородили раньше.
Геттеры гораздо более понятны, прозрачны и их легче рефракторить, допустить же при использовании ошибку гораздо сложнее, т.к. IDE сама может определить что такого свойства нет, в отличии от магических костылей.
> Зачем, если сейчас у разработчиков прекрасно получается и без всяких лишних опций вводить новые фичи и оставлять старые.
Это спорно, вспомнить хотя бы довольно давнее обновление после которого preg_quote начала вдруг экранировать "-", думаете это ничего не поломало? Лично исправлял проблему из-за этого. А отключение безопасного режима, который использовался многими древними скиптами? «Волшебные» кавычки? И к чему после этого разговоры о совместимости? Еще не понятен момент — какой смысл в древних проектах использовать новые версии?
Поэтому, ИМХО, лучше всего было оставить одну долгоживущую ветку для старого и существующего софта (с фиксом ошибок), а в текущей начать исправлять то, что нагородили раньше.
+3
Отлично, я согласен с вашим первым тезисом, к тому же в php уже можно без проблем писать прозрачные геттеры и сетторы, а магия лишь синтаксический сахар для уменьшения дублирования, IDE можно помогать через phpdoc. Новый синтаксис всего лишь сахар и нет большой разницы внедроят его или нет.
Кавыччки и сейфмод выпиливались много лет, регулировались из конфигогв и много лет предупреждали что так делать нехорошо и это деприкейтид подходы. А так все изменения по мелочам, которые правятся за 5 минут, либо такие которые уже пару лет анансировались.
Кавыччки и сейфмод выпиливались много лет, регулировались из конфигогв и много лет предупреждали что так делать нехорошо и это деприкейтид подходы. А так все изменения по мелочам, которые правятся за 5 минут, либо такие которые уже пару лет анансировались.
0
PHP5_COMPABILITY_MODE, <?php6 и подобные штуки — это и есть костыли. Представляете, как будет сложно поддерживать и развивать сам интерпретатор?
0
В PHP хватает несовместимостей, например нерабочий htmlspecialchars в 5.4, если в него подавать cp1251 строки, так как внезапно в этой версии он стал по умолчанию считать что указано UTF-8, что сразу ломает все cp1251 приложения.
Но это ладно, проблема в том что в ini это не изменить и необходимо рефакторить приложения.
Но это ладно, проблема в том что в ini это не изменить и необходимо рефакторить приложения.
0
Именно, на кого они ориентируются? Те все равно годами ничего не обновляют, а сейчас на 5.1 с register_globals сидят, потому что видео урок не работает.
+1
> Генераторы как мимо него протолкнули интересно.
А он там не голосовал просто (https://wiki.php.net/rfc/generators), в то же время за геттеры гораздо больше народу проголосовало (https://wiki.php.net/rfc/propertygetsetsyntax-v1.2), интересно чем это вызвано и почему геттеры точно так же не протолкнули?
ЗЫ: Забавно конечно, геттеры это сложно для понимания, а генераторы нет…
А он там не голосовал просто (https://wiki.php.net/rfc/generators), в то же время за геттеры гораздо больше народу проголосовало (https://wiki.php.net/rfc/propertygetsetsyntax-v1.2), интересно чем это вызвано и почему геттеры точно так же не протолкнули?
ЗЫ: Забавно конечно, геттеры это сложно для понимания, а генераторы нет…
+1
Чего все носятся с этими аксессорами, когда есть __get/__set?
Тайп хинтинг лучше бы починили…
Тайп хинтинг лучше бы починили…
-2
Да не в аксессорах дело то, а в отношении многих контрибуторов к направлению развития языка в целом.
0
Я тоже не фанат Java way которым Symfony и ZF идут, тем не менее двигаться вперед надо, а если переживать за разработчиков которые новые элементы синтаксиса не освоят или за проекты на PHP 5.1 то ничего не выйдет.
0
Да оно-то понятно, я чертовски рад развитию языка, но меня озадачивает стоящий по интернету плач об аксессорах. Потому что я не понимаю, что такого можно сделать с ними, чего нельзя с __get/__set. А наоборот — понимаю.
Решил спросить, пользуясь случаем.
Решил спросить, пользуясь случаем.
0
__get/__set работает одновременно для всего класса.
И это печально. Ибо один метод по сути ответственный за геттеры сеттеры всех полей.
А если мы хотим добавить какой-то кастомный геттер в одно поле, а другой в другое, — придется вешать много костылей на бедный __get.
И это печально. Ибо один метод по сути ответственный за геттеры сеттеры всех полей.
А если мы хотим добавить какой-то кастомный геттер в одно поле, а другой в другое, — придется вешать много костылей на бедный __get.
+2
Я знаю чем они отличаются, но спасибо. Просто что-то мне подсказывает, что проперти, буде они появятся в языке, всё равно окажутся синтаксическим сахаром, внутри реализованным в терминах __get/__set.
А для эмуляции поведения пропертей (перечисление полей, выборочные геттеры и сеттеры) можно прямо сейчас нарисовать трейт строчек, ну, скажем, в двадцать, и пользоваться в своё удовольствие. Функционал будет ровно тем же, что вы ищете в аксессорах. Синтаксис будет чуть другой, подумаешь.
А для эмуляции поведения пропертей (перечисление полей, выборочные геттеры и сеттеры) можно прямо сейчас нарисовать трейт строчек, ну, скажем, в двадцать, и пользоваться в своё удовольствие. Функционал будет ровно тем же, что вы ищете в аксессорах. Синтаксис будет чуть другой, подумаешь.
0
Вкуснятина!
+2
дайте уже ссылку на весь список картинок со слонами…
+2
Что-то я не понял, что за новость такая, отлавливание fatal error?
Ещё 5 с лишним лет назад читал у Котерова: dklab.ru/chicken/nablas/45.html
Ещё 5 с лишним лет назад читал у Котерова: dklab.ru/chicken/nablas/45.html
+1
Ага, а вот в симфони2 она появилась 4 месяца назад :)
github.com/Koc/symfony/commit/acfc750a48d83496e342a0876ca86a9627e306b6
Fabien почему-то считал что если UB, то сообщить об этом факте на мыло не надо.
github.com/symfony/symfony/issues/2042
Вообще имхо такую вещь как сообщение о всех ошибках на мыло нужно лепить на продакшен в обязательном порядке.
github.com/Koc/symfony/commit/acfc750a48d83496e342a0876ca86a9627e306b6
Fabien почему-то считал что если UB, то сообщить об этом факте на мыло не надо.
github.com/symfony/symfony/issues/2042
Вообще имхо такую вещь как сообщение о всех ошибках на мыло нужно лепить на продакшен в обязательном порядке.
0
Отправку на мыло допилю в ближайшее время, уже есть в принципе PR на эту тему. А что значит UB?
0
> А что значит UB?
Неопределенное поведение в смысле
github.com/symfony/symfony/issues/2042#issuecomment-3328719
Я до глубины души был возмущен этим комментарием :)
Спасибо, будем ждать.
Неопределенное поведение в смысле
github.com/symfony/symfony/issues/2042#issuecomment-3328719
Я до глубины души был возмущен этим комментарием :)
Спасибо, будем ждать.
0
Ну вот почему все новые версии пестрят словами «Fix», «Hotfix», «Fix bug»? И, причём, чем новее — тем больше. Эх, а так всё красиво начиналось.
0
С другой стороны это лучше, чем framework.zend.com/changelog/2.0.2/ "#2393 Trying to solve issue" )
0
Добавили бы data caching API из APC в Zend Optimizer, делов то. Всяко проще чем собственно создание опкода.
>>using PHP in FastCGI mode with 4 worker processes.
Ну дают, APC в FastCGI режиме «теряет» кэш, вернее создаёт отдельный кэш на каждый worker, неужели они об этом не знают?
>>using PHP in FastCGI mode with 4 worker processes.
Ну дают, APC в FastCGI режиме «теряет» кэш, вернее создаёт отдельный кэш на каждый worker, неужели они об этом не знают?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дайджест интересных новостей и материалов из мира PHP за последние две недели №10 (26.01.2013 — 11.02.2013)