сублайм самый нормальный

atom красивый, но тормознутый потому что он же пислася вроде как браузернео приложение, а потом перевели его на desktop

atom красивый, но тормознутый потому что он же пислася вроде как браузернео приложение, а потом перевели его на desktop

++

через электрон вроде

через electron

http://electron.atom.io/

vscode быстрее sublime

в самом низу страницы можно посмотреть где атом используется

да какбы devtool с —harmony не пашет

ставишь eval и можно через браузер

не пробывал

хороший

?

@tom910 а подробнее??

это отдельная тулза или примочка?

это отдельная тулза или примочка?

опция

devtool: ‘eval’

visual studio ….

для ангуляр девелоперов наверное удобней

атом фигня

а ты чем знаменит чтобы писать что атом фигня

я написал почему атом плохой

высказал свое мнение

по ide

я ничем не знаменит, если я вас задел чем-то, то извеняй

надо просто принять что фигни нет ? и что сотни тысяч людей которые выбрали атом наверное этот выбор сделали не так просто ? все мы разные

я пользовался атом , vs, subl

аналогично

и остановился на атоме после многих лет в сублиме

многие пишут все на vim )

и хотя я vim вообще не понимаю не стоит же назвать его фигней ?

это труд кучи людей

atom удобней тем что более настроеный и понятней с подсказками

ну те кто умеет то наверное для них это не заменимо

у меня тупо сломался трекпад - и на обычной дискретной мышке я не вижу разницы по скорости между атомом и сублимом

правда без мышки не представляю, сложно если кода много

раньше скрол напрягал

самый лучший редактор это на windows notepad стандартный

far + colorer мне его последние много лет не хватает

?

.bind() полностью пересоздаёт метод? Насколько более ресурсоёмко сделать .bind(), чем просто передать функцию в переменную?

"Насколько более ресурсоёмко сделать .bind(), чем просто передать функцию в переменную?" Вопрос не понятен

Уже решил.

bind() создаёт обёртку.

По сути, созданная обёртка — есть декоратор, который делает originalMethod.call(cоntext, arg1, arg2, ...)

Я беспокоился о том, насколько повлияет на производительность использование bind() в конструкторе класса для копирования определённых методов в другие объекты с привязкой контекста.

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

Что исходники v8 говорят об этом?

Клёвая шутка. Я не изучал C++.

Я беспокоился о том, насколько повлияет на производительность использование bind() в конструкторе класса для копирования определённых методов в другие объекты с привязкой контекста.

Как это у тебя выглядит?

Как это у тебя выглядит?

https://github.com/bigslycat/pbem/blob/master/lib/Block.js#L18

А зачем ты так себе жизнь усложняешь?

Ты решил сделать эти функциями не методами чтобы контекст уж точно не переопределялся или как?

Это хелперы, функции внутри шаблона.

Но они работают с контекстом экземляра класса.

Но они работают с контекстом экземляра класса.

Ну так и сделать их методами. Либо явно передавать в них ctx.

То бишь, передавать в шаблон сам экземпляр?

А то выглядит будто ты monkey-patching делаешь какой-то.

=))

То бишь, передавать в шаблон сам экземпляр?

Ну да. Но лучше, наверное, просто сделать их методами. Они же таковые и есть.

Так ведь тогда они потеряют контекст.

Ну, если второе.

Почему вдруг?

Если я передам экземпляр, то всё ок. Только в использовании будет уже не так удобно.

Ну, допустим, в шаблоне будет вызов block('header'). Ему потребуется контекст экземляра класса, т.к. он содержит персональные конфиг и данные.

Не понял с чего вдруг методы потеряют контекст.

Class.prototype.func когда вызывается от inst.func всегда имеет this же

Или там у тебя кто-то снаружи контекст портит?

Хм. Так. А можно ссылку, чтобы по-подробнее ознакомиться?

ERROR: S client not available

Клёвая шутка. Я не изучал C++.

я тоже - там читается довольно просто код

this.local({ mod: this.getMod, isMod: this.isMod, element: this.createElement, attributes: this.getAttributes });

Хм. Так. А можно ссылку, чтобы по-подробнее ознакомиться?

Ссылку на что? Есть методы экземпляра, которые ищутся в прототипе и this'ом которых будет сам экземпляр.

Контекст в примере выше потерян.

Есть методы "класса"

А что у тебя функция local делает?

Я чёт не нашёл её быстрым взглядом с телефона.

Это методы экземпляра класса.

local() устанавливает локальные переменные для шаблона. Таким образом туда попадают и хелперы.

Это единственный вариант.

А, я понял. Это какой-то проброс обработчиков в шаблонизатор.

Дада.

Ну тогда нормальная практика юзать bind

Печаль в том, что это БЭМ, и шаблон состоит из кучи блоков. В норме — каждый ДОМ-элемент — это, в переводе на мою либу, класс.

Пардон, экземпляр класса.

Честно говоря мне сложно было понимать твой код. Много всяких примесей и всего такого. Но может дело в специфике шаблонизатора.

Ну, код кое-где снабжён абстракциями. Наверное, не всегда к месту. Ещё есть вопросы к его разбиению по файлам. Шаблонизатор здесь не при чём. =)

Зато здесь есть вариант реализовать кеширование уже отрендеренного вывода отдельно для каждого блока.

http://benediktmeurer.de/2015/12/25/a-new-approach-to-function-prototype-bind/ 7 месяцев назад вмержили такой подход

но уже походу снова переписали

хотя в ноде может и старее пользоваться или эта версия

Там байндинг находится за пределами теста.

А у меня это часть нагрузки.

дело не в тесте (смотри кот)

Сам байндинг в смысле.

У тебя операция один раз выполняется?

О_о

или тебя интересует кэширование bind функции?

Нет. Я говорил о другом кешировании. =)

Это уже другая тема.

Байндинг выполняется при каждом создании экземпляра.

Таких созданий много.