Как стать автором
Обновить
3
0
Сергей @Seldon

Пользователь

Отправить сообщение
Sugar не следует ES6 в полной мере habrahabr.ru/post/217603/#comment_7449943
А вы попробуйте разок. Как-нибудь на досуге, на каком-нибудь маленьком проекте. О каких переработках и наработках вы говорите, я не понял.

Я бы с радостью но эта фитча недоделана и половинчата, поэтомуи начинать не хочется, 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) 

Только это не решает проблемы наличия такого еж метода у меня в библиотеке

String.isCyrrilic = function(){return false}

А если давать имена из 1000 символов, то все будет ваапще хорошо. А написав в любимой IDE «my name is». я получу подвисание в ожидании 100500 методов в автокомплите? И буду их разгребать? и опятьже почему обе библиотеки не могут иметь одинаковых префиксов? Как я понимаю префикс — 2-4 символа, вполне ожидаемо что 2 мои любимые библиотеки будут иметь одиаковый префикс.
Почему бы просто не оставить код ВАШЕЙ библиотеки внутри вашей библиотеки.
А главное объясните мне в чем будет выйгрыш? Где профит такого решения?
А моя библиотека делает это так:

Array.prototype.randomElement = function() {
        this.last = this[Math.floor(Math.random()*(this.length))];
	return this.last;
};
Array.prototype.last = function() {
	return this.last;
}
String.prototype.last = function() {
 	return this.split(" ").pop();
}


Имеет право на жизнь? Да! Ничуть не меньше вашего! А теперь подключите обе библиотеки и удачного дебагинга проекта.
Ну и по поводу руби, я бы также хотел возразить на счет такого подхода, имхо широкое применения таких приемов приводит к нечитаемсоти кода, да библиотека допустим изолирована от внешнего мира, но вот я использую вашу библиотеку, она опенсоурс и тут нахожу багу, решаю вам помочь и исправить её, идут в библиотеку, читаю ваш код, из-за подмены стандартных методов, читать его будет в 100 раз сложнее, за ошибки я могу принимать правильный код (ведь я думаю что метод работает по другому) и в итоге написать 100 остылей я только все сломаю, буду плеваться и тд. Зачем же так с людьми? Мне кажется такой подход нужен в крайних случаях, например:

вышла новая версия руби и там пофиксили многолетний баг — метод (простите не знаю руби. беру из головы) .map() у массива который проходится по всему массиву не учитывал последний элемент, вы это знали и в свой библиотеке исскусственно решали проблему. И тут все поправили, теперь метод все делает правильно. Но у вас нет времени сейчас на рефакторинг тонны кода для библиотеки, вы решаете быстренько поправить метод, вернув старый баг, дабы библиотека работала во всех версиях руби

Вот для таких временных решений имхо механизм идеален, но никак не в роли основного механизма организации кода.
Наверное дискуссия началась с моего коментария, но по сути не было там дискусии, просто набежало народу, который js в общем -то не знает да и основных принципов программирования тоже. (Хотя минусов наставили, ну да ладно)
Все уже давно решено, все уже давно определились со стратегией и любой адекватный программист скажет:
1) если вы расширяете прототип стандартного объекта, методом из спецификации котоый не поддерживается в старыж версиях браузера, ваш метод должен также работать по спецификации. Алгоритм здесь простой
а) Проверить есть ли метод в прототипе, если есть ничег оне делать
б) если нет — добавить свой, который работает аналогично спецификации
2) если вы расширяете прототип стандартного метода методом не из спецификации, то надо понимать что это путь анархии и если каждая библиотека будет такое делать, вы получите кучу конфликтов, которые порой можно отлавливать днями.

Не зря все современные библиотеки используют замыкания чтобы скрыть все свои внутренности а также имеют no conflict решения, чтобы можно было их переименовать.

О чем тут спорить я честно говоря не знаю, если вы заменяете стандартный метод нативного объекта нестандартным, вы осознанно стреляете себе в ногу и отмазки ну я же писал документация тут не работают! Представьте себе челока который знает спецификацию js, много лет работает js программистом и приходит к вам в проект, даже если он 10 раз прочтет ваши доки его руки будут использовать ваш нестандартный метод по стандарту js, просто из-за привычке, вы просто замедлите его работу. Ну а также он каждый раз будет лазить в доку перед тем как написать строчку кода, боясь что сейчас использует что-то не так.

А также я не вижу ни одного аргумента почему это вам нужно? Если вам нужен метод, выполяющий специальную функцию — добавьте его в свою библиотеку или утилитный «класс» MyClass.myMethod его будет в 100 раз проще найти, читающий код будет всегда знать что и как, понимать что происходит в коде

Речь уже далеко не про SugarJS, а про то что не надо расширять нативные объекты нестанждартной реализацией или методами, которые работают не по стандарту.
И отмазка иди читать доку — не работает!
Если я буду читать доку потмоу что вы изменили стандартный метод .map в прототипе массива то я буду тупо читать доки а не писать код. И даже опытный сеньер жс кодер будет вам писать 100500 ошибок, спотыкаясь на таких вещах.

Наверное стандарты для того и существуют чтобы их соблюдать и упрощать жизнь?
Статья, ради статьи, на хабре щас более 50% так
P.S. хотел как ответ на вышестоящий коментарий, сорри
Вы наверное путаете что-то? В прототип таких вещей как Object.prototype Array.prototype нельзя выносить кастомные методы, я лишь предложил туда выносить методы из спецификации если таковые не поддерживаются данными праузером, причем эти методы должны работать 100% по спецификации, чтобы вызвав .map() я не получил потом бредогого созания от автора.

Если вы сделали собственнвй метод для работы с массивом типо quickSort() не надо его пихать в прототим массива, это будет вносить путаницу Создайте свой класс или объект с утилитными методами.

По-моему, это просто глупо, когда апологеты JS разводят понты про протоипную модель,


Вы помоему плохо их читали, идите матчасть учить, они вам говорят что методы должны быть в прототипе для реализации правильного наследования, но они вам не говорят что надо засирать стандартные классы своми методами.
Вот что мне не нравиться в undescore — это то что они не стали выносить методы в прототипы нативных объектов js. То есть выносить .map() в прототип Array я считаю намного правильней ибо это приучает тебя писать в стили нового стандарта ECMAScript 5 (уже конечно не такого нового) и дает вам возможность скажем на мобильных устройствах не использовать библиоткеу да и вообще приучает к использованию нового апи. под _.method я бы выносил только те функции которые не попали в спецификацию
Тогда я боюсь желающих будет чуть больше чем 0.
Походу самый дорогой флагман, при том, что в нем ничего что могло бы оправдать цену, предрекаю провал продаж.
Названия идельного мира в вашей голове — коммунизм. Когда все люди станут отвественными, честными и не предвзятыми. Но надо понимать что не в ближайшую сотню лет
У гугла хватает в общем-то патентов, в том числе и странных не все там опенсоурс.
Простите, щас я буду троллить, но в троллинге глубокий смысл:
Почему скажем на роман дают 50-70 лет как на интеллектуальную собственность, а на алгоритм должны давать скажем год, ведь тут очень тонкая грань.
Вот взял программист код реализующий алгоритм, посмотрел на него и за пол года переписал полностью оптимизировав использование памяти, много поточности и тд, будет ли это являтся основой для патента? Или как это должно\не должно защищаться законом.
Вы наверное открывали мою ссылку выше, логичный вопрос как отличать обоснованный патент от необоснованного? Есть же понятие юзабилити, есть специалисты в этой области. И вот скажем специалист провел исследование, опросил и исследовал показатели 10 000 людей и реализовал идеальное расположение клавишь для клавиатуры или скажем идеальный интерфейс почтового клиента. Надо ли это защищать? Человек ведь работал. работал не меньше математиков, программистов, писателей.
Маленькая поправка алгоритмов/функциональности, по мне вы тут неточно выразились, копирование функциональности — это ок, да это двигает процесс. А вот копирование алгоритмов должно быть ограничено и также защищаться авторским правом. Может математики год работали над реализацией видео декодера, который стал в 3 раза быстрее, это труд и его результат должен быть защищен. Ведь написать код по уже готово алгоритму может «любой»
А тут вообще очень тонкая грань. Вот давайте с простого — пишите вы калькулятор, умножить, поделить, сложить, вычесть. Написали выложили и тут вам бац, приходит иск о том что вы нарушили патент на калькулятор. Но согласитесь что +,-,*,/ стандартные математические операции и глупо давать на них патент и вообще о чем-то рассуждать тут. А вот скажем вы сделали так чтобы калькулятор распознавал рукописный текст с тачскрина, тут уже другое дело.
И опять же правильней же патентовать не то, что ваш калькулятор распознает рукописый текст (хотя щас и это патентуют), а алгоритм распознания и код реализующий алгоритм.
Очнь непрастая сфера, много нюансов и просто так «Такой эксперт запросто напишет про музыку „ не получится решить проблему

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность