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: |

Newly uncovered hack campaign in Telegram

The campaign, which security firm Check Point has named Rampant Kitten, comprises two main components, one for Windows and the other for Android. Rampant Kitten’s objective is to steal Telegram messages, passwords, and two-factor authentication codes sent by SMS and then also take screenshots and record sounds within earshot of an infected phone, the researchers said in a post published on Friday.

Telegram auto-delete message, expiring invites, and more

elegram is updating its messaging app with options for auto-deleting messages, expiring invite links, and new unlimited groups, the company shared in a blog post. Much like Signal, Telegram received a burst of new users in the confusion over WhatsApp’s privacy policy and now the company is adopting features that were already part of its competitors’ apps, features which offer more security and privacy. Auto-deleting messages were already possible in Telegram’s encrypted Secret Chats, but this new update for iOS and Android adds the option to make messages disappear in any kind of chat. Auto-delete can be enabled inside of chats, and set to delete either 24 hours or seven days after messages are sent. Auto-delete won’t remove every message though; if a message was sent before the feature was turned on, it’ll stick around. Telegram’s competitors have had similar features: WhatsApp introduced a feature in 2020 and Signal has had disappearing messages since at least 2016.

PHP Digest from tr


Telegram PHP Digest
FROM USA