@Petroveg Ну для сокрытия данных и символы должны быть в IIFE обернуты :) Методы, работающие с приватными данными из замыкания, нужно объявлять в том же замыкании - лишние ресурсы, когда символы - обычные свойства объекта, с ними могут работать и методы прототипа.
@Fesor
> Символы не участвуют в обходе объекта через for-in.
> Символы отсутствуют в массиве ключей, получаемых через Object.keys.
> Символы уникальны - их не подобрать как неперечислимую строку-ключ.
> Object.getOwnPropertySymbols - единственный способ получить символы - как и Object.getOwnPropertyNames, необходим для низкоуровневых операций, например, клонирования объекта и не предназначен для повсеместного использования.
@Fesor getOwnPropertySymbols - рефлексия. Полностью приватными символы, конечно, не являются, но, пожалуй, их можно назвать таковыми и использовать в большинстве случаев, когда необходимо скрыть данные - уж явно быстрее и красивее замыканий будут. У меня в проектах символы используются именно как ключи приватных свойств.
@vasIvas ох ты ж хоспади... Вкратце: первая ссылка - спецификация стандарта Promise A+, которого поддерживается большинство библиотек, довольно абстрактного. По нему у инстансов обещаний гарантирован только метод then, описываются состояния обещаний и как выполняется их разрешение. Вторая - спецификация Promise из ECMAScript 6, который в будущем будет доступен в javascript искаропки. Внутрянка незначительно отличается от A+, спецификация куда более конкретна - конструктор Promise, у инстансов добавлен метод cath, статические методы resolve, reject и 2 метода работы с коллекциями - all и race, но все эти методы - сахар над then. Третья ссылка - простейший полифил (имплементация недостающего по стандарту функционала) последнего. И программисты, использующие библиотеку, тоже пользователи. Ферштейн, надеюсь?
@vasIvas при чем здесь строки? У меня реализация по спецификации заняла чуть больше 100 строк. Полифил Promise ES6, ссылку на который скинул - три сотни. Если вы так восприняли спецификацию, где всё предельно подробно расписано и которой нужно следовать как минимум для обеспечения совместимости и оправдания ожиданий пользователя, то действительно - они для вас непостижимы.
@Fesor простая реализация - возможно, но когда в своё время их разбирал и реализовывал по спеке чуть моск не сломал. Разминка для мозгов - хорошо, но если человек идет сюда с подобным вопросом вместо того, что бы спросить у поисковика - я бы посоветовал с этим не заморачиваться и воспринимать их как черный ящик.
@pofigizm как... вот так: Function('return 42')(); // => 42
Ну а про "если забыть про json" и написано последнее предложение, что тут еще можно добавить.
@anonymous само собой, ссылка на конструктор, если не поняли.
object.exceptions[key].prototype.constrictor = object.exceptions[key];
против вашего
this.constructor = object.exceptions.IncorrectLink;
Какой к черту новый прототип на каждый новый объект? Новый прототип на каждый новый КОНСТРУКТОР. facepalm.
> А вы предлагаете использовать один конструктор и один прототип? Чем объекты будут отличаться тогда?
Тем, что не возникает путаницы
a instanceof A // => true
a instanceof B // => false
Тем, что конструктор лежит в прототипе - нет необходимости тратить лишние ресурсы на добавление свойства при каждом вызове.
> Мой же вариант не должен создавать таких проблем
Зная внутрянку движков - при добавлении нового свойства инстансу все равно создается новый внутренний класс, сводя на нет отсутствие лишнего объекта-прототипа в вашем способе, см. доки по оптимизации производительности в v8, например.
Очень интересно, и какие это книжки подобному говнокоду учат? :) Пруф, где рекомендуется на практике использовать различные конструкторы с одним прототипом. Серьезные проекты, где подобное используется.
Это как раз то, от чего автор и пытается избавиться. Сэкономите несколько байт, получив спагетти на выходе. Необходимость весить метку в конструкторе сводит и это преимущество на нет.
@Anonym полнейший говнокод это
this.constructor = object.exceptions.IncorrectLink;
зачем писать свойство в конструкторе, когда его можно записать в прототип? :) Защищать разные конструкторы с одним прототипом может только совсем недалекий человек. Чего только не сделаешь, дабы наследования избежать...
@Anonym лолшто? :D Использовать один прототип для разных сущностей - очень, очень правильное решение, цепочка прототипов должна быть одна для всего в системе, на 2 (или сколько в проекте разных видов исключений?) лишних объекта с 1 свойством в каждом памяти никакого суперкомпьютера не хватит.