Комментарии 20
Правильно понимаю, что используя каррирование, можно создать функцию-обёртку с некоторым количеством аргументов, и от неё — функции с предопределёнными значениями этих некоторых аргументов?
Грубо говоря — да, хотя и не совсем так. В упоминаемой статье Кирпичева есть хорошее изложение (раздел 5, «Интуиция» и далее).
Вот эти строки:
лучше бы вытащить на уровень выше.
/* определяем число аргументов исходной функции */
$func = new ReflectionFunction($callback);
$num = $func->getNumberOfParameters();
лучше бы вытащить на уровень выше.
Вы уж извините, но это все выглядит, как:
В PHP4 было довольно слабо развито ООП. Фичи функционального программирования тогда никому не были нужны.
Сейчас на дворе PHP5 — поработали над ООП, теперь оно имеет немало возможностей. И все побежали писать велосипеды используя нововведенные closure/reflection.
Блин, для вас стараются, делают качественную поддержку ООП, чтобы вы реализовывали паттеры проектирования, концепции (H)MVC, писали более понятный и качественный код… ну вы меня поняли.
В PHP4 было довольно слабо развито ООП. Фичи функционального программирования тогда никому не были нужны.
Сейчас на дворе PHP5 — поработали над ООП, теперь оно имеет немало возможностей. И все побежали писать велосипеды используя нововведенные closure/reflection.
Блин, для вас стараются, делают качественную поддержку ООП, чтобы вы реализовывали паттеры проектирования, концепции (H)MVC, писали более понятный и качественный код… ну вы меня поняли.
Не понял вашу мысль. Разве я где-то написал, что я против ООП?
Мне мой велосипед вполне полезен для работы с array_walk, array_reduce, array_map, array_filter, usort и прочими функциями, принимающие callback-параметры. ИМХО каррирование гораздо элегантнее, чем true-OOP-way с классом с единственным методом и несколькими параметрами.
Мне мой велосипед вполне полезен для работы с array_walk, array_reduce, array_map, array_filter, usort и прочими функциями, принимающие callback-параметры. ИМХО каррирование гораздо элегантнее, чем true-OOP-way с классом с единственным методом и несколькими параметрами.
Приведите пример?
См. последний пример в статье. Насколько я понимаю, в ООП он выглядел бы примерно как
class MassCalculator {
private $density;
public function setDensity($density){...}
public function calculateMass($length){...}
}
$mass = new MassCalculator;
$mass->setDensity(7.9);
$lengths = array(3, 2, 5, 6, 1);
$masses = array_map(array($mass, "calculateMass"), $lengths);
Все равно currying не нужно. Да тут и не currying, а partal function application получается. Суть не в этом.
Решение без ООП, без ФП:
Решение с ООП, без ФП:
Решение без ООП, без ФП:
function mass($density, $length) {
return $density * pow($length, 3);
}
function steel_mass($length) {
return mass(7.9, $length);
}
Решение с ООП, без ФП:
class Physics
{
static public function mass($density, $length) {
return $density * pow($length, 3);
}
static public function steelMass($length) {
return self::mass(7.9, $length);
}
/* ... другие методы для работы над физ. свойствами ... */
}
АФАИК $f = curry(«f»); g = f(7.9); — это как раз каррирование. Вот если бы было что-то вроде $g = partial(«f», 7.9) — это было бы частичное выполнение.
Верно, если нам нужно только стальные кубы взвешивать — то в этом частном случае проще написать функцию-обертку. Но я подразумевал, что величина плотности материала может быть задана динамически.
Верно, если нам нужно только стальные кубы взвешивать — то в этом частном случае проще написать функцию-обертку. Но я подразумевал, что величина плотности материала может быть задана динамически.
в чем ваша претензия функциональной парадигме программирования? вы ведь не путаете ее с процедурной, правда?
Я имел ввиду, что в PHP оно не надо.
PHP не функциональный ЯП.
PHP не функциональный ЯП.
В текущей версии пока нет. Но надо заметить, что 4-я версия в свою очередь не была объектно-ориентированной.
Главный признак ФЯП (функции — объекты первого класса) в PHP выполнен. Так что поддержка ФП уже есть. И, как отмечено в основном тексте, налицо дальнейшие шаги разработчиков по наращиванию средств функциональной парадигмы.
Я не был бы столь категоричен: вам оно в PHP не надо, мне вот, например, надо и удобно — на вкус и цвет фломастеры разные.
Я не был бы столь категоричен: вам оно в PHP не надо, мне вот, например, надо и удобно — на вкус и цвет фломастеры разные.
Согласен.
Я все время забываю про анонимные функции 5.3+ и до сих пор на живых проектах ни разу не пользовался ими.
Для меня PHP как бы языком для создания сайтов-визиток, блогов, форумов — так и останется :)
Для остального — erlang, lua, python.
Я все время забываю про анонимные функции 5.3+ и до сих пор на живых проектах ни разу не пользовался ими.
Для меня PHP как бы языком для создания сайтов-визиток, блогов, форумов — так и останется :)
Для остального — erlang, lua, python.
Судя по документации динамическое создание функций при помощи create_function() было доступно еще в PHP 4.0.1. Они правда были не вполне анонимными — интерпретатор автоматически присваивал им свободные имена вида lambda_NNN — и в целом это сильно смахивало на eval-шаманство, но вполне работало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Еще раз о каррировании и частичном применении в PHP