Комментарии 45
А какой код кроме _do функции например сложный?
function take(int $n): Parser {
return parser(function($s) use ($n) {
return strlen($s) < $n ? Parser::FAILED : [ substr($s, 0, $n), substr($s, $n) ];
});
}
тяжело воспринимается 2-ва return и тернарный оператор не к месту к стати…
Выглядит довольно таки красиво.
К примеру
if(strlen($s) < $n) {
return Parser::FAILED;
} else {
return array(
substr($s,0,$n),
substr($s,$n)
);
}
Согласитесь выглядит более читабельней чем
return strlen($s) < $n ? Parser::FAILED : [ substr($s, 0, $n), substr($s, $n) ];
Ну и чем плох тернарный оператор, к примеру, всё просто, у вас новая вводная вам надо и при strlen($s) == $n вернуть Parser::FAILED
многие привыкшие к тенарным операторам сделают это так
return strlen($s) < $n ? Parser::FAILED : strlen($s) == $n ? Parser::FAILED : [ substr($s, 0, $n), substr($s, $n) ] ;
Что приводит к тому что человек не сразу поймёт что возвращается, становиться не очевидным просто.
автор, отличная статья, ждем продолжения?
Было бы неплохо увидеть финальный код.
И сравнить с парсером, написанным с использованием како-то другого подхода.
Лично мне код не показался очень простым и понятным. Но возможно, простота познается в сравнении, и на деле другие реализации были бы гораздо сложнее?
Кстати, по-моему, написанный парсер строковых литералов не обработает строку с двойной кавычкой внутри ("I \"am\" inside"
) :)
Финальный код приведен в конце, правда ссылку на репозиторий я похоже забыл, вот он.
Вот пример на js, правда на js и мой код выглядел бы на порядок проще, разница в тестируемости отдельных частей и декларативности.
В парсинге строк я действительно немного схалтурил :)
Ну, а по поводу знаний ООП, мусора везде хватает, на то есть эйчары и собеседования, чтобы его фильтровать, в нормальные компании такие не попадают.
Я так понимаю, вы искали среди так называемых фрилансеров, но это отдельная группа, где за редким исключение ни то что программиста, но даже человека адекватного найти тяжело. У нас же сейчас обратная ситуация, слишком много начитанных специалистов, которые любят паттерны, ddd и всякие абстракции больше, чем результат.
Но это вымирающее меньшинство
Увы, наша страна делаеи шаги отнюдь не в сторону глобализации, а сказки про злого Обамку не мотивируют учить бездуховный английский.
У нас же сейчас обратная ситуация, слишком много начитанных специалистов, которые любят паттерны, ddd и всякие абстракции больше, чем результат
Ну вот я находясь в Москве очно собеседовал людей и с паттернами\начитанностью были проблемы. Обратную сторону тоже понимаю, но, по-моему, любая книжка по паттернам пытается предупредить о том, что не стоит заболевать «паттерном головного мозга». Ну и вообще думаю, что это тоже лечится, при том проще, чем незнание. Кстати, ФП в этом плане далеко не последний инструмент. Мне когда-то помогло в определенной степени.
На самом деле ад из колбеков может и сложно дебажить, но зато отдельные чистые функции легко тестировать, а комбинаторы пишутся довольно редко, а самый стабильный код это код, который не написан.
Вы в статье очень удачно использовали объекты, тем самым продемонстрировав, что ООП не отменяет функциональных подходов, а очень удачно дополняется ими.
На самом деле в этом примере ООП не используется, а класс используется только ради инфиксной нотации ($this->orElse($that)
вместо orElse($this, $that)
).
А у ООП достаточно недостатков, начиная от хрупкости базового класса. Это видно даже в количестве паттернов, большей части из которых в функциональной парадигме просто нет, за ненадобностью.
90% PHP-программистов пост-советского пространства и с ООП совладать не в силе…
В 90% ваш ООП не нужен.
Взяли за идею, мол ООП корова, которая спасет мир. Но это не так.
Нужно задачу решать самым простым способом, а не городить огород.
Не сказал бы, что DDD может быть использовано исключительно с ООП, наоборот, мне кажется описание действий, которые можно производить с данными более гибко, чем попытка определить какому объекту действие принадлежит.
Нефтяная труба и ящик помидоров это тоже данные, функциональный подход прекрасно справляется с такими сущностями, зато не возникает вопросов "сьесть" это метод человека или помидора? Или еще хуже, чей метод "создать продукт питания"?
А что там внутри длинна/ширина это нас не должно волновать, абстракция там тоже есть.
Возьмем для примера чистый функциональный язык Haskell, в нем делается так:
module Fruits (Tomato, grow, eat) where
data Tomato = Tomato String Int
grow weight = Tomato "Good one" weight
eat (Tomato name _) = name ++ " was good"
Извне модуля видно только имя типа Tomato
и функции, внутренняя структура абстрагирована.
Полиморфизм тут тоже есть, если интересно, называется Type Classes.
А еще не будете решать за сообщество, которое почему-то внезапно в большинстве своем использует ООП — наверное не просто так, м?
Мне сложно общаться с людьми, которые меняют свое мнение на лету.
Ты уж определись, либо 90% не могут совладать с ООП, либо сообщество только ООП использует. А то, я тебя не понимаю.
И не надо ванговать, что и кто лучше знает, я тут своими знаниями не делился.
Ты уж определись, либо 90% не могут совладать с ООП, либо сообщество только ООП использует
Если у тебя не достаточно логических способностей понять, что сообщество программистов не ограничивается только российскими программистами и то, что люди часто используют то, чего не понимают(ООП — как пример) это твои проблемы. Это если не учитывать, что я ни разу не сказал, что сообщество использует ТОЛЬКО ООП. Что-то я не вижу от тебя ни одной публикации по ФП, так что собирай свой жир и иди троллить куда-нибудь в другое место.
Ты делаешь утверждение, что 90% Похапэшников в СНГ, не могут совладать с ООП.
1. Какое сообщество программистов? Ты четко указал, что мы говорим о СНГ. И что в СНГ 90% похапэшников, не могут в ООП.
2. Выходя из пункта 1, ты не следишь, за тем что пишешь.
3. Довод, что я не пишу тут статьи, просто смешон.
Прошу не пиши мне больше, я общаюсь с адекватными людьми.
Спасибо.
Какое сообщество программистов? Ты четко указал, что мы говорим о СНГ. И что в СНГ 90% похапэшников, не могут в ООП.
А, то есть ты решил взять 2 разных комментария, написанных в 2х разных контекстах, 2м разным людям, вырвать их из контекста и обвинить меня в том, что я мол за своими словами не слежу. Позволю себе такой же «опус».
я общаюсь с адекватными людьми
Но это не так
Ну и иди общайся со своими неадекватами, клоун.
Не надо натягивать чисто функциональный подход на PHP. Выглядит убого.
Познавательно, но не ясен практический профит. Использовать такое в проекте, учитывая что для большинства это действительно выглядит абракадаброй не резон. Просто по факту что так можно на php и в качестве головоломки...
$pair = _do(function() use (&$jValue,&$result) {
$key = yield takeOf('\\w');
yield literal(':');
$value = yield $jValue;
$result[$key] = $value;
return true;
});
yield $pair->separatedBy(literal(','));
а как с автокомплитом метода separatedBy в IDE ?
Функции высших порядков и монады для PHP`шников