How to become an author
Search
Write a publication
Pull to refresh

Comments 19

И RFC атрибуты и simple annotation просто ужасны, синтаксис и то как преподнесена идея аннотаций.
Total votes 5: ↑4 and ↓1+3
dim_s ничего не поделаешь, нужен синтаксис совместимый с php, а не совершенно отдельный язык в языке, как в случае с доктриной. Собственно в самих RFC об этом сказано, а синтаксис выбран из уже существующих языков (Hack). p.s. прошу прощения за ответ в основном треде, а не на коммент — мобильный клиент, он такое не умеет.
This comment wasn’t rated yet0
>> и << являются операторами сдвига, ничего совместимого с синтаксисом не вижу. В питоне декораторы начинаются с @, в Java аннотации с @, в Dart аннотации тоже с @, а то что они предлагают, причем там еще и expression это полный бред. Аннотации это декларативность, а не императивность!
Total votes 3: ↑3 and ↓0+3
абсолютно согласен. тащат из других языков, но каверкают на свой лад. например namespace separator. зачем "\"?
This comment wasn’t rated yet0

Потому что во времена php 5.x лексер не умел такие штуки разруливать. В php7 в качестве разделителя нэймспейсов можно юзать уже точки к примеру, но уже обратная совместимость...

This comment wasn’t rated yet0
а аннотации? в 5 их не было, но это не мешает сделать их в стремном виде. этот пайп оператор опять же — а чем просто | плохо? у них же теперь контектно-зависимый парсер, он в курсе, что палка это пайп, а не ИЛИ.
Total votes 2: ↑0 and ↓2-2

А что делать в тех случаях, когда нужна "функия_а или функция_б"? Из какого контекста лексер будет исходить? Мысли разработчика он читать не умеет. ;)

Total votes 1: ↑1 and ↓0+1
например namespace separator. зачем "\"?

Тогда я вас не понял вообще.

This comment wasn’t rated yet0

Точки нельзя, и даже не из-за лексера. Т.к. конфликтует с конкатенацией дефайнов, тоже самое и с прямым слешем — деление дефайнов. Раньше (в php 6) думали над двойным двоеточием, но под конец убрали, из-за проблем с вложенными классами (напоминаю, в php7 можно чейнить статик методы через A::b()::c(), но резолв класса из константы пока не работает, в будущем, предполагаю, поправят, так что получится A::b::c, где b и с — константы класса).


Если уж ругаться на что-то, то на оператор конкатенации, вместо плюса, который решает тучу проблем с приведением типов (вспомним JS и его дикий угар с оператором "+"). Отсюда и переиначивание, берут то что есть в других языках, но делают так, чтобы это не было проблемой в будущем, как, например с дженериками в джаве (https://www.youtube.com/watch?v=HE4yyPpUsy4).


Предполагаю, что отсюда и именование аннотаций, пусть и не очень красиво (хотя я бы сказал просто непривычно), но зато консистентно и не будет проблем как, например сейчас с ассоциативными массивами, синтаксис которых был взят под копирку из перла. Хотя, предполагаю, что "двойные скобки" добавят проблем с операторами сдвига в подходах с контрактным программированием.


Короче, я к чему, такой "необычный" синтаксис не потому, что авторы упоролись, а потому что они сидели и долго думали, проектируя язык так, чтобы в будущем не возникало проблем в развитии и введении необходимых фич.

Total votes 2: ↑2 and ↓0+2
после такого аргумента, им уже можно все простить ;)
Total votes 1: ↑1 and ↓0+1
Pipe Operator однозначное зло. Уж лучше бы вмержили расширение scalar_objects Никиты Попова, которое решает ту же самую проблему сильно элегантнее.
Total votes 5: ↑4 and ↓1+3

Цитата из статьи:


позволит записывать цепочки вложенных вызовы в более читаемом виде

Экстеншн scalar_objects решает именно эту проблему.
Сорри, это пример плохой в статье приведён с array_fitler и array_map. В самом RFC гораздо более продуктивный пример, который действительно через scalar_objects не решить

This comment wasn’t rated yet0
Вот нет, scalar_objects решает другую:

This extension implements the ability to register a class that handles the method calls to a certain primitive type (string, array, ...). As such it allows implementing APIs like $str->length().

Total votes 1: ↑1 and ↓0+1
Pipe Operator однозначное зло.

когда кто-то завяляет об "однозначности" зла — стоит задуматься в том сколько человек обдумывал эту идею или это чистой воды субъективизм.


Уж лучше бы вмержили расширение scalar_objects Никиты Попова, которое решает ту же самую проблему сильно элегантнее.

Вот только давайте подумаем… pipe-оператор не требует изменения кода, решение от Никиты — требует как минимум обертки. Не знаю как вы, а мне pipe-оператор дико нравится, хоть с функциональными выражениями было бы намного лучше:


$ret = scandir($arg)
    |> array_filter($$, $x => $x !== '.' && $x != '..' })
    |> array_map($x => $arg . '/' . $x, $$)
    |> getFileArg($$)
    |> array_merge($ret, $$);

Ну и выбор $$ в качестве плэйсхолдера сомнителен, _ как в JS выглядит уже приятнее и логичнее.


Опять же посмотрим внимательно на пример выше. Предположим что с filter/map никаких проблем, они уже есть в хэндлерах для массивов. Далее допустим мы array_merge можем заменить на concat тот же. А что делать с getFileArg? Выходит пока так:



return $ret->concat(
   getFileArg(
      scandir($arg)
         ->filter(function($x) { return $x !== '.' && $x != '..'; })
         ->map(function ($x) use ($arg) { return $arg . '/' . $x; })
));

Как-то это не сильно решает проблему. И добавлять getFileArg как хэндлер ЛЮБЫХ массивов явно мы не можем. Делать объектную обертку? Зачем, чистая функция, зачем ее в объект заворачивать...


Словом я двумя руками за, это позволит сильно упростить код некоторых методов моих объектов.

Total votes 1: ↑1 and ↓0+1

Блин, ну я же там написал уже, что вот эти вот array_map и array_filter через пайп оператор ну прямо скажем что неудобно.
Что касается остального — полностью согласен.
Одним словом я не против пайп-оператора, я против того чтобы его наличие стало аргументов против вмерживания scalar_objects.

This comment wasn’t rated yet0
через пайп оператор ну прямо скажем что неудобно.

Более чем удобно, мне только плэйсхолдер не нравится и отсутствие лямбд. А так — удобно) просто попробуйте)


Вообще надо бы реализовать это дело на yay.


я против того чтобы его наличие стало аргументов против вмерживания scalar_objects.

я не против scalar_objects, я против того что бы убирали возможность работать просто с функциями и против того что бы пользователи могли из userland "манкипатчить" скаляры добавляя свои обработчики.

This comment wasn’t rated yet0

Прокомментирую, пожалуй, про PHP-FIG. Разлада как такового нет. Покинули группу те, кто достигли своих целей или кто не может найти времени на обсуждения.


CDS пока занятен, но очень хаотичный. Посмотрим, что из него получится.

Total votes 5: ↑5 and ↓0+5
Пасиба за комментарий, обновил текст.
Total votes 1: ↑1 and ↓0+1
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr