Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 322
Let the holy war begin!
Не удивили
Урок русского языка в грузинской школе. Учительница:
— Дэти, это нэльзя понять, это надо запомнить: ОТ ВАС пишется раздельно, а КВАС — вместе.
— Дэти, это нэльзя понять, это надо запомнить: ОТ ВАС пишется раздельно, а КВАС — вместе.
Дети это нельзя понять, єто надо запомнить
слова вилька и тарелька пишутся с мягким знаком, а сол и фасол — без.
слова вилька и тарелька пишутся с мягким знаком, а сол и фасол — без.
— Дэти, самый нэпонятный русский слово эсть «груст»! Это нэ тот груст, который грыб, а тот который тоска. И нэ тот тоска, который шашлик рэжищ, а тот, когда пичално-пичално.
— Ос — это такой полосатый мух, а еще вокруг него вертится Зэмля
нэ тот тоска, что строит, а тот, что пэщаль. Но нэ тот пэщаль, что ружье. Ну и так далее.
habrahabr.ru/post/142140/ — здесь уже много сказано. В том числе и это. Автор (как и переводчик), очевидно, не в курсе того, что там изложено, и сейчас ему явилось откровение. И этот момент показывают, что они лишь поверхностно владеют проблемой.
Не знаю за автора, но переводчик изложенное по ссылке пог бы рассказать и пять лет тому назад. Тэги я не зря расставил ;)
Считайте этот перевод tl;dr для приведенной ссылки.
Считайте этот перевод tl;dr для приведенной ссылки.
А почему тогда не сказали своими словами?
Сказал что?
То, что по ссылке, я говорил на разных форумах и в разных комментариях
То, что перевел, я перевел, потому что понравился такой вот tl;dr
То, что по ссылке, я говорил на разных форумах и в разных комментариях
То, что перевел, я перевел, потому что понравился такой вот tl;dr
Нет, ну а в чем смысл?
Ну да, есть в PHP несостыковки. Они серьезно так сильно лично вам жить мешают, раз аж на многих форумах пишете?
Ну да, есть в PHP несостыковки. Они серьезно так сильно лично вам жить мешают, раз аж на многих форумах пишете?
Когда возникает вопрос о недостатках РНР, тогда я и пишу. Не надо приписывать мне действия и задчаи, которые я не делаю и не ставлю
Кстати, хочу вот заметить, что пока читал статью понял что за дискомфорт я постоянно ощющал. Все вот эти безсистемно названные функции, аргументы, давно бесило. Даже был удивлен появлению новых фич которые мне были нужны, в новых версиях пхп.
Т.е. получается, что Вы стараетесь для людей, которые не смогли осилить важную статью для языка, на котором они пишут? Вы уверены, что Вам именно это нужно?
Благодаря такой простой заметке, до большего числа людей донесутся светлые мысли статьи по ссылке. Всем только польза от этого.
Чуть ли не 10 лет назад читал статью про Perl vs PHP, там это тоже было, да.
Что ж все в этой статье такое нашли.
Там треть притянуто за уши, треть спорно, и только треть — ценная информация.
Там треть притянуто за уши, треть спорно, и только треть — ценная информация.
Вы уже заебали.
И что дальше?
В чём прикол?
Традиционная для PHP несогласованность функций стандартной библиотеки. Прикол, мягко говоря, баянистый.
Разный порядок аргументов у двух функций, которые выполняют очень похожие действия.
Как следствие, они не взаимозаменяемы и callback на эти функции нельзя передавать как аргумент для другой функции. Хотя такая возможность должна быть.
Как следствие, они не взаимозаменяемы и callback на эти функции нельзя передавать как аргумент для другой функции. Хотя такая возможность должна быть.
Эти функции не взаимозаменяемы по определению или я чего-то не понимаю?
Они не взаимозаменяемы, если их вызывать не непосредственно, а через переданный callback.
Или лучше раскройте пример, где Вы будете использовать разные array_ функции через указатель?
Кстати, в php функции не передаются просто так, их в любом случае придётся завернуть в лямбду или передать по имени.
Кстати, в php функции не передаются просто так, их в любом случае придётся завернуть в лямбду или передать по имени.
1. Не раскрою ;) Потому что это докажет лишь то, что придуманным примером можно доказать все что угодно.
2. По имени обычно передается. Разница между указателем или именем — не так уж и велика.
2. По имени обычно передается. Разница между указателем или именем — не так уж и велика.
1. Ну уже поделитесь — таки любопытно. Обещаю не использовать как доказательство ни pro, ни contrau )))
2. Хорошо, с простой функцией — признаю, $callback(...) вполне работает подобно указателю, что с именем, переданным строкой, что с экземпляром Closure. Изящество пропадает при включении в эту модель методов объектов, но они по задумке ФП вроде как и не планировались…
2. Хорошо, с простой функцией — признаю, $callback(...) вполне работает подобно указателю, что с именем, переданным строкой, что с экземпляром Closure. Изящество пропадает при включении в эту модель методов объектов, но они по задумке ФП вроде как и не планировались…
Обе функции принимают на вход массив и колбэк и возвращают массив. Обе относятся к одному подмножеству функций (работа с массивами абстрагированная от их содержимого). Но по каким-то причинам порядок их аргументов разный. В принципе причины понятны даже в каждом отдельном случае, но непонятно почему им последовали не считая единообразность более веской причиной.
Это безусловно кривизна, но мотивы оной в документации описаны, array_map принимает несколько массивов, соот-но массив у него вторым параметром потому как может быть ещё и третий, четвертый и т.п., ради этого разработчики php решили испохабить его сигнатуру.
ага, ага. Что только не сделаешь, лишь бы самообманом заняться.
habrahabr.ru/post/148010/?reply_to=4997107#comment_4996999
«Испохаблена» сигнатура не у array_map, а у array_filter, array_intersect_ukey и т.п.
habrahabr.ru/post/148010/?reply_to=4997107#comment_4996999
«Испохаблена» сигнатура не у array_map, а у array_filter, array_intersect_ukey и т.п.
И что не так с array_filter? Сигнатура такая-же как у array_reduce, да и по логике оно так как должно быть, в объектном стиле это-бы выглядело $array->filter() / $array->reduce(), если рассматривать функцию как первичный аргумент относительно массивов, как в array_map — то тогда и называться они должны наоборот, function_filter_array, function_reduce_array и т.п., ну или в недостижимом идеале — как в других языках — просто filter, просто map, просто reduce, а префикс array_ однозначно указывает что в первую очередь операция производится над массивом, а уже потом какая, как и чем, это как-бы привычное человеческому восприятию соглашение об именовании, вон например в gtk+ — все функции gtk_window_* принимают первым аргументом структуру GtkWindow, что логично, gtk_widget_* соот-но GtkWidget и т.п.
> Сигнатура такая-же как у array_reduce, да и по логике оно так как должно быть,
По какой логике?
> в объектном стиле
Причем тут объектный стиль?
> если рассматривать функцию как первичный аргумент относительно массивов, как в array_map — то тогда и называться они должны наоборот
Нет, не должны
> префикс array_ однозначно указывает что в первую очередь операция производится над массивом
И? Из-за этго в половине функций первый элемнет должен быть массивом, а во второй половине — функцией?
> это как-бы привычное человеческому восприятию соглашение об именовании
Еще один. С какого перепугу оно привычно человеческому восприятию?
> вон например в gtk+ — все функции gtk_window_* принимают первым аргументом структуру GtkWindow, что логично
Оно кажется логичным, потому что оно так реализовано.
Чтобы не повторяться: habrahabr.ru/post/148010/?reply_to=4999631#comment_4994223
По какой логике?
> в объектном стиле
Причем тут объектный стиль?
> если рассматривать функцию как первичный аргумент относительно массивов, как в array_map — то тогда и называться они должны наоборот
Нет, не должны
> префикс array_ однозначно указывает что в первую очередь операция производится над массивом
И? Из-за этго в половине функций первый элемнет должен быть массивом, а во второй половине — функцией?
> это как-бы привычное человеческому восприятию соглашение об именовании
Еще один. С какого перепугу оно привычно человеческому восприятию?
> вон например в gtk+ — все функции gtk_window_* принимают первым аргументом структуру GtkWindow, что логично
Оно кажется логичным, потому что оно так реализовано.
Чтобы не повторяться: habrahabr.ru/post/148010/?reply_to=4999631#comment_4994223
Если функция называется array_filter — то первым аргументом она должна принимать массив, это ожидаемое от неё поведение, было-бы как минимум нелогично если-бы preg_replace принимал первым аргументом строку замены, а не шаблон регулярного выражения, str_split количество символов для разбивки строки, а не саму строку и т.п., так как у них в названии это написано:
И тон смените, я вам спокойно излагаю свою позицию, а вместо аргументированного ответа получаю какое-то брызганье слюной.
массив_фильтровать($массив, $чем_фильтровать);
строку_разбить($строка, $на_сколько_символов_разбить);
И тон смените, я вам спокойно излагаю свою позицию, а вместо аргументированного ответа получаю какое-то брызганье слюной.
> Если функция называется array_filter — то первым аргументом она должна принимать массив
Нет, не должна
> это ожидаемое от неё поведение
«Ожидаемое» поведение описывается документацией и principle of least surprise. В частности: если все функции, принимающие на вход массив(ы) и callback должны иметь callback в одно и том же месте.
> было-бы как минимум нелогично
Аналогии идут лесом.
> И тон смените, я вам спокойно излагаю свою позицию, а вместо аргументированного ответа получаю какое-то брызганье слюной.
Это не брызганье слюной, а усталость от разъяснения очевидных вещей третьему человеку в топике.
Потому что аргументация «ах, оно ведь так читается» — это, извините, звиздец.
Можно начать с того, что префикс array_ указывает не на то, как читать функцию, а на то, что в PHP не было неймспейсов, а функции надо было как-то разделять. Аналогично с string_*, mysql_*, preg_* и так далее.
Но надо же обязательно найти самый убогий аргумент «оно так читается!!» и попытаться притянуть его сюда за уши.
Нет, не должна
> это ожидаемое от неё поведение
«Ожидаемое» поведение описывается документацией и principle of least surprise. В частности: если все функции, принимающие на вход массив(ы) и callback должны иметь callback в одно и том же месте.
> было-бы как минимум нелогично
Аналогии идут лесом.
> И тон смените, я вам спокойно излагаю свою позицию, а вместо аргументированного ответа получаю какое-то брызганье слюной.
Это не брызганье слюной, а усталость от разъяснения очевидных вещей третьему человеку в топике.
Потому что аргументация «ах, оно ведь так читается» — это, извините, звиздец.
Можно начать с того, что префикс array_ указывает не на то, как читать функцию, а на то, что в PHP не было неймспейсов, а функции надо было как-то разделять. Аналогично с string_*, mysql_*, preg_* и так далее.
Но надо же обязательно найти самый убогий аргумент «оно так читается!!» и попытаться притянуть его сюда за уши.
Ну вот с точки зрения principle of least surprise чертова куча библиотек под си работает именно с таким соглашением, а это gtk+, mysql, gd и т.д., и если уж говорить о php — то в нём тоже большинство функций работы с массивами принимает первым аргументом массив, большинство функций работы со строками — строку, с регулярками — регулярярное выражение, это и есть то самое ожидаемое для программиста поведение.
«все функции, принимающие на вход массив(ы) и callback должны иметь callback в одном и том же месте» — а что, в этом топике есть хоть один человек который с этим спорит? Должны, и это место — место второго аргумента по вышеобозначенному вами-же принципу, так как в php первый занят массивом в большинстве функций array_*.
И за весь наш разговор ни одного аргумента в поддержку вашей позиции я пока не услышал, как собственно и самой позиции, подозреваю что их вообще нет. Адекватный спор — попытка доказать свою точку зрения, а не хамством опровергнуть чужую, поэтому считаю дискуссию закрытой, у меня нет желания приводить свои доводы и получать в ответ аргументы в виде «ну это в натуре бред», я себе не враг.
«все функции, принимающие на вход массив(ы) и callback должны иметь callback в одном и том же месте» — а что, в этом топике есть хоть один человек который с этим спорит? Должны, и это место — место второго аргумента по вышеобозначенному вами-же принципу, так как в php первый занят массивом в большинстве функций array_*.
И за весь наш разговор ни одного аргумента в поддержку вашей позиции я пока не услышал, как собственно и самой позиции, подозреваю что их вообще нет. Адекватный спор — попытка доказать свою точку зрения, а не хамством опровергнуть чужую, поэтому считаю дискуссию закрытой, у меня нет желания приводить свои доводы и получать в ответ аргументы в виде «ну это в натуре бред», я себе не враг.
> если уж говорить о php — то в нём тоже большинство функций работы с массивами принимает первым аргументом массив
Тогда *все* функции должны быть такими, а не «треть так, треть этак, а треть еще и врастопырку»
> callback должны иметь callback в одном и том же месте» — а что, в этом топике есть хоть один человек который с этим спорит?
А вы почитайте комменты. «ой, это же логично, что в одной функции аргументы так, а в другой — этак, потому что оно читается так».
> И за весь наш разговор ни одного аргумента в поддержку вашей позиции
Вообще-то моя позиция ровно одна: порядок в аргументах. Пусть callback будет последним, мне от этого ни холодно ни жарко. Мне холодно и жарко, когда люди с жаром начинают рассказывать про логичность в беспорядке и аргументируют это бредом типа «ну ведь вот так вот читается»
Тогда *все* функции должны быть такими, а не «треть так, треть этак, а треть еще и врастопырку»
> callback должны иметь callback в одном и том же месте» — а что, в этом топике есть хоть один человек который с этим спорит?
А вы почитайте комменты. «ой, это же логично, что в одной функции аргументы так, а в другой — этак, потому что оно читается так».
> И за весь наш разговор ни одного аргумента в поддержку вашей позиции
Вообще-то моя позиция ровно одна: порядок в аргументах. Пусть callback будет последним, мне от этого ни холодно ни жарко. Мне холодно и жарко, когда люди с жаром начинают рассказывать про логичность в беспорядке и аргументируют это бредом типа «ну ведь вот так вот читается»
Позиция ясна. Но не ясно, а какой из порядков будет самый порядистый. Желание упорядочить есть у всех, но не факт, что логика разных людей будет одинаковой
В принципе, достаточно выбрать один и придерживаться его.
Но, учитывая, что filter/map и т.п. растут из ФП, то там порядок известен давно: fun(Predicate, List)
Но, учитывая, что filter/map и т.п. растут из ФП, то там порядок известен давно: fun(Predicate, List)
Можно ещё упомянуть, что когда php был маленький, то для работы с массивами сначала были безпрефиксные функции типа sort(), usort(), count()… По мере развития php они придумали префиксы array_, однако они не стали ломать обратную совместимость.
Что вы хотели сказать постом, что PHP развивается? Да в PHP много несостыковок, вызванных очень бурным развитием от простого скрипта для сборки шапки-футера маленького сайта, до мощного ООП языка.
Хотя согласен, данный пример функция явно символизирует нескоординированность разработчиков, учитывая что обе эти функции появилмсь в php 4.0.6
Что вы хотели сказать постом, что PHP развивается? Да в PHP много несостыковок, вызванных очень бурным развитием от простого скрипта для сборки шапки-футера маленького сайта, до мощного ООП языка.
Хотя согласен, данный пример функция явно символизирует нескоординированность разработчиков, учитывая что обе эти функции появилмсь в php 4.0.6
вот только теперь уже поздно что-то менять в данном виде. либо еще плодить новые имена, либо устроить «веселье» разработчикам )
Менят не поздно, только есть полно проблем:
— это скучно и рутинно и никому неинтересно © история с Юникодом
— это займет много лет, потому что легаси такой легаси
Хотя постепенный вывод функций в соответсвующие неймспейсы/классы и превращение старых функций в алиасы с пометкой «deprecated» ничто не мешает сделать
— это скучно и рутинно и никому неинтересно © история с Юникодом
— это займет много лет, потому что легаси такой легаси
Хотя постепенный вывод функций в соответсвующие неймспейсы/классы и превращение старых функций в алиасы с пометкой «deprecated» ничто не мешает сделать
Собственно, сейчас на php.internals идут жаркие споры среди разработчиков по поводу того, что делать с этим всем наследием. Кому интересно, могут почитать, например, 6.0 And Moving Forward или Pseudo-objects (methods on arrays, strings, etc.).
В Ruby on Rails целыми днями меняют имена и всякие штуки.
Никто от этого не страдает, ну те кто отключил варнинги страдают, наверное…
За год после изменений предупреждается разработчик, что та или иная магия будет запрещене, используйте вот это заклинание вместо этого.
Т.о. доступна и та и другая магия в переходной версии.
Никто от этого не страдает, ну те кто отключил варнинги страдают, наверное…
За год после изменений предупреждается разработчик, что та или иная магия будет запрещене, используйте вот это заклинание вместо этого.
Т.о. доступна и та и другая магия в переходной версии.
Т.е., грубо говоря, раз в год нужно переписывать все спорные моменты в коде?
За 8 лет работы переписал одну или две функции. В остальном использовал другие методы, уже новые.
Выходит, что просто не использовали тот функционал/синтаксис, который менялся между версиями?
Иначе как-то не сходится такое постоянство кода с постоянными изменениями в руби.
Иначе как-то не сходится такое постоянство кода с постоянными изменениями в руби.
Может просто время жизни функций или приложения в целом меньше периода изменений.
Ну тут меня больше интересует, как пишут достаточно большие проекты на ruby с длительной поддержкой и развитием (измеряемые годами). В них многие части могут не меняться месяцами.
1. версия руби и версия рельс четко прописана в проекте. Т.о. без вашего ведом код не может вдруг начать подругому работать
2. ветка 2.3.6 — 2.3.11 прошло более 3-х лет
3.0.х — 3.1.х — параллельная ветка, все что задекларировано 2.3 как неработающее в 3х неработает
Переезд работающего проекта с 2.3 на 3х занимает менее недели в хучшем случае. Конечно если у вас в проекте километры спагети и быдлокод — переезд затрудняется. Список депрецированных функций можно получить из лога, и если избавится от всех варнингов деприкации переезд с ветки 2.3 на 3.0 проходит в считанные минуты
3. мой проект, которому больше года, спокойно перелез с 3.0.непомню, на 3.1.1 за 10 минут, с одним багом, по моей вине.
4. смена версии руби вообще может не повлиять на поведение системы
5. Тесты наше все — не прошел тест — поправили
2. ветка 2.3.6 — 2.3.11 прошло более 3-х лет
3.0.х — 3.1.х — параллельная ветка, все что задекларировано 2.3 как неработающее в 3х неработает
Переезд работающего проекта с 2.3 на 3х занимает менее недели в хучшем случае. Конечно если у вас в проекте километры спагети и быдлокод — переезд затрудняется. Список депрецированных функций можно получить из лога, и если избавится от всех варнингов деприкации переезд с ветки 2.3 на 3.0 проходит в считанные минуты
3. мой проект, которому больше года, спокойно перелез с 3.0.непомню, на 3.1.1 за 10 минут, с одним багом, по моей вине.
4. смена версии руби вообще может не повлиять на поведение системы
5. Тесты наше все — не прошел тест — поправили
Теперь я понимаю ту боль, с которой рубисты пишут про смену версий
В Ruby on Rails исторически сложилось, что у разработчика приложения и/или у администратора приложения больше «контроля» над средой выполнения. Грубо говоря, никто не заменит версию интерпретатора без их ведома. В PHP же это сплошь и рядом: решил хостер обновиться — хорошо если предупредил о факте обновления.
Это делается просто:
WARNING: function array_map($callback, $input); will be depricated in version 5.x. Use array_collect($input, $callback) instead.
главное желание
WARNING: function array_map($callback, $input); will be depricated in version 5.x. Use array_collect($input, $callback) instead.
главное желание
> вот только теперь уже поздно что-то менять в данном виде. либо еще плодить новые имена, либо устроить «веселье» разработчикам )
Прекрасно. Переходим на следующий уровень:
mysql_query($query, $connection);
pg_query($connection, $query);
mysql_query($query, $connection);
pg_query($connection, $query);
А вот ещё секретный уровень:
mixed mysqli_query ( mysqli $link, string $query [, int $resultmode] )
mixed mysqli_query ( mysqli $link, string $query [, int $resultmode] )
Для совместимости с разработчиками :-)
Всё-таки наверно это было сделано ради простоты конвертации старых проектов, там где много mysql_ вызовов прямо в коде (да, такого ужаса хватает), без всяких абстракций вроде DB.
Но тут ситуация действительно такая: я тоже себе долго планировал перейти на mysqli — вроде и кода менять не много было, всё было вынесено в отдельный класс, но всё руки не доходили, не жало оно мне. А потом оказалось не актуально — перешёл на pg.
Но тут ситуация действительно такая: я тоже себе долго планировал перейти на mysqli — вроде и кода менять не много было, всё было вынесено в отдельный класс, но всё руки не доходили, не жало оно мне. А потом оказалось не актуально — перешёл на pg.
Как-то надо было перевести проект с mysql на mysqli. Сделали в 2 этапа — сначала пару регекспов по проекту, заменяя функции на их mysqli аналоги, потом, по ходу разработки, перевели на объекты.
Почему на проекте не было PDO-подобной абстракции — это другой вопрос :)
Почему на проекте не было PDO-подобной абстракции — это другой вопрос :)
Я почему-то всегда думал, что должен быть отдельный класс для работы с базой, а не прямые вызовы mysql*_*. Дурак я, да? Люди вот регекспят код, это видимо удобнее.
Чтобы его можно было использовать.
Я на PHP пишу простые скрипты для штук вроде asterisk или zabbix, мне ООП вообще не нужно, а работа с MySQL — необходима.
Я на PHP пишу простые скрипты для штук вроде asterisk или zabbix, мне ООП вообще не нужно, а работа с MySQL — необходима.
Я когда перешел на этот синтаксис читал, что надо лишь i и будет работать… убил время не понимая почему оно не работает. Оказывается надо было параметры поменять…
AFAIK mysql устарела и заменена на mysqli лет 5 назад или я что-то путаю?
А в mysqli порядок как в pg
А в mysqli порядок как в pg
Я понял смысл жизни — он всего в 2 строчках:
Жить
Умереть
Могу выразить одной строкой
implode() can, for historical reasons, accept its parameters in either order.
implode() can, for historical reasons, accept its parameters in either order.
Что поделать. Кода на php в виде всяких мелких сайтов и прочего в вебе наверное больше, чем кода на всех остальных языках вместе взятых. Пусть это в основном и мелкие сайты, но когда ищешь нужную информацию, лучше чтобы сайт работал, хоть и криво, чем не работал совсем.
При чем здесь распространенность php на мелких сайтах?
И как она связана с поиском информации?
И что за сайт должен работать, хоть и криво при поиске Вами информации?
Я ничего не понял из вашего комментария.
И как она связана с поиском информации?
И что за сайт должен работать, хоть и криво при поиске Вами информации?
Я ничего не понял из вашего комментария.
Наличие подобных вещей связано с тем, что пхп сначала был языком для домашних страниц. На этих версиях создали множество домашних страниц, форумов, блогов, которые некому патчить если что. Поэтому приходится мирится с сохранением этого помета мамонта в новых версиях php, это лучше, чем ломать эти сайты.
и аналогичный пример для jQuery:
$.map( [1,2,3,4], function( ELEMENT, INDEX ) {… } );
, но
$(«div»).map( function( INDEX, ELEMENT ) {… } );
$.map( [1,2,3,4], function( ELEMENT, INDEX ) {… } );
, но
$(«div»).map( function( INDEX, ELEMENT ) {… } );
Это не аналогичный пример.
В первом случае — вызывается функция из нэймспейса jquery, принимающая два параметра — коллекцию и коллбек. Во втором случае вызывается метод объекта, уже содержащего коллекцию — дивов, в данном случае.
Оба раза вызывается функция map, работающая с коллекцией элементов. С точки зрения предиката, передаваемого в эту функцию, должно быть пофиг, в каком из случаев он используется.
То есть этот код должны быть эквивалентен:
То есть этот код должны быть эквивалентен:
$.map($("div"), F);
$.map([$("#div1"), $("#div2")], F);
$("div»).map( F );
Хм. Получил за этот комментарий минус. Неужели кто-то не согласен, и у этого кого-то есть аргументы?
Вы просто рушите кому-то стройную картину мира и розовые очки. jQ ему не идеален, вы посмотрите на него!!!
Я могу изложить вот какой аргумент: в случае $('div').map( function(index, element){…} ) второй параметр функции необыкновенно часто (да собственно, почти всегда) является необязательным, потому что его и без того можно взять в this.
То есть на практике в алгоритмах, не учитывающих номер элемента, станет использоваться $('div').map( function(){…} ), в учитывающих — $('div').map( function(index){…} ), а двухпараметрическая функция — почти никогда.
А ведь наиболее редко используемый параметр должен стоять последним, потому что именно его в джаваскрипте проще всего опустить при описании и при вызове функции.
В случае $.map( [1,2,3,4], function(element, index) {…} ) обстоятельства противоположны: номер элемента в некоторых алгоритмах не нужен, а вот сам элемент понадобится непременно, потому что this на сей раз его не содержит, а указывает на глобальный объект (window).
Изменение практики употребления функции диктует изменение порядка её аргументов.
Всё логично, как видите.
То есть на практике в алгоритмах, не учитывающих номер элемента, станет использоваться $('div').map( function(){…} ), в учитывающих — $('div').map( function(index){…} ), а двухпараметрическая функция — почти никогда.
А ведь наиболее редко используемый параметр должен стоять последним, потому что именно его в джаваскрипте проще всего опустить при описании и при вызове функции.
В случае $.map( [1,2,3,4], function(element, index) {…} ) обстоятельства противоположны: номер элемента в некоторых алгоритмах не нужен, а вот сам элемент понадобится непременно, потому что this на сей раз его не содержит, а указывает на глобальный объект (window).
Изменение практики употребления функции диктует изменение порядка её аргументов.
Всё логично, как видите.
Логично, но не до конца.
Написать в параметрах i, v — очевидней и короче, чем использовать this. Тем более, что this — всегда приходится использовать с оглядкой — в той ли области видимости мы находимся?
Написать в параметрах i, v — очевидней и короче, чем использовать this. Тем более, что this — всегда приходится использовать с оглядкой — в той ли области видимости мы находимся?
обычно обнообразность документации ценится выше, чем экономия символов от пропуска параметра функции.
кстати, у $.each, к которому применимы ваши аргументы про $.map, порядок не совпадает с $.map. Кроме того, в callbackе, переданном в $.each, this указывет не на window, а на текущий элемент.
кстати, у $.each, к которому применимы ваши аргументы про $.map, порядок не совпадает с $.map. Кроме того, в callbackе, переданном в $.each, this указывет не на window, а на текущий элемент.
Раз уж $.each вызывает callback таким образом, что в нём this указывает не на глобальный объект (window), а на текущий элемент, то к нему применимы те мои тезисы, которые про $('div').map(), а не те мои тезисы, которые про $.map().
Для наглядности я повторю здесь эти тезисы: появление текущего элементав this делает крайне необязательным тот аргумент функции обратного вызова (callback), который содержит текущий элемент (ведь теперь его значение можно преспокойно брать из this). Следовательно, этот аргумент естественно ставить последним среди аргументов функции, потому что именно последний аргумент в джаваскрипте проще всего опустить при описании и при вызове функции.
Как видите, к $.each моя логика также применима, и всё вполне логично и в этом случае.
Для наглядности я повторю здесь эти тезисы: появление текущего элемента
Как видите, к $.each моя логика также применима, и всё вполне логично и в этом случае.
но дело в том, что то, на что указывает this — это не внешнее обстоятельство, а заданный архитектором способ передачи параметра в функцию.
Суть в том, что $.map отличается от остального семейства функций ($.each, $().each, $().map). Отличается оно не только порядком параметров в callbackе, но и значением в this.
Кроме того, при некоторой степени педантичности, можно считать, что передача одного и того же значения в функцию двумя способами — это плохо. Речь о том, что this дублирует явные аргументы функции. Хотя, это наверняка сделано для того, чтобы снизить порог вхождения — про this знаю не все.
Суть в том, что $.map отличается от остального семейства функций ($.each, $().each, $().map). Отличается оно не только порядком параметров в callbackе, но и значением в this.
Кроме того, при некоторой степени педантичности, можно считать, что передача одного и того же значения в функцию двумя способами — это плохо. Речь о том, что this дублирует явные аргументы функции. Хотя, это наверняка сделано для того, чтобы снизить порог вхождения — про this знаю не все.
И что? По-моему, тут как раз всё окей.
это точно так? Поскольку $().map(callback(indexInArray, valueOfElement))
Я как-то увидел, что можно использовать this в качестве текущего элемента в callback, и с тех пор мне было пофиг на порядок аргументов :))
$callback = function($input_el){ echo `$input_el`; };
Смотрим в документацию:
=)
array_filter — Фильтрует элементы массива с помощью callback-функции
array_map — Применяет callback-функцию ко всем элементам указанных массивовт.е. даже в документации порядок разный, как и смысл этих функций.
=)
С точки зрения ФП это не аргумент :)
Всё дело в формулировке. Они должны быть последовательными — именно это главное:
array_filter — фильтрует элементы массива с помощью callback-функции
array_filter — с помощью callback-функции фильтрует элементы массива
array_map — применяет callback-функцию ко всем элементам указанных массивов
array_map — ко всем элементам указанных массивов применяет callback-функцию
Тренируем память!
Все, разработчики больше не нужны. Увольняем всех.
Решение проблемы в две строчки:
function filter ($callback, $input) { return array_filter ($input, $callback); }
function map ($callback, $input) { return array_map ($callback, $input); }
Таких «решений» придется плодить на дикое количество функций.
Практика показывает, что «дикое количество» сводится к «паре десятков». Да и их я себе заменил больше из эстетических соображений, чем по практической надобности. PHP далёк от идеала функциональных языков, очень далёк ))
Пара десятков — это уже слишком много.
Даже не знаю, каков критерий «много/мало»? По логике «больше нуля» — это уже много. Вопрос в другом — это было неизбежным, это не потребовало много времени, это не приводит к смертельному оверхеду, это до сих пор не вызвало конфликтов. Что ещё требуется от данного решения?
Да, хотелось бы, чтобы оно не понадобилось в принципе. Но оно понадобилось и с этим будем жить дальше.
Да, хотелось бы, чтобы оно не понадобилось в принципе. Но оно понадобилось и с этим будем жить дальше.
Да я даже где-то видел специальный класс-фаил подключаемый через include, который имеет обертки такого рода почти ко всем существующим функциям php (и даже ко многим плагинам), но только в едином стандартном формате имен и вызовов.
Писать на таком приятно (после некоторой практики), а вот разбирать чужой код или искать помощь по функциям уже не очень
Писать на таком приятно (после некоторой практики), а вот разбирать чужой код или искать помощь по функциям уже не очень
Сначала вы пишете такое решение. Получается два. Потом вы подключаете какой-нибудь фрэймворк, где тоже есть такое решение. Уже три. Потом подключили дополнительную библиотеку, где тоже есть свое решение. Уже четыре.
В общем, стандартная библиотека языка должна быть настолько мощной и согласованной, чтобы не пришлось ее переделывать.
В общем, стандартная библиотека языка должна быть настолько мощной и согласованной, чтобы не пришлось ее переделывать.
стандартная библиотека языка должна быть настолько мощной и согласованной, чтобы не пришлось ее переделывать.
Если бы мы жили в идеальном мире — нам хватило бы грубо говоря двух-трёх языков на все случаи жизни. Но основная проблема в том, что PHP ухитрился обогнать конкурентов на рынке и обогнал он их не благодаря качеству. Поэтому имеем то, что имеем.
Проблема конфликта имён — возможно переоценена, я за почти десять лет работы с PHP с подобным конфликтом не сталкивался. Теперь же у нас есть пространства имён, которые призваны решить проблему и вопрос уже не стоит и выеденного яйца.
Если бы мы жили в идеальном мире — нам хватило бы грубо говоря двух-трёх языков на все случаи жизни. Но основная проблема в том, что PHP ухитрился обогнать конкурентов на рынке и обогнал он их не благодаря качеству. Поэтому имеем то, что имеем.
Проблема конфликта имён — возможно переоценена, я за почти десять лет работы с PHP с подобным конфликтом не сталкивался. Теперь же у нас есть пространства имён, которые призваны решить проблему и вопрос уже не стоит и выеденного яйца.
namespace спает отца русской демократии. и перегрузите их в своем пространстве а вызывайте как хотите их уже из нативного, если это вас так удручает.
А мне IDE подсказывает в каком порядке какие аргументы.
А в Советской России — программисты подсказывают IDE :-)
Вопрос, как выше уже обсудили не в том, чтобы знать порядок, а в том, чтобы порядок не мешал более хитрым динамическим конструкциям. Впрочем, мне переименование понадобилось ради лаконичных имён, позволяющих писать сложные выражения в строчку.
Вопрос, как выше уже обсудили не в том, чтобы знать порядок, а в том, чтобы порядок не мешал более хитрым динамическим конструкциям. Впрочем, мне переименование понадобилось ради лаконичных имён, позволяющих писать сложные выражения в строчку.
Мало того что это очередной говнопост про то какой PHP не идеальный, так за него еще положительно голосуют… Вы бы лучше что то умное написали про PHP…
Т.к. input — всегда массив, а callback — никогда не может быть массивом, могли бы в следующей версии профиксить и добавить проверку, изменить по-человечески в документации и т.д. Печально, что ничего не делается, чтобы не тянуть за собой эти «детские» ошибки.
callback — может быть массивом, если вы используете не функцию, а метод объекта.
Всегда удивляюсь, кто в php придумал передавать метод класса как массив
array(&$this, 'someMethod')
Что самое интересное, до сих пор и нет другого способа его передать. Лямбды не признают $this
5.4.0 Стало возможным использовать $this в анонимных функциях. Или про что вы?
Он про то, что если есть $this->foo(), то нельзя передать в качестве параметра $this->foo
Аналогичный подход используется в JS
Аналогичный подход используется в JS
Вот же ж блин, таки да — оно. Признаю, был не прав.
А я его по наивности через use пропихивать пытался, так и пришёл к выводу, что не работает, очень расстроился :-)
class B {
protected $a = 'test';
public function b() {
$a = function () {
return $this->a;
};
return $a();
}
}
$b = new B;
print $b->b()."\n";
// test
А я его по наивности через use пропихивать пытался, так и пришёл к выводу, что не работает, очень расстроился :-)
Угу, даже полез в документацию. До этого не знал о подобной «фишке» и, если честно, до сих пор не понимаю почему класс и метод передавать в виде элементов массива, а не class::method()
Не класс, а объект — экземпляр класса со своими данными.
Можно спокойно делать array($someObject, $someMethod)
Почему нельзя делать по-другому? Потому что все другие способы уже заняты:
$someObject->someMethod — получение значения переменной someMethod
$someObject->someMethod() — вызов метода someMethod
$someObject->$someMethod — получение значения переменной, название которой указано в переменной $someMethod
$someObject->$someMethod() — вызов метода, название которого указано в переменной $someMethod
Обращения через :: указывают на статические переменные и методы.
Можно спокойно делать array($someObject, $someMethod)
Почему нельзя делать по-другому? Потому что все другие способы уже заняты:
$someObject->someMethod — получение значения переменной someMethod
$someObject->someMethod() — вызов метода someMethod
$someObject->$someMethod — получение значения переменной, название которой указано в переменной $someMethod
$someObject->$someMethod() — вызов метода, название которого указано в переменной $someMethod
Обращения через :: указывают на статические переменные и методы.
Что мешает узнать интерпретатору php, что $someObject->someMethod — это метод, а не свойство и вернуть в этом случае лямбда функцию.
А если нет ни метода, ни свойства, но определены __get && __callback?
Кинуть исключение логично, ну или как минимум warning и вернуть null. Вы рассуждаете с точки зрения текущего функционала php. Я же говорю о том что можно реализовать.
Можно реализовать все, что угодно. Книгу дракона в руки — и вперед, реализуйте.
Я же рассказываю о том, почему все именно так в определенном языке.
Я же рассказываю о том, почему все именно так в определенном языке.
Так в текущем языке по одной простой причине — так проще разработчикам, выкинуть очередной недофункционал с помощью костыля (тот же __get, __set), чем менять синтаксический анализатор и вычищать потом кучу багов.
> так проще разработчикам, выкинуть очередной недофункционал с помощью костыля (тот же __get, __set), чем менять синтаксический анализатор и вычищать потом кучу багов.
вообще-то, разработчики боятся этого анализатора, как огня. Половина обсуждений про новые фичи сводятся к «ой, парсеру будет слишком сложно».
вообще-то, разработчики боятся этого анализатора, как огня. Половина обсуждений про новые фичи сводятся к «ой, парсеру будет слишком сложно».
__get, __set, а в особенности __call — офигенные штуки. Вот когда на них пытаются построить property а-ля С#, то кажется, что это костыли и недофункционал.
Во всём можно найти плюсы, согласен с вами магические методы __get и __set также могут найти своё применение. Лучше всего для разработчика когда есть и то и другое, то есть можно задать как традиционный getter/setter так и магический __get/__set для несуществующих свойств.
Тут ещё одна особенность — в php (не знаю с каких пор) нет «несуществующих свойств» в приведённом смысле. Свойства создаются автоматически. То есть
отработает без запинки.
$a = new StdClass;
$a->b = 123;
print $a->b;
отработает без запинки.
Причём значительно быстрее, чем при использовании __get и __set.
Ну это понятно, это называется «динамические классы», __get же срабатывает для не инициализированного свойства (isset($a->b)==false). Делать из php строгие неизменяемые классы конечно тоже не надо.
Вообще программируя на JavaScript и ActionScript очень часто посещает голову мысль «вот здорово если бы в php было бы также»… Но у каждого языка свои плюсы и свои минусы)
Вообще программируя на JavaScript и ActionScript очень часто посещает голову мысль «вот здорово если бы в php было бы также»… Но у каждого языка свои плюсы и свои минусы)
> (isset($a->b)==false)
__isset() php.net/manual/en/language.oop5.overloading.php
__isset() php.net/manual/en/language.oop5.overloading.php
Да, меня такие мысли тоже часто посещают — к ним ещё добавился опыт программирования на питоне :-)
Хочется в действительности совместить лучшие качества всех языков. Но мучает мысль, что лучшие они только до первой попытки создания этой гремучей смеси ))
Хочется в действительности совместить лучшие качества всех языков. Но мучает мысль, что лучшие они только до первой попытки создания этой гремучей смеси ))
Иногда мне хочется на __get и __set написать выбрасывание исключения. От опечаток спасает ;)
Пишите. А ещё лучше сделайте trait, если есть возможности.
Я думаю, что можно было бы отладочную версию в первопредке части объектов так и сделать и на продакшене просто убирать или заменять на логи с дампом стека и окружения.
По первам, как пример тёмной стороны магии, — поймал грабли такого молчаливого принятия несуществующих методов и свойств, которые поменяли местами логику кода.
По первам, как пример тёмной стороны магии, — поймал грабли такого молчаливого принятия несуществующих методов и свойств, которые поменяли местами логику кода.
Почему вдруг исключение?
$b = 'b'
$a->$b() — работает,
$a->b — выкинет исключение? Это непоследовательно
Помимо этого, в php следующий код будет работоспособен
И именно это мешает разрулить: ссылка на метод или на функцию.
$b = 'b'
$a->$b() — работает,
$a->b — выкинет исключение? Это непоследовательно
Помимо этого, в php следующий код будет работоспособен
class A {
public $a = 'property';
public function a() {return 'method';}
}
$a = new A;
print $a->a."\n";
print $a->a()."\n";
И именно это мешает разрулить: ссылка на метод или на функцию.
А что не так со статическими методами? А цепочку он поймет в виде массива $someObject->getSomeProperty()->somePropertyMethod()->… или строго два элемента воспринимает? Пролистал доки и не нашел.
&$someObject->someMethod() — всё уже придумано до нас :)
В языке есть возможность вызывать функции и классы по именам, но нет возможности передать ссылку на функцию или на класс. Даже лямбды — это по сути костыль в виде объекта с магическим методом.
Это точно, php много костылей, те же __set и __get. Благо в php 5.5 вроде собираются это решать…
__set, __get, __call — это не совсем костыли, это магия :-)
То есть с их помощью можно реализовать куда больше, чем тривиальные геттеры и сеттеры. У меня например с их помощью реализуются миксины в рантайме, чего язык, даже в версии 5.5 до сих пор не предусматривает (trait'ы нельзя скомпоновать динамически).
Хотя последнее время магию сильно критикуют и есть за что, но в умелых руках и гомеопатических дозах — она бесценна.
То есть с их помощью можно реализовать куда больше, чем тривиальные геттеры и сеттеры. У меня например с их помощью реализуются миксины в рантайме, чего язык, даже в версии 5.5 до сих пор не предусматривает (trait'ы нельзя скомпоновать динамически).
Хотя последнее время магию сильно критикуют и есть за что, но в умелых руках и гомеопатических дозах — она бесценна.
Интересно, что пока я в холиварных топиках не вычитал, что в PHP проблема с порядком параметров, я никогда не обращал на это внимание.
На php.net давно надо повесить комерческие баннеры на страницах функций со спорным порядком аргументов.
Несмотря на то, что в php действительно бардак, именно в данном случае как раз все совершенно логично.
1)array_filter фильтрует один массив опциональным коллбэком. Можно делать просто array_filter($array), что отфильтрует пустые значения.
Иначе говоря, в другом языке это бы выглядело как $Array.filter() или $Array.filter(function()… {}).
2)array_map принимает сколько угодно массовов, потому коллбэк первый.
Иначе говоря, в другом языке это бы выглядело как $Function.map($Array1, $Array2… );
1)array_filter фильтрует один массив опциональным коллбэком. Можно делать просто array_filter($array), что отфильтрует пустые значения.
Иначе говоря, в другом языке это бы выглядело как $Array.filter() или $Array.filter(function()… {}).
2)array_map принимает сколько угодно массовов, потому коллбэк первый.
Иначе говоря, в другом языке это бы выглядело как $Function.map($Array1, $Array2… );
Нет ничего логичного. Это стандартные функции из «Функциональное программирование для самых маленьких». Все подобные операции над списками должны выглядеть или как fun(Predicate, List) или fun(List, Predicate).
Если Predicate опционален, могу подсказать способ сделать его опциональным.
Если Predicate опционален, могу подсказать способ сделать его опциональным.
Давайте прочитаем эти две функции человеческим языком
array_filter($input, $callback); — хочу отфильтровать массив при помощи собственной функции
array_map($callback, $input); — хочу применить функцию на каждый элемент массива
Теперь логика есть?
array_filter($input, $callback); — хочу отфильтровать массив при помощи собственной функции
array_map($callback, $input); — хочу применить функцию на каждый элемент массива
Теперь логика есть?
И молвила ему рыбка человеческим голосом, ага.
А что, если мы эти функции прочитаем не по-русски, а по-турецки? ВНЕЗАПНО окажется, что порядок параметров будет прямо противоположный.
В общем, аргумент понятный, но менее идиотским от этого не становящийся.
А что, если мы эти функции прочитаем не по-русски, а по-турецки? ВНЕЗАПНО окажется, что порядок параметров будет прямо противоположный.
В общем, аргумент понятный, но менее идиотским от этого не становящийся.
Почему именно идиотским? Ну не совпадает способ мышления разработчика языка с вашим представлением о Прекрасном Коде, ну и что? К чему категоричность мышления?
> Почему именно идиотским?
Потому что вы пытаетесь аргументировать неверное решение о дизайне языка попыткой прочтения функции на «человеческом языке». При том, вам даже в голову не пришло, что прочтение на русском может отличаться от прочтения на другом языке.
> Ну не совпадает способ мышления разработчика языка с вашим представлением о Прекрасном Коде, ну и что?
Это не «мои представления о прекрасном». Это здравый смысл, принцип наименьшего удивления, «введение в функциональное программирование для самых маленьких» и «введение в дизайн языков для самых маленьких»
Потому что вы пытаетесь аргументировать неверное решение о дизайне языка попыткой прочтения функции на «человеческом языке». При том, вам даже в голову не пришло, что прочтение на русском может отличаться от прочтения на другом языке.
> Ну не совпадает способ мышления разработчика языка с вашим представлением о Прекрасном Коде, ну и что?
Это не «мои представления о прекрасном». Это здравый смысл, принцип наименьшего удивления, «введение в функциональное программирование для самых маленьких» и «введение в дизайн языков для самых маленьких»
Мне в голову не пришло только потому, что PHP написан на английском и на нем же мои высказывания читаются аналогично русскому, даже несколько проще. Прошу прощения, я не гуру в английском, но попробую таки воспроизвести.
filter $input by $callback
map $callback to $input
В такой формулировке мне нравится расположение параметров гораздо больше, чем
map to each $input element the $callback
Еще раз прошу прощения за корявый Ынглиж
filter $input by $callback
map $callback to $input
В такой формулировке мне нравится расположение параметров гораздо больше, чем
map to each $input element the $callback
Еще раз прошу прощения за корявый Ынглиж
И опять же про английский:
use callback to filter input
use callback to map input
having input, filter it using callback
having input, map it using callback
И ни то ни другое не имеет ни малейшего отношения к дизайну языка
use callback to filter input
use callback to map input
having input, filter it using callback
having input, map it using callback
И ни то ни другое не имеет ни малейшего отношения к дизайну языка
В любом, даже мало-мальском моменте найдутся противники и последователи. Но это не значит, что только один из них прав. Скорее всего не правы обе стороны или правы оба. Так что не вижу смысла продолжать наш «спор», каждый останется при своем мнении.
> В любом, даже мало-мальском моменте найдутся противники и последователи. Но это не значит, что только один из них прав.
Вообще-то, principle of least surprise и азы ФП никто не отменял. Но я понимаю, что если кроме аргументов «а вот так вот хорошо читается» ничего нет, то разговор действительно не стоит продолжать.
Вообще-то, principle of least surprise и азы ФП никто не отменял. Но я понимаю, что если кроме аргументов «а вот так вот хорошо читается» ничего нет, то разговор действительно не стоит продолжать.
Какая разница? 95% тех, кто пишет на php, не знают, что такое функциональное программирование, и думают, что это то же самое, что процедурное.
Подскажите, я расскажу, почему в php так не выйдет.
Если Predicate опционален, могу подсказать способ сделать его опциональным.
Подскажите, я расскажу, почему в php так не выйдет.
> Подскажите, я расскажу, почему в php так не выйдет.
Вы сами сделали его опциональным. Так почему Predicate в качестве первого параметра не подходит для array_filter? И почему это нельзя сделать в PHP? Я внимательно слушаю
> 1) array_filter фильтрует один массив опциональным коллбэком. Можно делать просто array_filter($array), что отфильтрует пустые значения.
Вы сами сделали его опциональным. Так почему Predicate в качестве первого параметра не подходит для array_filter? И почему это нельзя сделать в PHP? Я внимательно слушаю
1) Я ничего не делал опциональным, опциональным его сделали разработчики PHP.
2) И это очень удобно: 50% применений array_filter — без указания callback.
Что в этом случае делать? array_filter(false, $array)? array_filter(null, $array)? Ужасно.
Разве что так — сделать Predicate обязательным и добавить что-то вроде array_filter_empty.
Но это все уже не важно, никто ничего не будет менять, просто потому что BC.
2) И это очень удобно: 50% применений array_filter — без указания callback.
Что в этом случае делать? array_filter(false, $array)? array_filter(null, $array)? Ужасно.
Разве что так — сделать Predicate обязательным и добавить что-то вроде array_filter_empty.
Но это все уже не важно, никто ничего не будет менять, просто потому что BC.
> Что в этом случае делать? array_filter(false, $array)? array_filter(null, $array)?
Что мешает сделать
array_filter($array)
array_filter($callback, $array)
?
> 50% применений array_filter
47.098765678% цифр в интернете являются выдуманными. Инфа 146%
Что мешает сделать
array_filter($array)
array_filter($callback, $array)
?
> 50% применений array_filter
47.098765678% цифр в интернете являются выдуманными. Инфа 146%
То что и $callback, и $array могут быть массивами, отличимыми друг от друга только семантически?
Нет, это не мешает сделать. Функция с одним аргументом — это вызов без callback'а, функция с двумя аргументами — вызов с callback'ом.
Тут рядом вообще привели пример мегакривого дизайна habrahabr.ru/post/148010/?reply_to=4997107#comment_4996999
Что-то тут то, что callback может быть массивом, не помешало им засунуть callback в конец функции. Но помешало бы поставить его в начла? Ага, как же :)
Тут рядом вообще привели пример мегакривого дизайна habrahabr.ru/post/148010/?reply_to=4997107#comment_4996999
Что-то тут то, что callback может быть массивом, не помешало им засунуть callback в конец функции. Но помешало бы поставить его в начла? Ага, как же :)
No one is right, everyone is wrong!
Предлагаю автору, вместо дешевого троллинга, написать пару обстоятельных статей, про достоинства своего любимого яп :)
А такие вот вбросы, характеризуют автора, скорее с негативной стороны ;)
А такие вот вбросы, характеризуют автора, скорее с негативной стороны ;)
Поддерживаю.
Несмотря на то, что топик — это перевод, топикстартер явно поддерживает «мысль».
Напишите о вашем ЯП.
И вообще — я в программировании весьма давно (писал ещё на асме), пробовал и лёгкие ЯП и тяжёлые. Вот моё мнение: Идеальных ЯП — НЕТ! Они все с изъянами. А изъяны эти лежат в головах разработчиков. Идеального вообще ничего нет. Есть хорошее, есть отличное, есть удобное.
Несмотря на то, что топик — это перевод, топикстартер явно поддерживает «мысль».
Напишите о вашем ЯП.
И вообще — я в программировании весьма давно (писал ещё на асме), пробовал и лёгкие ЯП и тяжёлые. Вот моё мнение: Идеальных ЯП — НЕТ! Они все с изъянами. А изъяны эти лежат в головах разработчиков. Идеального вообще ничего нет. Есть хорошее, есть отличное, есть удобное.
Одно дело, когда изъяны лежат в головах разработчиков на языке N.
Совсем другое дело, когда изъяны лежат в головах разработчиков самогó языка N.
Совсем другое дело, когда изъяны лежат в головах разработчиков самогó языка N.
При разработке сообществом разные функции из одной категории вполне себе могли быть созданы разными разработчиками со своими взглядами. Если при этом нет коллективного стандарта и общего обсуждения нововведений, то вполне себе могут рождаться такие вот чудные творения.
Давно хотел узнать: Сергей, вы приверженец каких языков и технологий (если это не коммерческая тайна)?
100+ комментариев и никто не прочитал документацию по функциям до конца, и, похоже, на деле их никогда не использовал.
Все функции в «функциональном» стиле имеют вид array_*(array $input, $callback).
array_map выделяется из этого стиля, потому ей на вход можно передать несколько массивов.
Полное описание такое:
Нужна ли такая возможность — спорный вопрос, но изменение порядка аргументов, по-моему, оправдано.
Проблема с порядком параметров в PHP есть, но приведенный в топике пример никакого отношения к ней не имеет.
Если у вас есть идеи, как сделать лучше — мейл листы ждут вас.
Все функции в «функциональном» стиле имеют вид array_*(array $input, $callback).
array_map выделяется из этого стиля, потому ей на вход можно передать несколько массивов.
Полное описание такое:
array array_map ( callable $callback , array $arr1 [, array $... ] )Нужна ли такая возможность — спорный вопрос, но изменение порядка аргументов, по-моему, оправдано.
Проблема с порядком параметров в PHP есть, но приведенный в топике пример никакого отношения к ней не имеет.
Если у вас есть идеи, как сделать лучше — мейл листы ждут вас.
Упс, опередили, ещё и разжевали лучше :)
Процитирую себя
В принципе причины понятны даже в каждом отдельном случае, но непонятно почему им последовали не считая единообразность более веской причиной.
habrahabr.ru/post/148010/#comment_4994250
В принципе причины понятны даже в каждом отдельном случае, но непонятно почему им последовали не считая единообразность более веской причиной.
habrahabr.ru/post/148010/#comment_4994250
> Все функции в «функциональном» стиле имеют вид array_*(array $input, $callback).
> array_map выделяется из этого стиля, потому ей на вход можно передать несколько массивов.
Простой вопрос сразу: что именно мешало сделать другой порядок аргументов?
> array_map выделяется из этого стиля, потому ей на вход можно передать несколько массивов.
Простой вопрос сразу: что именно мешало сделать другой порядок аргументов?
Ах, да. Совсем забыл.
Как простейший вариант
array array_map ( array $arr1 [, array $... ], callable $callback )
Как простейший вариант
Ага, и тогда это выбьется из общего стиля, что все необязательные аргументы идут последними и кто то напишет об этом :)
P.S. По моему, на хабре недавно был подкаст, в котором гость привел цитату Расмус Лердорф, что php это простая обертка над сишными библиотеками, и что порядок и именование в основном взяты от туда.
P.S. По моему, на хабре недавно был подкаст, в котором гость привел цитату Расмус Лердорф, что php это простая обертка над сишными библиотеками, и что порядок и именование в основном взяты от туда.
Не знаю как в php, но такое сделать в C# нельзя.
Разве что расписывать каждую функцию:
array array_map ( array $arr1, callable $callback )
array array_map ( array $arr1, array $arr2, callable $callback )
array array_map ( array $arr1, array $arr2, array $arr3, callable $callback )
…
и так до бесконечности.
А функцию array_map ( callable $callback, array $arr1 [, array $… ] ) можно будет сделать одну и код не будет повторяться.
Разве что расписывать каждую функцию:
array array_map ( array $arr1, callable $callback )
array array_map ( array $arr1, array $arr2, callable $callback )
array array_map ( array $arr1, array $arr2, array $arr3, callable $callback )
…
и так до бесконечности.
А функцию array_map ( callable $callback, array $arr1 [, array $… ] ) можно будет сделать одну и код не будет повторяться.
В PHP такое делается легко через func_get_args(), но вот поддержки со стороны IDE в таком случае можно не ждать :).
Справедливости ради, сделать такое можно. Пример:
array array_intersect_ukey ( array $array1 , array $array2 [, array $... ], callable $key_compare_func ) php-docПилять. И после этого мне рассказывают сказки про логичность PHP и что плохо иметь обязательный параметр в конце и необязательные в середине?
Слушайте, я тогда вообще не понимаю, почему так поступили. Во-первых, полезность поддержки нескольких массивов сомнительна, во-вторых, такое можно сделать и с необязательными аргументами в середине, в-третьих, такое уже сделали в других функциях. Где логика?
Лично я думаю, что дело во времени, когда эти функции появились.
array_map — это php 4.0, т.е 2000ый год (12 лет назад!) и тогда лучшего решения, как поменять параметры местами, просто не придумали. С того времени функцию уже не меняли из-за обратной совместимости.
array_intersect_ukey — это уже php 5, 2005ый год — за 5 лет люди поменялись и новое решение нашлось и всех устроило.
array_map — это php 4.0, т.е 2000ый год (12 лет назад!) и тогда лучшего решения, как поменять параметры местами, просто не придумали. С того времени функцию уже не меняли из-за обратной совместимости.
array_intersect_ukey — это уже php 5, 2005ый год — за 5 лет люди поменялись и новое решение нашлось и всех устроило.
Слушайте, вот в этом и проблема PHP. Вначале было что-то написанное для новичков людьми, которые забили на сами основы CS, а потом когда язык вырос и оброс нормальными фичами, в самих основах языка из-за обратной совместимости осталась куча дерьма.
Именно. Расмус Лердорф сам говорил:
«I was really, really bad at writing parsers. I still am really bad at writing parsers.»
«I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say «Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.» I’ll just restart Apache every 10 requests.»
«I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.»
;)
К сожалению, оно взлетело. Хотя бы по той причине, что лучше на тот момент не было.
И к еще большему сожалению сейчас есть люди, верящие в то, что за всем этим стоял дизайн и логические решения
«I was really, really bad at writing parsers. I still am really bad at writing parsers.»
«I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say «Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.» I’ll just restart Apache every 10 requests.»
«I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.»
;)
К сожалению, оно взлетело. Хотя бы по той причине, что лучше на тот момент не было.
И к еще большему сожалению сейчас есть люди, верящие в то, что за всем этим стоял дизайн и логические решения
Вот наверное автор топика не поймёт, но я увидел логику, как только открыл документацию:
array array_filter ( array $input [, callable $callback = "" ] )
array array_map ( callable $callback , array $arr1 [, array $... ] );
Я не автор, но переводчик, и заявляю, что логики там нет:
habrahabr.ru/post/148010/#comment_4994223
habrahabr.ru/post/148010/#comment_4994250
habrahabr.ru/post/148010/#comment_4994223
habrahabr.ru/post/148010/#comment_4994250
А быть может логика в том, что в первом случае только 1 массив передаётся, а во втором случае — сколько угодно?
Логика в том, что в первом случаи необязательным элементом является callback, а во втором случаи — дополнительный набор массивов, это намного лучше того, что необязательные аргументы будут стоят в середине, как было предложено выше
habrahabr.ru/post/148010/?reply_to=4996285#comment_4994223
array_filter($array)
array_filter($callback, $array)
Что изменилось по сравнению с существующей ситуацией? Ничего, кроме ВНЕЗАПНОГО появления принципа наименьшего удивления.
Ну и не говоря о том, что array_filter без callback'а в общем случае смысла не имеет вообще, а явлется захардкоженным весьма частным случаем.
habrahabr.ru/post/148010/?reply_to=4996285#comment_4994223
array_filter($array)
array_filter($callback, $array)
Что изменилось по сравнению с существующей ситуацией? Ничего, кроме ВНЕЗАПНОГО появления принципа наименьшего удивления.
Ну и не говоря о том, что array_filter без callback'а в общем случае смысла не имеет вообще, а явлется захардкоженным весьма частным случаем.
habrahabr.ru/post/148010/?reply_to=4996285#comment_4994223
Мне на ваш пример смотреть неприятнее чем на пример в топике, пусть там две функции одного класса принимают массив в разных позициях параметров (хотя 2 функция все таки принимает не массив, а массивы), зато у них параметр не может начать плыть, а что касается необязательных параметров — это как в статье, если я хочу что то добавить, а не изменить, то гораздо удобнее писать в конце, а не вставлять все в уже сформированный текст, может логика свзяности поплыть
А array_filter без callback функции все таки имеет смысл (очистить все от лжи — всегда хорошо =) ), а то что частный случай — дак это конечно, впрочем как и сам array_filter
Я ни в коем случаи не говорю, что мое мнение единственное и правильное, ваш вариант тоже имеет место, кому то он покажется лучше, просто в общем не говорит все это о том, что язык плохой… или что вы пытаетесь доказать?
А array_filter без callback функции все таки имеет смысл (очистить все от лжи — всегда хорошо =) ), а то что частный случай — дак это конечно, впрочем как и сам array_filter
Я ни в коем случаи не говорю, что мое мнение единственное и правильное, ваш вариант тоже имеет место, кому то он покажется лучше, просто в общем не говорит все это о том, что язык плохой… или что вы пытаетесь доказать?
> зато у них параметр не может начать плыть
Боже. Что значит «плыть»?
> если я хочу что то добавить, а не изменить, то гораздо удобнее писать в конце
Добавить что? Функция filter для работы со списками известна еще с 60-х, наверное, а то и раньше. И выглядит стандартно как filter(predicate, list)
> А array_filter без callback функции все таки имеет смысл
Только в мозгах РНРшников, которые считают, что жестко прописанные в языке хаки для исключительно частных случаев — это логично и является хорошим дизайном языка.
> дак это конечно, впрочем как и сам array_filter
array_filter не является частным случаем. Он как раз является общим решением, которое решили испоганить ради весьма частного случая.
> просто в общем не говорит все это о том, что язык плохой
Говорит, и еще как говорит
Боже. Что значит «плыть»?
> если я хочу что то добавить, а не изменить, то гораздо удобнее писать в конце
Добавить что? Функция filter для работы со списками известна еще с 60-х, наверное, а то и раньше. И выглядит стандартно как filter(predicate, list)
> А array_filter без callback функции все таки имеет смысл
Только в мозгах РНРшников, которые считают, что жестко прописанные в языке хаки для исключительно частных случаев — это логично и является хорошим дизайном языка.
> дак это конечно, впрочем как и сам array_filter
array_filter не является частным случаем. Он как раз является общим решением, которое решили испоганить ради весьма частного случая.
> просто в общем не говорит все это о том, что язык плохой
Говорит, и еще как говорит
К вопросу о сверхсупер логичном приятно PHP в комментарии выше: habrahabr.ru/post/148010/?reply_to=4996999#comment_4997011
Адъ и израильъ, как он есть
Адъ и израильъ, как он есть
Смотрите на это как на перегрузку. В других языках это сомнений и проблем не вызывает.
Ээээ. Это был ответ на вопрос про адъ и израиль?
Нет, это был ответ krs на Мне на ваш пример смотреть неприятнее чем на пример в топике
array_filter($array)
array_filter($callback, $array)
Типичная перегрузка методов, которая в PHP может быть ещё и гибче, чем, например в Java, поскольку не нужно объявлять отдельную версию метода на каждую возможную комбинацию параметров, а можно их проанализировать по классу и типу в произвольном порядке. Разумеется и все минусы и плюсы как следствие этого подхода — анализ на этапе выполнения, а не на этапе трансляции в байткод.
array_filter($array)
array_filter($callback, $array)
Типичная перегрузка методов, которая в PHP может быть ещё и гибче, чем, например в Java, поскольку не нужно объявлять отдельную версию метода на каждую возможную комбинацию параметров, а можно их проанализировать по классу и типу в произвольном порядке. Разумеется и все минусы и плюсы как следствие этого подхода — анализ на этапе выполнения, а не на этапе трансляции в байткод.
Простите, это покажется грубым, но, вы что слепой? КАК можно в приведенном примере не видеть логику? Или тупо лбом и уперлись и все? Типа: «вы все гомосексуалисты, а я д'артаньян и своих ошибок не признаю»
Отутсвие логики там увидеть легко, имея банальные познания в ФП, откуда у этих функций растут ноги. То, что $callback необязателен, не значит, что он обязан быть в конце.
habrahabr.ru/post/148010/?reply_to=4996285#comment_4994223
habrahabr.ru/post/148010/?reply_to=4996285#comment_4994223
Всего две строчки, а столько обсуждения по делу.
Здравствуй, старый-добрый Хабр
Здравствуй, старый-добрый Хабр
Неумная провокация. Думайте больше. Как верно предложено: habrahabr.ru/post/148010/#comment_4994382
Лучше уж тогда было оформить все возможные неоднозначности «основного ядра PHP» в форме инфоргафики какой-нибудь.
А так один пример и тот не совсем корректен (выше уже было про параметры array_map). Смысла поста никакого.
А так один пример и тот не совсем корректен (выше уже было про параметры array_map). Смысла поста никакого.
пост тупо ни о чем
Объясните кто-то в чем смысл статьи? Только в том, что аргументы этих функций идут в разной последовательности?
Глупость, притянутая за уши, уже не раз обсуждали.
Минусанул
Да-да, это всё было уже тут nuclight.livejournal.com/107170.html но более конструктивно. Стоит поучится аргументировать свою позицию. Хотя, она ясна и без этого. И всё равно я люблю пхп!
ну круто чо. сюда бы тоже добавить в «Ссылки» lurkmore.to/PHP — линк на ЖЖ я там и нарыл когда-то.
видел давно еще. Только скажите, где сегодня перл в вебе применяется? А PHP живет и не чихает даже :)
К тому же аргументы в той статье много раз обсосаны и большинство из них притянуты за уши.
К тому же аргументы в той статье много раз обсосаны и большинство из них притянуты за уши.
Неужели никто не вспомнил про htmlentities и html_entity_decode?
Автор, держись! Я сейчас тебе такой непредсказуемый язык покажу, что ого-го. Вот мануал.
Я так понял, что холивары на эту тему закончатся только после того, как про php совсем забудут (если конечно это случится).
П.С. Не считаю php хорошим языком. Обыкновенный ЯП для генерирования web страниц. Кстати, не знаю почему, но мне труднее набирать его код. Ту же Java быстрее выходит. Наверно из-за особенностей синтаксиса.
П.С. Не считаю php хорошим языком. Обыкновенный ЯП для генерирования web страниц. Кстати, не знаю почему, но мне труднее набирать его код. Ту же Java быстрее выходит. Наверно из-за особенностей синтаксиса.
>> Обыкновенный ЯП для генерирования web страниц
Что интересно: он на большее особо и не претендует.
Писать на нём Национальную ОС никто не будет (хочется в это верить), создавать ПО для обслуживания атомных станций — тоже врядли.
Вот смотрите: ассемблер — очень мощный язык. На нём можно сделать вообще всё, что хочешь. Но, б/\ядь, как же на нём долго и дорого создавать веб-приложения и сайты… Мне труднее набирать на нём код для этого :) Но писать на PHP низкоуровневый драйвер, ну или более близкий мне пример: программу для микроконтроллера — мне даже в голову не придёт. Хотя… :)
Что интересно: он на большее особо и не претендует.
Писать на нём Национальную ОС никто не будет (хочется в это верить), создавать ПО для обслуживания атомных станций — тоже врядли.
Вот смотрите: ассемблер — очень мощный язык. На нём можно сделать вообще всё, что хочешь. Но, б/\ядь, как же на нём долго и дорого создавать веб-приложения и сайты… Мне труднее набирать на нём код для этого :) Но писать на PHP низкоуровневый драйвер, ну или более близкий мне пример: программу для микроконтроллера — мне даже в голову не придёт. Хотя… :)
Однажды случится PHP-NG (new generation), и будет он правильным, хорошим и замечательным, и порядо аргументов в нем будет одинаков и незыблем, вне зависимости от того, с какой ноги проснется его автор. И будут от самого существования этого языка расти деревья, петь птицы, веселиться люди, а программеры все как один (даже говнопрограммеры!) перейдут с текущего PHP на этот, новый, и воцарится счастье и гармония в сердцах людских!
И только немногие заметят, что PHP-NG будет как один похож на (поставьте свой любимый язык). Так, обманом в имени, сонмы адептов PHP будут переманены в лоно новой церкви нового языка, и тишина и благодать окутает Землю.
До очередной holy war, разумеется!
И только немногие заметят, что PHP-NG будет как один похож на (поставьте свой любимый язык). Так, обманом в имени, сонмы адептов PHP будут переманены в лоно новой церкви нового языка, и тишина и благодать окутает Землю.
До очередной holy war, разумеется!
Пожалуй напишу это с одной строчки
array_filter($input, $callback); array_map($callback, $input);
array_filter($input, $callback); array_map($callback, $input);
exit();
Как же вы уже надоели. Одно по одному, тысячу раз.
так его, этот пехепе.
Хочу сказать, что я соглашаюсь, что это косяк. Что есть достаточное количество функций, которые несогласованы между собой. Как порядок аргументов, так и названия. И мне непонятны порывы оправдать это. Да это так.
Но меня как-то это не трогает.: )
Но меня как-то это не трогает.: )
это явно маркетинговый ход, причем удачный :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Весь PHP в двух строчках