Telegram Group & Telegram Channel
Forwarded from Пых (Валентин Удальцов)
#[<T>] Дженерики через атрибуты

Роман Пронский в своём блоге предлагает реализовать стираемые дженерики путём расширения синтаксиса атрибутов.

Ход мысли такой. Сейчас мы описываем общие типы для Psalm и PHPStan в phpdoc-ах, то есть, по сути, и используем стираемые дженерики, только с не особо стандартизованным синтаксисом и в комментариях, КАРЛ. А ещё у нас есть атрибуты — синтаксис в PHP, предназначенный для метаинформации. Так почему бы нам не объединить две эти вещи? Так как атрибуты в текущем виде слабо подходят для типизации, Рома предлагает расширить их синтаксис, в частности, разрешить ставить атрибуты над выражениями и перед типом возвращаемого значения.

https://pronskiy.com/blog/generics-via-attributes-in-php/

Я считаю, что это интересный альтернативный взгляд на дженерики в PHP, но с ним связано несколько проблем:

1. Нарушение принципа единой отвественности для атрибутов. Мы либо получим неоднозначность в определении понятия "атрибут", либо просто дженерики с похожим синтаксисом.

2. Инстанциированные атрибуты можно получить только через рефлексию. Рефлексия — это рантайм и автолоадинг. Статанализ же в идеале вообще не должен запускать анализируемый код. Именно поэтому появились такие проекты, как PHP Parser и Better Reflection. Если же обновлённые атрибуты будут использоваться только как синтаксис, то нет смысла их называть атрибутами.

3. Приведенную в статье декларацию атрибута-дженерика над выражением вообще не получится отрефлексировать, поскольку для выражений по определению невозможна рефлексия. Из-за этого синтаксис дженериков может быть реализован только на уровне языка.

Получается, что замаскированные под атрибуты дженерики технически не смогут ими быть. Ну а в таком случае проще реализовать стираемые дженерики с привычным синтаксисом array<string, object>. Если же по каким-то техническим причинам необходимо оборачивать декларации в #[], то пусть это просто будут дженерики с таким синтаксисом.

Что касается самой концепции стираемых дженериков, я её однозначно поддерживаю. Да, такой подход требует наличия внешнего анализатора, но взамен даёт стандартизированный синтаксис, нативный парсинг кода с дженериками и популяризацию обобщённого программирования среди PHP-разработчиков.

Я очень рад, что Рома в очередной раз подогрел дискуссию вокруг дженериков. Любой подобный движ полезен для сообщества и приближает нас к результату.
👍32🔥27🤔8😢8



tg-me.com/phpdigest/299
Create:
Last Update:

#[<T>] Дженерики через атрибуты

Роман Пронский в своём блоге предлагает реализовать стираемые дженерики путём расширения синтаксиса атрибутов.

Ход мысли такой. Сейчас мы описываем общие типы для Psalm и PHPStan в phpdoc-ах, то есть, по сути, и используем стираемые дженерики, только с не особо стандартизованным синтаксисом и в комментариях, КАРЛ. А ещё у нас есть атрибуты — синтаксис в PHP, предназначенный для метаинформации. Так почему бы нам не объединить две эти вещи? Так как атрибуты в текущем виде слабо подходят для типизации, Рома предлагает расширить их синтаксис, в частности, разрешить ставить атрибуты над выражениями и перед типом возвращаемого значения.

https://pronskiy.com/blog/generics-via-attributes-in-php/

Я считаю, что это интересный альтернативный взгляд на дженерики в PHP, но с ним связано несколько проблем:

1. Нарушение принципа единой отвественности для атрибутов. Мы либо получим неоднозначность в определении понятия "атрибут", либо просто дженерики с похожим синтаксисом.

2. Инстанциированные атрибуты можно получить только через рефлексию. Рефлексия — это рантайм и автолоадинг. Статанализ же в идеале вообще не должен запускать анализируемый код. Именно поэтому появились такие проекты, как PHP Parser и Better Reflection. Если же обновлённые атрибуты будут использоваться только как синтаксис, то нет смысла их называть атрибутами.

3. Приведенную в статье декларацию атрибута-дженерика над выражением вообще не получится отрефлексировать, поскольку для выражений по определению невозможна рефлексия. Из-за этого синтаксис дженериков может быть реализован только на уровне языка.

Получается, что замаскированные под атрибуты дженерики технически не смогут ими быть. Ну а в таком случае проще реализовать стираемые дженерики с привычным синтаксисом array<string, object>. Если же по каким-то техническим причинам необходимо оборачивать декларации в #[], то пусть это просто будут дженерики с таким синтаксисом.

Что касается самой концепции стираемых дженериков, я её однозначно поддерживаю. Да, такой подход требует наличия внешнего анализатора, но взамен даёт стандартизированный синтаксис, нативный парсинг кода с дженериками и популяризацию обобщённого программирования среди PHP-разработчиков.

Я очень рад, что Рома в очередной раз подогрел дискуссию вокруг дженериков. Любой подобный движ полезен для сообщества и приближает нас к результату.

BY PHP Digest




Share with your friend now:
tg-me.com/phpdigest/299

View MORE
Open in Telegram


PHP Digest Telegram | DID YOU KNOW?

Date: |

What is Telegram Possible Future Strategies?

Cryptoassets enthusiasts use this application for their trade activities, and they may make donations for this cause.If somehow Telegram do run out of money to sustain themselves they will probably introduce some features that will not hinder the rudimentary principle of Telegram but provide users with enhanced and enriched experience. This could be similar to features where characters can be customized in a game which directly do not affect the in-game strategies but add to the experience.

What is Secret Chats of Telegram

Secret Chats are one of the service’s additional security features; it allows messages to be sent with client-to-client encryption. This setup means that, unlike regular messages, these secret messages can only be accessed from the device’s that initiated and accepted the chat. Additionally, Telegram notes that secret chats leave no trace on the company’s services and offer a self-destruct timer.

PHP Digest from de


Telegram PHP Digest
FROM USA