Ну в общем вы поняли что в вопросах о спецификации вы были не правы.
Вы никогда не знаете когда ваш код понадобится подключать из вне. Вот мы разрабатываем сервис по бронированию гостиниц, жд и авиа билетов, недавно нам поступило требования реализовать возможность подключения виджетов этого сервиса во внешние сайты, без Iframe, основной код ведь у нас берется с самого сервиса, работа с даннами и тд никуда не делаись, мы просто дописали новое вью для отрисовки нового вида и юзаем идиный код на сайте и в подключаемых виджетах. А было бы что-то типо sugarjs? был бы повод переписать (
Sugarjs учит только плохому, вы приучаетесь использовать методы не по спецификации, потом долго будите отучаться.
как я сказал я не против добавление каки-то плюшек, но сделайте map() и propertyMap() к примеру. Я не знаю какие еще подводные камни можно встретить, предполагаю что многие.
Больше всего мне не нравиться что Sugarjs недоделан с любой стороны и ES6 полностью не имлементит, и методы стандартные портит и все стандартные методы не юзает, те же методы Math не все перехали в Number.
Хорошая библиотека для сайта хомячка. но не для серьезного проекта, который мейнтейнить многие годы!
А давайте мы сейчас будем серьезными, прекратим демагогию, запишем себе навсегда что developer.mozilla.org — это не спецификация ES, пойдем и скачаем спецификацию найдем описание стандартного метода Array.prototype.map и увидим там четкое руководство кидать TypeError если в параметре не функция. И на этом вопрос не соответствия спецификации будет закрыт!
Я не юзал Sugar, но в начале дискуссия я был не против юзания либы, однако сейчас я склоняюсь категорично к ответу нет! И в частности если человек хотел бы подключить библиотеку только для того чтобы писать по стандарту ES6 у него не получится ибо неизвестно сколько еще подводных камней мы тут встретим.
И в третьих в реальных проектах подобное фактически не применимо, вы можете представить себе LeafLet или Jquery которые тянут за собой подобный Sugar и ломают проект, а можете себе представить backbone который вместо андрескора сломает проект благодаря использованию sugar?
Область применения Sugar имхо только домашние проекты которые не поползут в паблик, ибо понадобиться вам выкинуть js api на ружу а у вас там везде подобное sugar юзается, да и то вас эта либа приучит писать криво. Потом будите месяцами отучаться от нестандартных костылей.
Слишком много сахара — не есть хорошо, ищите золотую середину.
Вы понимаете что по спецификации ES в случае если параметр мутода .map() получает не функцию мы должны кинуть TypeError.
Давайте тогда говорить что Sugar добавляет часть функций нативные объекты, некоторые из функций могут повторять стандарт ES.
Не надо громких заявлений
Sugar неукоснительно следует спецификации ES6
Почувствуйте разницу. Неукоснительное следование ES6 значит что в браузере который поддерживает ES6 стандарт я могу отключить sugar и получить рабочий код.
А вы попробуйте разок. Как-нибудь на досуге, на каком-нибудь маленьком проекте. О каких переработках и наработках вы говорите, я не понял.
Я бы с радостью но эта фитча недоделана и половинчата, поэтомуи начинать не хочется, sugar добавил методы но и пропустил, типо atan2
Или например у sugar Array.prototype.map работает не по стандарту, о чем я и сожалею ['one','two','three'].map('length') ибо по стандарту фргумент map должен быть функцией, согласитесь что уловить этот момент нереально, даже если сказат ьчеловеку что используется sugarjs, ему придется каждый нативный метод сверять с апи библиотеки, это имхо ограничивает свободу.
Я сам лично юзаю polyfill для ES5 в старых браузерах — и да это чудесно, радуюсь и люблю их. Вот еще идея есть юзать препроцессор для arrow function.
Я люблю нувые удобные плюшки, мне нравиться идея с pipeline «return arr.last().floor().debug();» обеими руками за, а еще я прям тащусь от реализации из кофескрипт «if (obj?.obj1?().obj3) { code… }» и хотел бы такое в js.
Но меня угнетают подобные искривления типо как с .map это и есть корень зла — изменение поведения стандартной функции.
Предположим, разработчик Вася, который пишет библиотеку Vasya, не стесняется делать манки-патчи: из своей библиотеки он (пере)определяет методы стандартных объектов при помощи конструкции refine.
«Он переопределяет методы стандартных объектов» — ваши слова. Ясное дело что извращаться конкретно над length нието так не будет, но есть же много других методов, которые полне могут вот так заменить, по вашей же логике, заметьте.
Помоему вы сейчас о другом, разные версии руби — ок, не о том речь. Но если я вас правильно понял вы в статье сказали что можете переопредилть стандартный метод нативного объекта только для своего класса\библиотеки.
То есть был метод String.length() который возвращал кол-во символов, вы переопределил его как String.length — который возврвщает кол-во символов минус 1. В итоге я писал что человек который будет читать ваш код подобную тонкость легко выпустит из головы и от сюда у него возникнут разночтения и проблемы восприятия.
Я сейчас общался с вами в стиле «Расширение нативных объектов JavaScript — зло ли это? » А не конкретно о SugarJS. Потому как подобных библиотек много и обсуждать каждую в отдельности не вижу смысла, так что предлагаю окончательно обстрагировать от конкретной либы и обсуждать проблему как таковую.
Вы подняли тему расширения нативных объектов в JS и почемуто всю статью посвятили SugarJS и считаете, что это истина в последней инстанции и только это мы обсуждаем. Если это так, я требую переименовать статью в «Рассуждения о SugarJS „ вопрос будет снят.
Я же рассуждал о первоочередной проблеме, который вы поставили на первое место в статье “Расширение нативных объектов JavaScript — зло ли это? „, это было ваше решение — не мое.
Отсюда — не вижу плохого в использовании библиотеки типо SugarJS в проекте. Я вижу проблему когда вы сами начинате копать прототипы нативных объектов, это чревато вашими же ошибками ну и конечно тем, что вы врятли будите следить за обновлениями спецификации.
также я против того чтобы библиотека типо JQuery, backbone, angular изменяла прототипы нативных объектов ибо вот это будет проблемой если КАЖДАЯ библиотка добавит свое. Если библиотека чисто заточена на синтаксический сахар — то велком.
Теперь по поводу тоскливо, конечно приятно писать в стиле паттерна pipeline и JQ нас прикчил к этому в js, но все-таки сам js имеет некую историю и тут применили некий другой подход.
Поэтому такого arr.last().floor().debug(); в js босюь мы не увидим, ну или по крайне мере это большая переработка, ведь если уж делать то надо поддержать все нативные методы и возможности. Может какие наработки в этом стиле уже есть. надо погуглить на гитхабе.
String.isCyrrilic = function(){return true}
"test".isCyrrilic()
TypeError: Object test has no method 'isCyrrilic'
ой…
То что вы метод добавили не в прототип, а прямо в класс проблему нашу не решило, вы загадили методами сам объект String (давате называть его класс, хотя правильно было бы функция конструктор). Ваш метод isCyrrilic теперь недоступен для объектов порождаемых конструктором, так как поиск будет происходить по prototype chain и scope, и теперь вам придется обращаться к нему так
String.isCyrrilic(obj)
Только это не решает проблемы наличия такого еж метода у меня в библиотеке
А если давать имена из 1000 символов, то все будет ваапще хорошо. А написав в любимой IDE «my name is». я получу подвисание в ожидании 100500 методов в автокомплите? И буду их разгребать? и опятьже почему обе библиотеки не могут иметь одинаковых префиксов? Как я понимаю префикс — 2-4 символа, вполне ожидаемо что 2 мои любимые библиотеки будут иметь одиаковый префикс.
Почему бы просто не оставить код ВАШЕЙ библиотеки внутри вашей библиотеки.
А главное объясните мне в чем будет выйгрыш? Где профит такого решения?
Ну и по поводу руби, я бы также хотел возразить на счет такого подхода, имхо широкое применения таких приемов приводит к нечитаемсоти кода, да библиотека допустим изолирована от внешнего мира, но вот я использую вашу библиотеку, она опенсоурс и тут нахожу багу, решаю вам помочь и исправить её, идут в библиотеку, читаю ваш код, из-за подмены стандартных методов, читать его будет в 100 раз сложнее, за ошибки я могу принимать правильный код (ведь я думаю что метод работает по другому) и в итоге написать 100 остылей я только все сломаю, буду плеваться и тд. Зачем же так с людьми? Мне кажется такой подход нужен в крайних случаях, например:
вышла новая версия руби и там пофиксили многолетний баг — метод (простите не знаю руби. беру из головы) .map() у массива который проходится по всему массиву не учитывал последний элемент, вы это знали и в свой библиотеке исскусственно решали проблему. И тут все поправили, теперь метод все делает правильно. Но у вас нет времени сейчас на рефакторинг тонны кода для библиотеки, вы решаете быстренько поправить метод, вернув старый баг, дабы библиотека работала во всех версиях руби
Вот для таких временных решений имхо механизм идеален, но никак не в роли основного механизма организации кода.
Наверное дискуссия началась с моего коментария, но по сути не было там дискусии, просто набежало народу, который js в общем -то не знает да и основных принципов программирования тоже. (Хотя минусов наставили, ну да ладно)
Все уже давно решено, все уже давно определились со стратегией и любой адекватный программист скажет:
1) если вы расширяете прототип стандартного объекта, методом из спецификации котоый не поддерживается в старыж версиях браузера, ваш метод должен также работать по спецификации. Алгоритм здесь простой
а) Проверить есть ли метод в прототипе, если есть ничег оне делать
б) если нет — добавить свой, который работает аналогично спецификации
2) если вы расширяете прототип стандартного метода методом не из спецификации, то надо понимать что это путь анархии и если каждая библиотека будет такое делать, вы получите кучу конфликтов, которые порой можно отлавливать днями.
Не зря все современные библиотеки используют замыкания чтобы скрыть все свои внутренности а также имеют no conflict решения, чтобы можно было их переименовать.
О чем тут спорить я честно говоря не знаю, если вы заменяете стандартный метод нативного объекта нестандартным, вы осознанно стреляете себе в ногу и отмазки ну я же писал документация тут не работают! Представьте себе челока который знает спецификацию js, много лет работает js программистом и приходит к вам в проект, даже если он 10 раз прочтет ваши доки его руки будут использовать ваш нестандартный метод по стандарту js, просто из-за привычке, вы просто замедлите его работу. Ну а также он каждый раз будет лазить в доку перед тем как написать строчку кода, боясь что сейчас использует что-то не так.
А также я не вижу ни одного аргумента почему это вам нужно? Если вам нужен метод, выполяющий специальную функцию — добавьте его в свою библиотеку или утилитный «класс» MyClass.myMethod его будет в 100 раз проще найти, читающий код будет всегда знать что и как, понимать что происходит в коде
Речь уже далеко не про SugarJS, а про то что не надо расширять нативные объекты нестанждартной реализацией или методами, которые работают не по стандарту.
И отмазка иди читать доку — не работает!
Если я буду читать доку потмоу что вы изменили стандартный метод .map в прототипе массива то я буду тупо читать доки а не писать код. И даже опытный сеньер жс кодер будет вам писать 100500 ошибок, спотыкаясь на таких вещах.
Наверное стандарты для того и существуют чтобы их соблюдать и упрощать жизнь?
Вы наверное путаете что-то? В прототип таких вещей как Object.prototype Array.prototype нельзя выносить кастомные методы, я лишь предложил туда выносить методы из спецификации если таковые не поддерживаются данными праузером, причем эти методы должны работать 100% по спецификации, чтобы вызвав .map() я не получил потом бредогого созания от автора.
Если вы сделали собственнвй метод для работы с массивом типо quickSort() не надо его пихать в прототим массива, это будет вносить путаницу Создайте свой класс или объект с утилитными методами.
По-моему, это просто глупо, когда апологеты JS разводят понты про протоипную модель,
Вы помоему плохо их читали, идите матчасть учить, они вам говорят что методы должны быть в прототипе для реализации правильного наследования, но они вам не говорят что надо засирать стандартные классы своми методами.
Вот что мне не нравиться в undescore — это то что они не стали выносить методы в прототипы нативных объектов js. То есть выносить .map() в прототип Array я считаю намного правильней ибо это приучает тебя писать в стили нового стандарта ECMAScript 5 (уже конечно не такого нового) и дает вам возможность скажем на мобильных устройствах не использовать библиоткеу да и вообще приучает к использованию нового апи. под _.method я бы выносил только те функции которые не попали в спецификацию
Названия идельного мира в вашей голове — коммунизм. Когда все люди станут отвественными, честными и не предвзятыми. Но надо понимать что не в ближайшую сотню лет
Вы никогда не знаете когда ваш код понадобится подключать из вне. Вот мы разрабатываем сервис по бронированию гостиниц, жд и авиа билетов, недавно нам поступило требования реализовать возможность подключения виджетов этого сервиса во внешние сайты, без Iframe, основной код ведь у нас берется с самого сервиса, работа с даннами и тд никуда не делаись, мы просто дописали новое вью для отрисовки нового вида и юзаем идиный код на сайте и в подключаемых виджетах. А было бы что-то типо sugarjs? был бы повод переписать (
Sugarjs учит только плохому, вы приучаетесь использовать методы не по спецификации, потом долго будите отучаться.
как я сказал я не против добавление каки-то плюшек, но сделайте map() и propertyMap() к примеру. Я не знаю какие еще подводные камни можно встретить, предполагаю что многие.
Больше всего мне не нравиться что Sugarjs недоделан с любой стороны и ES6 полностью не имлементит, и методы стандартные портит и все стандартные методы не юзает, те же методы Math не все перехали в Number.
Хорошая библиотека для сайта хомячка. но не для серьезного проекта, который мейнтейнить многие годы!
И на этом вопрос не соответствия спецификации будет закрыт!
Я не юзал Sugar, но в начале дискуссия я был не против юзания либы, однако сейчас я склоняюсь категорично к ответу нет! И в частности если человек хотел бы подключить библиотеку только для того чтобы писать по стандарту ES6 у него не получится ибо неизвестно сколько еще подводных камней мы тут встретим.
И в третьих в реальных проектах подобное фактически не применимо, вы можете представить себе LeafLet или Jquery которые тянут за собой подобный Sugar и ломают проект, а можете себе представить backbone который вместо андрескора сломает проект благодаря использованию sugar?
Область применения Sugar имхо только домашние проекты которые не поползут в паблик, ибо понадобиться вам выкинуть js api на ружу а у вас там везде подобное sugar юзается, да и то вас эта либа приучит писать криво. Потом будите месяцами отучаться от нестандартных костылей.
Слишком много сахара — не есть хорошо, ищите золотую середину.
Давайте тогда говорить что Sugar добавляет часть функций нативные объекты, некоторые из функций могут повторять стандарт ES.
Не надо громких заявлений
Почувствуйте разницу. Неукоснительное следование ES6 значит что в браузере который поддерживает ES6 стандарт я могу отключить sugar и получить рабочий код.
Я бы с радостью но эта фитча недоделана и половинчата, поэтомуи начинать не хочется, sugar добавил методы но и пропустил, типо atan2
Или например у sugar Array.prototype.map работает не по стандарту, о чем я и сожалею ['one','two','three'].map('length') ибо по стандарту фргумент map должен быть функцией, согласитесь что уловить этот момент нереально, даже если сказат ьчеловеку что используется sugarjs, ему придется каждый нативный метод сверять с апи библиотеки, это имхо ограничивает свободу.
Я сам лично юзаю polyfill для ES5 в старых браузерах — и да это чудесно, радуюсь и люблю их. Вот еще идея есть юзать препроцессор для arrow function.
Я люблю нувые удобные плюшки, мне нравиться идея с pipeline «return arr.last().floor().debug();» обеими руками за, а еще я прям тащусь от реализации из кофескрипт «if (obj?.obj1?().obj3) { code… }» и хотел бы такое в js.
Но меня угнетают подобные искривления типо как с .map это и есть корень зла — изменение поведения стандартной функции.
«Он переопределяет методы стандартных объектов» — ваши слова. Ясное дело что извращаться конкретно над length нието так не будет, но есть же много других методов, которые полне могут вот так заменить, по вашей же логике, заметьте.
То есть был метод String.length() который возвращал кол-во символов, вы переопределил его как String.length — который возврвщает кол-во символов минус 1. В итоге я писал что человек который будет читать ваш код подобную тонкость легко выпустит из головы и от сюда у него возникнут разночтения и проблемы восприятия.
Поправьте если я не так говорю.
Вы подняли тему расширения нативных объектов в JS и почемуто всю статью посвятили SugarJS и считаете, что это истина в последней инстанции и только это мы обсуждаем. Если это так, я требую переименовать статью в «Рассуждения о SugarJS „ вопрос будет снят.
Я же рассуждал о первоочередной проблеме, который вы поставили на первое место в статье “Расширение нативных объектов JavaScript — зло ли это? „, это было ваше решение — не мое.
Отсюда — не вижу плохого в использовании библиотеки типо SugarJS в проекте. Я вижу проблему когда вы сами начинате копать прототипы нативных объектов, это чревато вашими же ошибками ну и конечно тем, что вы врятли будите следить за обновлениями спецификации.
также я против того чтобы библиотека типо JQuery, backbone, angular изменяла прототипы нативных объектов ибо вот это будет проблемой если КАЖДАЯ библиотка добавит свое. Если библиотека чисто заточена на синтаксический сахар — то велком.
Теперь по поводу тоскливо, конечно приятно писать в стиле паттерна pipeline и JQ нас прикчил к этому в js, но все-таки сам js имеет некую историю и тут применили некий другой подход.
Поэтому такого arr.last().floor().debug(); в js босюь мы не увидим, ну или по крайне мере это большая переработка, ведь если уж делать то надо поддержать все нативные методы и возможности. Может какие наработки в этом стиле уже есть. надо погуглить на гитхабе.
ой…
То что вы метод добавили не в прототип, а прямо в класс проблему нашу не решило, вы загадили методами сам объект String (давате называть его класс, хотя правильно было бы функция конструктор). Ваш метод isCyrrilic теперь недоступен для объектов порождаемых конструктором, так как поиск будет происходить по prototype chain и scope, и теперь вам придется обращаться к нему так
Только это не решает проблемы наличия такого еж метода у меня в библиотеке
Почему бы просто не оставить код ВАШЕЙ библиотеки внутри вашей библиотеки.
А главное объясните мне в чем будет выйгрыш? Где профит такого решения?
Имеет право на жизнь? Да! Ничуть не меньше вашего! А теперь подключите обе библиотеки и удачного дебагинга проекта.
вышла новая версия руби и там пофиксили многолетний баг — метод (простите не знаю руби. беру из головы) .map() у массива который проходится по всему массиву не учитывал последний элемент, вы это знали и в свой библиотеке исскусственно решали проблему. И тут все поправили, теперь метод все делает правильно. Но у вас нет времени сейчас на рефакторинг тонны кода для библиотеки, вы решаете быстренько поправить метод, вернув старый баг, дабы библиотека работала во всех версиях руби
Вот для таких временных решений имхо механизм идеален, но никак не в роли основного механизма организации кода.
Все уже давно решено, все уже давно определились со стратегией и любой адекватный программист скажет:
1) если вы расширяете прототип стандартного объекта, методом из спецификации котоый не поддерживается в старыж версиях браузера, ваш метод должен также работать по спецификации. Алгоритм здесь простой
а) Проверить есть ли метод в прототипе, если есть ничег оне делать
б) если нет — добавить свой, который работает аналогично спецификации
2) если вы расширяете прототип стандартного метода методом не из спецификации, то надо понимать что это путь анархии и если каждая библиотека будет такое делать, вы получите кучу конфликтов, которые порой можно отлавливать днями.
Не зря все современные библиотеки используют замыкания чтобы скрыть все свои внутренности а также имеют no conflict решения, чтобы можно было их переименовать.
О чем тут спорить я честно говоря не знаю, если вы заменяете стандартный метод нативного объекта нестандартным, вы осознанно стреляете себе в ногу и отмазки ну я же писал документация тут не работают! Представьте себе челока который знает спецификацию js, много лет работает js программистом и приходит к вам в проект, даже если он 10 раз прочтет ваши доки его руки будут использовать ваш нестандартный метод по стандарту js, просто из-за привычке, вы просто замедлите его работу. Ну а также он каждый раз будет лазить в доку перед тем как написать строчку кода, боясь что сейчас использует что-то не так.
А также я не вижу ни одного аргумента почему это вам нужно? Если вам нужен метод, выполяющий специальную функцию — добавьте его в свою библиотеку или утилитный «класс» MyClass.myMethod его будет в 100 раз проще найти, читающий код будет всегда знать что и как, понимать что происходит в коде
И отмазка иди читать доку — не работает!
Если я буду читать доку потмоу что вы изменили стандартный метод .map в прототипе массива то я буду тупо читать доки а не писать код. И даже опытный сеньер жс кодер будет вам писать 100500 ошибок, спотыкаясь на таких вещах.
Наверное стандарты для того и существуют чтобы их соблюдать и упрощать жизнь?
P.S. хотел как ответ на вышестоящий коментарий, сорри
Если вы сделали собственнвй метод для работы с массивом типо quickSort() не надо его пихать в прототим массива, это будет вносить путаницу Создайте свой класс или объект с утилитными методами.
Вы помоему плохо их читали, идите матчасть учить, они вам говорят что методы должны быть в прототипе для реализации правильного наследования, но они вам не говорят что надо засирать стандартные классы своми методами.