Comments 19
Чего только не предлагают, абы generics не пилить)
Но в целом весь тот «сахар» лишним не будет, лишь бы производительность не просела и обратной не совместимости не было большой, никто ж не заставляет юзать / переписывать код под восьмёрку.
А вот по этому поводу
One thing that particularly annoys me about naming is this silly `-able` suffix trend for interface names. Let's stop it.
️ JsonSerializable -> CastsToJson
️Identifiable -> HasIdentity
️ Taggable -> ProvidesTags
️ Emailable -> EmailMessage
Не поняли в чем его проблема с able. Diversity что-ли очень нужно и тут?
Сейчас надо запомнить основу (tag, email, identify) и один суффикс на всех. Вместо этого предлагается запоминать вместо одного able целую кучу допов — provided, has, message, при этом суть не меняется…
able vs Has = has более понятный и точный как правило. able — это всё таки возможность, то есть User implements Identifiable можно понять как "у пользователя может быть идентичность (калька)", User implements HasIdentity только как "у пользователя есть идентичность". Естественно подразумевается ситуация, когда в интерфейсе тип результата getIdentity описан как : Inentity, а не : ?Inentity
Опыт каких фич, например?
??= — это объединение ?? и =
?? используется, например, в С#, JavaScript, Swift
https://en.wikipedia.org/wiki/Null_coalescing_operator
То что вам может не нравиться синтаксис — это понятно и нормально. Вопросы к "опыт реализации прошлых фич шепчет что опять какую то дичь придумают «чтобы не как в C/JAVA» =".
чтобы не как в C/JAVAОбычно так делают учитывая ошибки
В Котлине например так делали крутые фичи… и да, некоторые у них не взлетели так, как задумывал, но все же это движение вперед
С енамом то че ошибаться? :)
Ну да, ведь дело обычно не в отличающемся синтаксисе, проблемах с парсингом и обратной совместимости, а именно «чтобы не как в C/JAVA»
Забавный факт
А также подробный ответ Никиты в Internals.
А ссылка ведёт на
https://externals.io/message/110004#110018
Очень PHP-шно :)
В PHP 8 с именованными аргументами:
Именно в этом примере ярко демонстрируется проблема: в названии поля meail сделана опечатка и чтобы это исправить вам придется так же сделать релевантную правку в вашем API (точней она была уже сделана, если этот код работает), который в предыдущем примере был абсолютно независимым.
Но скрестив два этих RFC вместе получаем двойную проблему — мало того что имена параметров — теперь часть API, так еще и при неудачном использовании даже приватные поля класса становятся частью API, т.к. описываются через именованные параметры.
Я не то чтобы против этих нововведений, но пример, на мой взгляд, совсем не демонстрирует их преимущества, а даже наоборот — выставляет в негативном свете.
PHP-Дайджест № 184 (6 – 20 июля 2020)