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

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

[RFC] Property Accessors

Почему-то напоминает сильно Swift… Интересное предложение, с которым как и в Swift отпадает необходимость в геттерах и сеттерах, но визеры (withers) – не вымещает… Мне лично геттеры/сеттеры кажутся более правильным подходом, почему в Swift и продолжаю их использовать, хотя смысла в этом зачастую просто 0… Интересно было бы глянуть опрос за и против – gettes/setters vs property control среди пользователей...

Почему бы для аксессоров не использовать аннотации?
Полагаю потому, что аннотации так или иначе надо извлекать в рантайме для работы с ними (пусть сейчас это и удобней и является частью синтаксиса\стандартной библиотеки). А аксессоры должны работать, полагаю, на этапе преобразования в байткод (чтобы сформировать правильные методы и уровни доступа).

Т.е. если упростить, то (в моем понимании) аннотации сами по себе ничего не делают. Что-то делает некоторый инструментарий (библиотека\фреймворк\самописный код), который на основе этих аннотаций как-то модифицирует свое поведение. И применение аннотаций для контроля выполнения кода в этом случае невозможно.
(в моем понимании)
Все верно, это просто метаданные, доступные из Reflection API
Да, согласен stitcher.io/blog/attributes-in-php-8
Keep in mind the goal of attributes: they are meant to add meta data to classes and methods, nothing more.
А мне нравится черновик Никиты, надеюсь увидеть реализацию всего этого в 8.2.

по-моему, сообщество в php давно созрело для создания нормальной стандартной библиотеки, а не вот этой мешанины в глобальном неймспейсе.
так же очень полезны были бы нормальные структуры данных в ядре (https://github.com/php-ds/ext-ds).
судьба fiber-ов, и прочей асинхронщины по прежнему туманна. ведь влом stream прослойку переписывать, проще и забавнее протолкнуть очередной дурацкий сахар в синтаксис, а не заниматься реально нужными вещами.

И еще несколько мероприятий с phpcommunity.ru


[RFC] Property Accessors
Да, есть некоторые базовые моменты, которые надо бы ввести, но реализация методов в свойствах, логику прописать… И ведь там примеры на 1-2 свойства, а если подумать: что произойдет, когда добавь ты с десяток свойств и еще методы??? И будет уже не класс PHP выглядеть, а как JSON в JS. А там до функционального ада недалеко.
Субъективно: идея интересная, но не продуманная и только изуродует существующее.
но реализация методов в свойствах,

Когда термины используют криво, для удобства и все друг-друга понимают — это одно. Но назвать обычные свойства подобным образом, исковеркав вообще все возможные значения — это уже за гранью...


И это особенно абсурдно звучит, т.к. "свойство" означает "поля класса с логикой". Т.е. критикуется предложение добавить свойства в язык, где их до сих пор просто не было.


P.S. Упс, промахнулся веткой.

А речь про php? Если внимательно прочитать, то фраза звучит следующим образом (в контексте php): "свойство — это свойство, но его не было". Когда не было? Где не было? А если не было в php, то когда появилось?

А речь про 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, встало все на свои места. Ужасный и могучий php, не даёт тем же, к примеру, программистам на с# спать спокойно из за того, что php нарушает общепринятые нормы, этакий супостат!
Все ниже, что было по тексту, балалайка о трёх струнах. Короче, не убедили.

Осталось выяснить причём тут C#...

Держите в курсе

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.