>>16434
В js есть только объекты. Больше ничего.
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).

Так. Короче только объекты.
Все объекты делятся на callable и non-callable. Callable это функции, в понимании большинства. Но по факту это все те же объекты, со всеми свойствами что и у других.

Все объекты могут принимать всего несколько типов сообщений - get, set и call. При чем call может принимать только callable объект. при попытке послать call сообщение не-callable объекту будет исключение.

Сообщение get содержит один параметр, сообщение set два. Сообщение call параметром содержит кортеж аргументов, а так контекст this.

Если в объекте (а так же в цепочке прототипов) не назначены слушатели для get и set с определенными параметрами, ищутся слоты с такими именами в объекте и по цепочке. Если находится возвращается то, что в них лежит. Если в них лежит callable объект и ему посылают сообщние call сразу как получили его из слота, то у него будет перегружен контекст (this) на объект из чьего слота его получили. Если только этот объект не был сконструирован стрелочным синтаксисом, иначе контекст перегрузить нельзя. Если после получение callable объекта из слота его сразу не вызвать, а например положить ссылку на него в переменную, то контекст будет сброшен на тот, который был установлен у него в момент его создания (и это не обязательно будет тот же объект из чьего слота его получили).

У callable объектов есть scope (область видимости) и контекст (this) в момент посылки им сообщения call (вызова). scope средствами языка перегрузить нельзя, но некоторые окружения позволяют (например в ноде есть модеуль vm), this перегружается у callable объектов сконструированных не-стрелочным синтаксисом

Классов нет. Есть конструкторы. Любой конструктор принимает новый созданный объект, которому выставлен определенный прототип (другой объект). Оператор instanceof (someObject instanceof SomeClassName) проверяет лишь есть ли в цепочке прототипов у someObject объект который лежит у SomeClassConstructor в слоте с именем prototype. На сам конструктор ему поебать. Чтобы сменить класс, достаточно сменить цепочку прототипов. Даже если объект был сконструированным определенным конструктором.

Так же у объектов есть параметр ограничения доступа, контролирующие его расширяемость или изменяемость (sealed, extensible, frozen). У слотов объекта есть параметры configurable, enumerable, writable. Параметры слотов объекта не влияют на объекты, что в них лежат. Они лишь контролируют доступ к самим слотам.

Все. Никаких классов. Никаких интерфейсов. Как отдельных сущностей. По факту все есть объект и все строит из них.
наследование реализуется выстраиванием цепочки прототипов. Инкапсуляция только на уровне scope'в (читай замыканий).
В остальном все меняется и все динамично, если только специально все не зафризить в момент конструирования. Но обычно этим никто не заморачивается по причине оверхеда и бессмысленности. Разве только фанатики по иммутабельности, н это все из разряда те, кому надо чтобы им по рукам бил компилятор\рантайм\дядя петя. Все "привычные" понятия тянуться в язык для еще более простого вкатывания тех, кто приходит из других языков. Так уж сложилось, что есть куча литературы по привычному, статически классовому ООП, но очень мало по мессадж-пассинг\прототайп-базед\мета-программинг. Все эти притянутые понятия выливают в синтаксический сахар, который не делает ничего полезного, а даже наоборот, еще больше вносит путаницы и от того непонимамания многих вещей в языке. При этом часто этот синтаксический сахар дэже урезан и вспомнинают об этом лишь после (как например проебались с полями в конструкции class и тянут ее теперь только в proposol'ах будущих версий).

JS истинно объектный язык. В современный язык притащили много вкусных вещей для метапрограммирования. Нову примитивную сущность Symbol, и Proxy-объекты. С помощью которых можно еще больше и сильнее перегружать и менять поведение в динамике.

Другое дело, что почти никто не умеет этим пользоваться и не понимает, что такое объектное программирование на самом деле.
Им нужно не объектное, а статически типизированное. А какие именно структуры будут скрываться за этими типами, не собо важно. Важно что это просто структуры и функции, строго привязанные к ним, или иногда менее строго. То, что в Java\C++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.

>>17346

>на каком этапе?

На этапе доступа к свойствам и методам примитива. Нет, не все передается по ссылке, точнее не так. Тут не уместно рассмтаривать понятия по ссылке и не по ссылке. Если сказать, что примитив епередается по значению - это будет не совсем правдой, потому что под капотом примитив (если это не какое-нибудь маленькое число) - это сложная структура данных, которая так же переадется по ссылке, но для программиста (пользователя) эти нюнансы в принципе не особо нужны. Достаточно понять что изменяемое,а что нет. Примитивы - immutable, любая операция над ним, возвращает новый примитив. И даже если инициализировать объект на основе такого примитива (который как раз будет передаваться по ссылке и являться полноценным объектом, но с неизменяемыми поялми), то все что ты сможешь с ним сделать, это добавлять новыйе свойства, но внутренее представление - тот самый примитив, ты изменить непосредственно в объекте не сможешь. Под капотом как раз есть те самые примитивные типы. 'string' - это примитив. new String('string') - это объект, внутри которого будет лежать примитив. Свойства и методы у них одинаковые, потому что в момент доступа с методу примитива он боксится в свой класс. То есть когда ты делаешь 'string'.length - под капотом происходит new String('string').length

В общем случае для пользователя (программиста) разницы между примитивным типом, и каким-нибудь кастомным синглтоном не будет. Поэтому проще воспринимать примитивные типы как снглтон объекты, чтобы не ебать себе мозги.

>приведи пример non-callable объекта

У всех объектов под капотом есть множество скрытых слотов. Такие как [Prototype], [Scope] (у callable обеъектов), [Call] и т.д. Часть из них ты можешь увидеть в дебаггере, но непосредственного доступа у программиста к ним нет. Callable объекты это те, у которых слот Call не null. По умолчанию он null у всех, кроме function. При этом у констуркторов классов es6, которые тоже в сущности function - [Call] так же отстутсвует.
Так что любой объект non-callble, что тут приводить пример. x = {a:2} , объект x in non-callable

>сущность Symbol

В целом для хранения разной метаинформации в объектах. Все символы уникальны. То есть Symbol() !== Symbol() В отличии от тех же строк или чисел. Есть возможность получать неуникальные символы, само собой. При этом символы являются примитивами, и могут быть ключами объекта. То есть, там где раньше писали x = {__siperprivateslot: 10} с символами можно делать private = Symbol() x = { [private]: 10 } И таким образом избегать конфликтов.

В то же время поля с ключами в виде символов стали использоваться для проброса внутренностей движков наружу, чтобы появилась возможность перегруки. Есть известные символы Symbol.hasInstance, Symbol.iterator, Symbol.toPrimitive и так далее, с помощью которых можно перегружать определенные поведения операторов. Например перегрузить тот самые операторо instanceof или изменить логугку приведения объекта к примитиву, и так далее.

---