Комментарии 17
[RFC] Property Accessors
Почему-то напоминает сильно Swift… Интересное предложение, с которым как и в Swift отпадает необходимость в геттерах и сеттерах, но визеры (withers) – не вымещает… Мне лично геттеры/сеттеры кажутся более правильным подходом, почему в Swift и продолжаю их использовать, хотя смысла в этом зачастую просто 0… Интересно было бы глянуть опрос за и против – gettes/setters vs property control среди пользователей...
Т.е. если упростить, то (в моем понимании) аннотации сами по себе ничего не делают. Что-то делает некоторый инструментарий (библиотека\фреймворк\самописный код), который на основе этих аннотаций как-то модифицирует свое поведение. И применение аннотаций для контроля выполнения кода в этом случае невозможно.
(в моем понимании)Все верно, это просто метаданные, доступные из Reflection API
Keep in mind the goal of attributes: they are meant to add meta data to classes and methods, nothing more.
по-моему, сообщество в php давно созрело для создания нормальной стандартной библиотеки, а не вот этой мешанины в глобальном неймспейсе.
так же очень полезны были бы нормальные структуры данных в ядре (https://github.com/php-ds/ext-ds).
судьба fiber-ов, и прочей асинхронщины по прежнему туманна. ведь влом stream прослойку переписывать, проще и забавнее протолкнуть очередной дурацкий сахар в синтаксис, а не заниматься реально нужными вещами.
Уже спрашивали мейнтейнера
https://github.com/php-ds/ext-ds/issues/156
- Большой стрим с Никитой Поповым, Дмитрием Елисеевым, Валентином Удальцовым, Сергеем Жуком и другими интересными людьми из сообщества — 27 февраля. Будет пара докладов, несколько обсуждений, и розыгрыш призов: фирменных слонов и не только.
- Офлайн встреча PHP-чата Йошкар-Олы — 11 феварля. Посиделки с обсуждениями в баре, уже заявлена пара тем + можно докинуть свою.
- Офлайн встреча PHP-чата Воронежа — 20 февраля. Посиделки с обсуждениями в баре, программа формируется.
Да, есть некоторые базовые моменты, которые надо бы ввести, но реализация методов в свойствах, логику прописать… И ведь там примеры на 1-2 свойства, а если подумать: что произойдет, когда добавь ты с десяток свойств и еще методы??? И будет уже не класс PHP выглядеть, а как JSON в JS. А там до функционального ада недалеко.
Субъективно: идея интересная, но не продуманная и только изуродует существующее.
но реализация методов в свойствах,
Когда термины используют криво, для удобства и все друг-друга понимают — это одно. Но назвать обычные свойства подобным образом, исковеркав вообще все возможные значения — это уже за гранью...
И это особенно абсурдно звучит, т.к. "свойство" означает "поля класса с логикой". Т.е. критикуется предложение добавить свойства в язык, где их до сих пор просто не было.
P.S. Упс, промахнулся веткой.
А речь про php?
Речь про общепринятую во всём мире терминологию.
В PHP "поля" называются properties ("свойствами"), но не реализуют свойства, а являются обычными полями. Ваш капитан =)
Это было сделано для того, чтобы когда в нём (в PHP) появятся настоящие свойства — не переименовывать половину API рефлексии. Так же как как "анонимные функции" называются "замыканиями", но могут вообще не быть ими. И названо так для обеспечения совместимости, когда объект типа Closure ("замыкание") в некоторых случаях реализует настоящие замыкание (например, с помощью arrow function или use).
И RFC, предлагающий добавить наконец в PHP полноценную реализацию свойств, именно так, как они и должны примерно выглядеть ( https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5) ). На что комментарий, вида "зачем в PHP нужны свойства, ведь это всё переусложняет", напичканный совершенно неуместной и неподходящей терминологией, когда в тоже время — язык изначально проектировался и именовался, исходя из подобных будущих изменений.
PHP Дайджест № 198 (25 января – 8 февраля 2021)