Pull to refresh

Comments 18

Рискую вызвать, гнев толпы, но автору респект. Конечно это извращение, но я с удовольствием потрачу пару часов, на то, чтоб покопаться в этом чуде.
В смысле?
В PHP основные типы примитивы, не объекты. Да и какие высокоуровневые функции JavaScript отсутствуют в PHP?
В том смысле, что API в PHP достаточно непоследовательно, больше системы прослеживается в JS.

А данная разработка не очень мне понятна, скорее усматриваю стремление скорейшей адаптации PHP-шников к JS, что вызывает у меня опасение, что вместо нормального обучения JS будут его использовать в стиле пхп, т.е. через одно место.
Это историческая проблема. Разработчикам PHP, привыкшим к такому будет удобнее пользоваться библиотекой, если параметры у функций будут аналогичными, а не «более правильными».

Думаю, библиотека создана для упрощения входа в JS после PHP, от этого и результат соответственный.
PHP для меня страшный сон, который я хочу забыть!
А те кто будет писать в стиле PHP на JS, и использовать такие библиотеки, буду быть стулом по голове на собеседовании, чтоб не мучился.
Такое впечатление, что у Вас «стиль PHP» прочно ассоциируется с процедурным программированием, которое в больших проектах, действительно, скорее всего приведет к коллапсу.

А, как известно, парадигму ООП можно применять даже на ассемблере. Так что PHP тут не причем — поддержка ООП в нем вполне себе хорошо реализована.
Частенько бывает, что пехепешников «заставляют» писать на JS. Вот вы взяли меня на работу на php-сервер-сайд, о JS ни в вакансии ни слова не было, ни на собеседовании речи не возникло. Или возникло но чисто в контексте манипулирования DOM, но про стандартные JS библиотеки для строк, чисел и т. п. не заикались. И вдруг «внезапно» и «вчера» требуется какая-то фича на клиент-сайде, использующая стандартную библиотеку, и кроме меня её писать некому. И «нужно было вчера» реально проблема, заказчик звонит каждые пять минут, кричит, слюной брызжет, грозит неустойками и «понятиями».

Вы реально предпочтёте, чтобы я открыл мануал и начал читать, а как же на JS реализовывать то, что на PHP я реализовал бы за минуту? Вот понятия не имею, можно ли на JS штатно посчитать md5 хэш. В PHP — это стандартная функция, в JS — не знаю, часик мануал полистаю, возможно не найду, залезу в исходники php, перепишу с C на JS. И всё это вместо того, чтобы использовать одну функцию из php.js. Зато стулом не получу, да? :) Пример утрирован, конечно, но суть, думаю, ясна.
все проблемы решаются гуглением в считанные секунды — я не помню многих PHP функций (в строковых всегда путаюсь и смотрю подсказки в IDE) — и все время забывают что в JS приведение типа не (int) а parseInt() — да это вызывает некоторые трудности, но уж далеко не фатальные —
Вообще подходы у JS и PHP настолько разные — что смешивать их не имеет смысла. Поковыряйтесь, например в Backbone и поймете о чем речь.
При желании можно написать классы PHP, эмулирующие объектные типы JS. Как-то нечто подобное даже начинал делать, правда эмулировал Ruby-библиотеку, а не JS, но забил так как упёрся в ограничения синтаксиса, в ачстности в невозможность переопределять операторы.
пока насвкидку не знаю, где это можно применить, но в любом случае штука крайне занятная…
Когда-то забредал туда, брал некоторые реализации как основу, переделывал для себя. Как новичку JavaScript мне это было очень полезно.
С одного ракурса — можно улыбнуться, вспомнив о несовершенстве самой стандартной библиотеки PHP.

С другой же стороны, это может быть удобно — хотя и не берусь утвердать, что такой подход правильный — разработчику, который проводит большую часть времени за пыхой, и недоволен скудностью хелперов ванильного JS. Ведь когда твой любимый язык позволяет проще решать рутинные задачи — это бросается в глаза.

Сходным образом думали авторы Sugar JS, портировав в JavaScript красоту и элегантность Ruby. Кстати, если думать только о расширении стандартного функционала, то я бы отдал предпочтение именно Sugar JS.
Only those users with full accounts are able to leave comments. Log in, please.