[value for i, value of ['a', 'b', 'c'][0...2]] # a, b
и до конца раздела — это вы о чем?
Во-первых не нужно писать of [arr], нужно in [arr]
Во вторых — смысла конструкции вообще не понял — может проще сразу было
Автору стоит вернуться к взрослой реальности.
Не хотите наш CS — ну и xрен с вами! Не нравится ответ на SO на CS — ну и хрен с вами!
Это ваши проблемы и не вам мне указывать где что и на чем писать.
Я же не начинаю ныть, что вот тут книжка по алгоритмам на сях, тут — на лиспе, а тут вообще не пойми чего? Раз оно надо мне, значит и с этим я разберусь.
Есть такой вопрос провокационный — а почему Вы не пишите на node.js?
Зачем Вы изобрели собственный механизм импорта\экспорта?
Почему не используете сторонние клиентские библиотеки — для работы с датой, строками и т.д? Всякие lodash-underscore уже стандарт де-факто.
Я уж молчу про то, что использование global — жуткий моветон, который еще как-то можно простить в тестах, но в продакшен-коде — ни-ни.
Я вот знаю про скрытые классы при создании объекта, про преобразования массива если он содержит разные типы данных, про преобразование полиморфных функций, а вот по поводу «скомпилированной сущности» в отношении регулярок — не, не видел. Может лишнего удумали?
Ох.
Уж положа руку на сердце по-моему там вообще ничего оптимизировать не надо.
Тем более изобретать велосипедов и «обходится без регулярки».
Регулярные выражения — простой и выразительный способ описания алгоритма обработки грамматики, с первого взгляда объясняющий что, зачем и почему тут происходит.
Более того — я твердо верю что это лучший и безальтернативный способ работы с грамматиками — так что их надо тупо выучить и применять.
Ну и основная идея поста была не в том, что что-то можно оптимизировать, а в том, что это накладно. Я не оперирую терминами «читабельность» и т.д. Тупо цифры: сложность — +столько-то, размер — +столько-то, effort — +столько-то. И в итоге поддержка кода превращается в ад. Как бы так вот.
PS. хм, ну и на что тут будет похож вариант «без регулярок»?
Погуглил про interning, выяснил что JS сам интернит строки-как-литерал, а динамически создаваемые — нет.
Однако идеи приведенного примера так и не понял — есть переменная, которая не используется, замыкание по идее возвращающее то же самое — профит-то в чем?
ой ли?
вот две записи, дающие одинаковый результат
Но почему первая — корректна, а вторая — путь на темную сторону?
Потому что:
Мы же не будем спорить о том, насколько неэффективно обращаться с массивом как объектом?
пример явно не удачный, потому как это же явно
ИМХО удачнее будет
и до конца раздела — это вы о чем?
Во-первых не нужно писать of [arr], нужно in [arr]
Во вторых — смысла конструкции вообще не понял — может проще сразу было
не?
Не, чтобы получить плоский список надо сказать
Автору стоит вернуться к взрослой реальности.
Не хотите наш CS — ну и xрен с вами! Не нравится ответ на SO на CS — ну и хрен с вами!
Это ваши проблемы и не вам мне указывать где что и на чем писать.
Я же не начинаю ныть, что вот тут книжка по алгоритмам на сях, тут — на лиспе, а тут вообще не пойми чего? Раз оно надо мне, значит и с этим я разберусь.
Я как бы не настаиваю, но есть некие best practice, игнорировать которые черевато боком, мне ли не знать.
Но в любом случае — успехов, хоть я лично за unix-way и держусь подальше от комбайнов.
Зачем Вы изобрели собственный механизм импорта\экспорта?
Почему не используете сторонние клиентские библиотеки — для работы с датой, строками и т.д? Всякие lodash-underscore уже стандарт де-факто.
Я уж молчу про то, что использование global — жуткий моветон, который еще как-то можно простить в тестах, но в продакшен-коде — ни-ни.
А что быстрее будет работать — честно говоря пофик, микрооптимизации меня никогда не интересовали.
(www\.[A-z\d\.\+\-]+) было что-то типа /(w{3}\.[-a-z\d+.]+)/i
Пишем на coffee, жмем clinch-ем и вуаля!
Получается что-то типа такого — демо и исходники.
Плюс еще есть TinyData, которая полноценный запросник по слабоструктурированным данным :)
Изменения в спеках и объяснялка на SO.
Я вот знаю про скрытые классы при создании объекта, про преобразования массива если он содержит разные типы данных, про преобразование полиморфных функций, а вот по поводу «скомпилированной сущности» в отношении регулярок — не, не видел. Может лишнего удумали?
Могу я попросить ссылку на документацию (вероятно в реализациях браузеров?) об этом факте?
Просто инлайновый быстрее — по многим очевидным причинам.
У меня вот как-то другие получаются результаты:
Или я не верно понял идею?
Это о чем? я знаю только о поведении реплейса с флагом 'g' и экспериментальном флаге 'y', но у нас тут другая ситуация вроде.
PS. А за что человека-то заминусовали — все верно заметил.
На мой вкус ничего там делать было не надо, данных проФайЛера (я правильно понял?) не было конечно — virgin premature.
Уж положа руку на сердце по-моему там вообще ничего оптимизировать не надо.
Тем более изобретать велосипедов и «обходится без регулярки».
Регулярные выражения — простой и выразительный способ описания алгоритма обработки грамматики, с первого взгляда объясняющий что, зачем и почему тут происходит.
Более того — я твердо верю что это лучший и безальтернативный способ работы с грамматиками — так что их надо тупо выучить и применять.
Ну и основная идея поста была не в том, что что-то можно оптимизировать, а в том, что это накладно. Я не оперирую терминами «читабельность» и т.д. Тупо цифры: сложность — +столько-то, размер — +столько-то, effort — +столько-то. И в итоге поддержка кода превращается в ад. Как бы так вот.
PS. хм, ну и на что тут будет похож вариант «без регулярок»?
Однако идеи приведенного примера так и не понял — есть переменная, которая не используется, замыкание по идее возвращающее то же самое — профит-то в чем?