Как стать автором
Обновить

Комментарии 30

А ведь у меня были планы на вечер…
PHP 6 Pissing in the Wind
Не нравится мне этот Зеев, одно и то же везде толдычит: «мы не будем делать аксессоры, потому что PHP программистам придется учить еще одну фичу.»
Что это за подход вообще? Генераторы как мимо него протолкнули интересно.
Именно по этой причине масса PHP-программитов постоянно смотрят в сторону Python, Ruby и др.
По идее можно было бы сделать форк PHP, но похоже оно особо никому и не надо.
Вопрос скорее не в фичах, а в их реализациях.
Если бы самые крутые РНРшники, принимающие PSR, знали Си и могли хакать РНР как они захотят, то через 1-2 итерации мы получили бы Джаву. Ну и зачем?
Очень точно подмечено насчёт Java. Смотрю на PSR последние и Symfony2 и вижу Java.
Вы неправы, по этой причине многие остаются на php, у приведённых языков как минимум две активные версии, потому что плохая совместимость, а на новой версии пхп работают мои проекты писанные более пяти лет назад под php 4.

Я всегда обновляю версию пыха на девелоперской машине на самую свежую, использую многие нововведения языка и spl, но я протива заполнеия языка сахором из за которого затем тяжело вводить новые фичи и против сырых фич. Очень жалею. что не додумали идею о неймспейсах, плюсь от зон видимости для замыканий и то, что $this в них появился лишь с 5.4, вместо того чтобы фичу внедрить сразу законченную и задем не думать об обратных совместимостях и не мучаться с use.

Лучше меньше, но разумно, чтобы не повторять косяки джавы, питона и руби, а брать от них лишь лучшее и хорошо продуманное.
Но ведь можно сделать опцию PHP5_COMPATIBILITY_MODE = On для поддержки старых приложений.
А то получится, что лет через 10 на PHP останутся только те, кому за 40. А «свежая кровь» пойдет стороной. Я сам уже около 10 лет работаю в основном с PHP, но мне совершенно не понятно его будущее. В каком направлении он развивается? В направлении добавления костылей? Всё это весьма печально.
Потом появится PHP53_COMPATIBILITY_MODE, PHP54_COMPATIBILITY_MODE, PHP6_COMPATIBILITY_MODE? Зачем, если сейчас у разработчиков прекрасно получается и без всяких лишних опций вводить новые фичи и оставлять старые. Так что свежая кровь только прибывает, буквально сегодня на хабре была статья об увеличении популярности пыха.
Сейчас же основное развитие не в синтаксическом сахаре, а в инструментарии написанном на пыхе: деплоймент, тестирование, отслеживание качества, оптимизации скорости, связь со сторонним софтом и бд, разного рода утилиты. здесь мы достаточно сильно проигрываем руби с рельсам и это вещи независящие от авторов самого пыха.

А аксессоры, это высосанная с пальца проблема из джава мира, в пыхе есть прекрасные волшебные __get __set __call.
> в пыхе есть прекрасные волшебные __get __set __call.

Геттеры гораздо более понятны, прозрачны и их легче рефракторить, допустить же при использовании ошибку гораздо сложнее, т.к. IDE сама может определить что такого свойства нет, в отличии от магических костылей.

> Зачем, если сейчас у разработчиков прекрасно получается и без всяких лишних опций вводить новые фичи и оставлять старые.

Это спорно, вспомнить хотя бы довольно давнее обновление после которого preg_quote начала вдруг экранировать "-", думаете это ничего не поломало? Лично исправлял проблему из-за этого. А отключение безопасного режима, который использовался многими древними скиптами? «Волшебные» кавычки? И к чему после этого разговоры о совместимости? Еще не понятен момент — какой смысл в древних проектах использовать новые версии?

Поэтому, ИМХО, лучше всего было оставить одну долгоживущую ветку для старого и существующего софта (с фиксом ошибок), а в текущей начать исправлять то, что нагородили раньше.
Отлично, я согласен с вашим первым тезисом, к тому же в php уже можно без проблем писать прозрачные геттеры и сетторы, а магия лишь синтаксический сахар для уменьшения дублирования, IDE можно помогать через phpdoc. Новый синтаксис всего лишь сахар и нет большой разницы внедроят его или нет.

Кавыччки и сейфмод выпиливались много лет, регулировались из конфигогв и много лет предупреждали что так делать нехорошо и это деприкейтид подходы. А так все изменения по мелочам, которые правятся за 5 минут, либо такие которые уже пару лет анансировались.
PHP5_COMPABILITY_MODE, <?php6 и подобные штуки — это и есть костыли. Представляете, как будет сложно поддерживать и развивать сам интерпретатор?
В PHP хватает несовместимостей, например нерабочий htmlspecialchars в 5.4, если в него подавать cp1251 строки, так как внезапно в этой версии он стал по умолчанию считать что указано UTF-8, что сразу ломает все cp1251 приложения.
Но это ладно, проблема в том что в ini это не изменить и необходимо рефакторить приложения.
Именно, на кого они ориентируются? Те все равно годами ничего не обновляют, а сейчас на 5.1 с register_globals сидят, потому что видео урок не работает.
> Генераторы как мимо него протолкнули интересно.

А он там не голосовал просто (https://wiki.php.net/rfc/generators), в то же время за геттеры гораздо больше народу проголосовало (https://wiki.php.net/rfc/propertygetsetsyntax-v1.2), интересно чем это вызвано и почему геттеры точно так же не протолкнули?

ЗЫ: Забавно конечно, геттеры это сложно для понимания, а генераторы нет…

Чего все носятся с этими аксессорами, когда есть __get/__set?
Тайп хинтинг лучше бы починили…
Да не в аксессорах дело то, а в отношении многих контрибуторов к направлению развития языка в целом.
Я тоже не фанат Java way которым Symfony и ZF идут, тем не менее двигаться вперед надо, а если переживать за разработчиков которые новые элементы синтаксиса не освоят или за проекты на PHP 5.1 то ничего не выйдет.
Да оно-то понятно, я чертовски рад развитию языка, но меня озадачивает стоящий по интернету плач об аксессорах. Потому что я не понимаю, что такого можно сделать с ними, чего нельзя с __get/__set. А наоборот — понимаю.
Решил спросить, пользуясь случаем.
__get/__set работает одновременно для всего класса.
И это печально. Ибо один метод по сути ответственный за геттеры сеттеры всех полей.
А если мы хотим добавить какой-то кастомный геттер в одно поле, а другой в другое, — придется вешать много костылей на бедный __get.
Я знаю чем они отличаются, но спасибо. Просто что-то мне подсказывает, что проперти, буде они появятся в языке, всё равно окажутся синтаксическим сахаром, внутри реализованным в терминах __get/__set.

А для эмуляции поведения пропертей (перечисление полей, выборочные геттеры и сеттеры) можно прямо сейчас нарисовать трейт строчек, ну, скажем, в двадцать, и пользоваться в своё удовольствие. Функционал будет ровно тем же, что вы ищете в аксессорах. Синтаксис будет чуть другой, подумаешь.
дайте уже ссылку на весь список картинок со слонами…
НЛО прилетело и опубликовало эту надпись здесь
Что-то я не понял, что за новость такая, отлавливание fatal error?
Ещё 5 с лишним лет назад читал у Котерова: dklab.ru/chicken/nablas/45.html
Ага, а вот в симфони2 она появилась 4 месяца назад :)
github.com/Koc/symfony/commit/acfc750a48d83496e342a0876ca86a9627e306b6
Fabien почему-то считал что если UB, то сообщить об этом факте на мыло не надо.
github.com/symfony/symfony/issues/2042
Вообще имхо такую вещь как сообщение о всех ошибках на мыло нужно лепить на продакшен в обязательном порядке.
Отправку на мыло допилю в ближайшее время, уже есть в принципе PR на эту тему. А что значит UB?
> А что значит UB?
Неопределенное поведение в смысле
github.com/symfony/symfony/issues/2042#issuecomment-3328719
Я до глубины души был возмущен этим комментарием :)

Спасибо, будем ждать.
Ну вот почему все новые версии пестрят словами «Fix», «Hotfix», «Fix bug»? И, причём, чем новее — тем больше. Эх, а так всё красиво начиналось.
Добавили бы data caching API из APC в Zend Optimizer, делов то. Всяко проще чем собственно создание опкода.
>>using PHP in FastCGI mode with 4 worker processes.
Ну дают, APC в FastCGI режиме «теряет» кэш, вернее создаёт отдельный кэш на каждый worker, неужели они об этом не знают?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий