Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Знаете ли вы JavaScript?

Предлагаю без проверок на живом коде ответить на вопрос:
какие значения будут у x.nnn и x.age в конце выполнения следующего кода:

var person = {firstName:"John", age:50}

var x = person;
var y = Object(person);
var z = new Object(person);

y.age = 10;
z.nnn = "new";

А потом высказать свое отношение к результату :)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

меня больше интересует вопрос зачем такую херню писать

Хотя ответ и угадал, всегда поражал тупизм задач типа «что получится» в результате некорректно или неявно написанного кода.

Мат.часть:
1) Преобразование типов. В данном случае Object->Object. Каждый, кто программировал сколь-либо боевой (не учебный) код знает, что преобразование типов — крайне нежелательная операция, потому что вы реально не знаете что творит компилятор или интерпретатор с конкретными типами. Единственные случаи, когда этим пользуются — это объяснить компилятору что вы знаете что творите, преобразовывая родственные типы, и не надо давать ворнинга на компиляции. Если есть хоть малейшие сомнения — делается новый объект, и вручную кодится то что вы хотите сделать.
Нет ни единой выгоды в синтаксическом сахаре кроме самого сахара. Если вы пишете одну строчку, компилятор всё равно напишет десять если они необходимы. И если есть сомнения что он сотворит — напишите сами эти строки.

2) Создание одного Object конструктором из другого. Отстойнейшая чушь js, но вероятно как и много чего ещё более убогого — оставленная для совместимости. Вы не обязаны знать, как работает каждый метод каждого класса. Назовите хоть один случай, когда вы получили пользу вызывая new Object(Object), и какая в этом польза.

Как бы выглядел тот же код, написанный минимально грамотно:

var person = {firstName:"John", age:50};
var x = person;
var y = person;
var z = person;
y.age = 10;
z.nnn = "new";
Но так же никаких загадок, даже если такого кода тысячи строк. Прям жить неинтересно. Особенно если переменным даны имена чуть поосмысленней чем x или person.

я бы, скорее, не взял человека, правильно ответившего на такой вопрос. вдруг, он весь свой код в таком же духе пишет?

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

кто вам поверит, что вы его не проверяли в консоли?)

Люблю js. язык нате вам говна на лопата. Первый раз когда столкнулся с js реализацией даты времени думал что это баг. Потом полез в спецификацию, оказалось что нет, кто то так специально написал

а чем она вам не нравится? можно подробнее?

Отсутствие единого подхода. Я уже с год не писал на js, подзабыл. Но по моему дни в месяце отсчитываются с нуля, а месяцы в году с 1. И при этом всем можно с этими вещами чисто арифметические операции проделывать.

а месяцы в году с 1.

Как раз месяцы 0-11. Это наследие Unix «struct tm» и повторяется много где.

Здравствуйте.


var person = {firstName:"John“, age:50}
Создаётся новый объект, указатель на который кладётся в переменную “person”.

var x = person;
Указатель на созданный объект копируется из переменной “person” в переменную “x”.
Теперь две переменные: [person, x] указывают на созданный объект.

var y = Object(person);
Из ECMAScript 5.1 RFC:
15.2.1.1 Object ( [ value ] )
When the Object function is called with no arguments or with one argument value, the following steps are
taken:
1. If value is null, undefined or not supplied, create and return a new Object object exactly as if the standard
built-in Object constructor had been called with the same arguments (15.2.2.1).
2. Return ToObject(value).

Поскольку у нас value не null и не undfined, а объект (ссылка на объект) то смотрим в эту табличку:

9.9 ToObject
The abstract operation ToObject converts its argument to a value of type Object according to Table 14:
Table 14 — ToObject
<th>Argument Type</th><th>Result</th>

UndefinedThrow a TypeError exception.
......
ObjectThe result is the input argument (no conversion).

Т.е. var y = Object(person) сделает следующее — создастся переменная “y”. Вызовется функция Object ( [value] ). Поскольку value не null и не undefined, а объект (ссылка на объект) person (в JS объекты передаются по ссылке) эта же ссылка и вернётся (см. 9.9. Table 14 ToObject::Object). И запишется в переменную “y”.

Соотвтетственно в “y” имеем ссылку на вновь созданный объект.
Итак теперь ссылки созданный объект в переменных: [person, x, y]

И последнее


var z = new Object(person);
Смотрим во всё тоже ECMAScript 5.1 RFC:

15.2.2 The Object Constructor
When Object is called as part of a new expression, it is a constructor that may create an object.

15.2.2.1 new Object ( [ value ] )
When the Object constructor is called with no arguments or with one argument value, the following steps are
taken:
1. If value is supplied, then
a. If Type(value) is Object, then
i. If the value is a native ECMAScript object, do not create a new object but simply return
value.

...

Из 1.a.i следует что назад вернётся аргумент конструктора value, т.к. value — ссылка на всё тот же созданный объект. Соотвтественно в переменной “z” будет ссылка на всё тот же созданный объект.

Т.е. в итоге мы имеем 4 ссылки на созданный обхект в четырёх переменных: [person, x, y, z].


y.age = 10;
z.nnn = “new”;
Поскольку во всех переменных ссылки на один и тот же объект, то эти две строки меняют свойства созданного объекта.
Поэтому:
  • В созданном объекте будет изменено свойство age и его значене будет теперь равно 10
  • В созданном объекте будет добавленно свойство nnn и его значение будет равно строке “new”

Как то так.

самый понятный ответ :)
но логично ли в данном случае “If the value is a native ECMAScript object, do not create a new object but simply return
value.” ?
В том смысле, что зачем оно так сделано.

но логично ли в данном случае «If the value is a native ECMAScript object, do not create a new object but simply return
value.» ?

Думаю да.

Этот конструктор оборачиват значение простого типа [number, boolean, ... ] в объект.
Но что делать с объектом ? Не оборачивать же его ещё в один объект.
Тут как бы сама суть конструктора привести входящее значение к объекту и вернуть на него ссылку. Собственно это он и делает.

Плохая попытка начать холивар на тему чей член длиннее какой ЯП круче :-)

И да, в perl это настолько удобно, что написали стопицот OO systems, а в документации написано:

We strongly recommend that you use one of these systems... ...There’s really no good reason to write your classes from scratch in Perl.

Мда, похоже в этом топике вообще кучу тайн открыли=) и приведение типов, и передачу объектов по ссылке, а где то школьный материал за представление чисел с плавающей запятой вспомнили, про new и конструктора уже молчу... о а еще страшные event loopы , да promise... страшилки для джунов перед сном?=))

Это js, тут куча магии.

А потом высказать свое отношение к результату :)

мне пофиг, что там у тебя будет.

что будет если прибавить 0.1+0.2. почему так?

Вас беспокоит точность вычислений с плавающей запятой? Хотите об этом поговорить? :D
P.S. У меня получилось 0.30000000000000004

Я хочу поговорить об Ангуляре господе нашем.

0.30000000000000004
особенности вычислений с плавающей точкой

а вы всегда массивы складываете, да?

ну не знаю, тут все про знания говорят я вот и показую, что увидел. узнал.

лучше бы разобрались с промисами

Или eventloop:

function printing() {
console.log(1);
setTimeout(function() { console.log(2); }, 1000);
setTimeout(function() { console.log(3); }, 0);
console.log(4); return 5;
}

printing();

я понимаю, что влез в беседу людей, понимающих друг-друга с полуслова. но мне стало интересно, как это собирается до кучи:
— а [1] + [2]
— а вы всегда массивы складываете, да?
— ну не знаю, тут все про знания говорят я вот и показую, что увидел. узнал.
— лучше бы разобрались с промисами
— Или eventloop: [...и дальше код]

к чему оно вообще было? setTimeout так же странно выглядит, как сложение массивов? должно помочь разобраться с промисами человеку? что?

Мы о том, что лучше спросить на собеседовании / выучить промисы или ивентлуп, чем про то чему будет равно малополезное выражение в роде [1]+[2] или того что в топике

видео классное, правда, ничего для себя внезапного не открыл :( это намек на что-то?
PS а докладчик визуализацию классную сделал.

Ви спитали

эм. что это?
Чи я не так зрозумів?

Єдиний варіант, коли доцільно проводити такі співбесіди, це коли проходиш спібесіду на architecture engineer з зарплатою від $5000 або у всякі гуглофейсбуки, де від того, які лапки ти поставив, залежить наскільки швидко завалиться твій сервер (образно, звичайно)
Все решта — від лукавого.

Ваша правда, якраз таким часто і бавляться. Жодного разу не чув такого на інтерв’є з замовниками з-за кордону, зате у нас такі круті програмісти, що навіть трейні знають деталі реалізації створення нових об’єктів.
Я взагалі в Україні не бачив різниці на співбесідах між junior & senior — питають до того часу, поки не набереш критичну масу мінусів.

Интервьюер должен спрашивать кандидата такие вопросы, ответы на которые будут ему говорить подходит ли человек по техническим скилам на конкретную вакансию на конкретный проект или нет. Ответы на вопросы «что будет после [1]-[0]», «что будет если написать +++i++» и т.д. не дают интервьюеру никакой полезной информации с которой можно было бы сделать вывод о соответствии кандидата требованиям вакансии. Соответственно, получается что не важно что ответит кандидат на такой вопрос.

А если задают такие вопросы, то интервьюер либо неопытный, либо решил повыпендриваться перед незнакомым человеком, который обязан его выслушать, в отличии от коллег или начальства.

Мало того, если вдруг кандидат отвечает правильно на такой вопрос, то это либо вызывает у интервьюера мысль «ты че, самый умный тут, да?», либо интервьюер внезапно осознает что знать такое могут только какие-то странные чокнутые программисты brainfuck, и нам тут такие работники не нужны. А если кандидат задаст вопрос «и часто у вас такое в коде вашего проекта?», то интервьюер осознает что его тут тролят, и решит «кандидат слишком борзый, такие в нашей команде не нужны».

В любом случае услышав подобные вопросы знайте что перед вами не профессиональный интервьюер. Если вакансия вас не особо инетерсует, уходите, а если интересует, то играйте в игру типа «вау, я и не знал такого, прикольно, вы тут все такие умные вещи знаете».

Тут все-таки від задач має залежати, не від зарплатні. Якщо треба наприклад розробляти фреймворк або якусь складну бібліотеку (графіка, складні обчислення) — такі питання доцільні. Якщо треба використовувати фреймворки та бібліотеки (створювати додатки) — ні.

Я про web. Той, що «рест, ангуляри і сімфоні-ларавели».

це коли проходиш спібесіду на architecture engineer
Этому лучше задать вопросы, которые дадут понять, как он будет принимать архитектурные решения. Например, если он допустит ошибку связанную с подобной задачей — это скорее всего будет просто исправить, чем решение на более высоком уровне, когда уже для исправления надо переписать все.
Єдиний варіант, коли доцільно проводити такі співбесіди, це коли проходиш спібесіду на architecture engineer з зарплатою від $5000 або у всякі гуглофейсбуки
В гуглофейсбуках вообще не задают вопросов, касающихся какого-то языка программирования, фреймворка или технологии, тем более на позиции архитекторов, тем более вопросв уровня «если ударить в глаз, на какой ноге шнурки развяжутся»

Ну и где тут заковыристый вопрос на тему «что будет если в языке X от объекта отнять массив»?

какие значения будут у x.nnn и x.age в конце выполнения
Без понятия
А потом высказать свое отношение к результату
Я пожалуй выскажу отношение к коду
var y = Object(person);
var z = new Object(person);
Что это и зачем это здесь нужно?

ок. А если так:
var z = new constructor(person).

Такое может быть нужно в принципе?

В контексте остального кода это даже больший бред, так как функция constructor не определена. Но если её написать и она что-то будет делать с переданным аргументом, то это будет иметь смысл.

Ну тут ответ очевиден. Объекты передаются по ссылке.

Проблема не в ссылках и не в прототипах. Проблема в особом случае:

The Object constructor creates an object wrapper for the given value. If the value is null or undefined, it will create and return an empty object, otherwise, it will return an object of a Type that corresponds to the given value. If the value is an object already, it will return the value.

new обычно создаёт новый объект. И в других языках, и в js. Кроме ситуации Object(v) где v уже объект, в которой новый объект внезапно не создаётся, даже если явно указано new.

Или с другой стороны, код выглядит как вызов конструктора. Что может делать конструктор с аргументом-ссылкой? Использовать и отпустить, или оставить в объекте (контейнер).
В js есть третий вариант: вернуть эту самую ссылку в качестве «созданного» объекта. WAT.

Это из той же серии, что и {} + [], «2» + 2, «2» — 2 и таблички равенства.
Полиморфная операция делает нечто неожиданное для некоторых типов аргументов.

new обычно создаёт новый объект. И в других языках, и в js. Кроме ситуации Object(v) где v уже объект, в которой новый объект внезапно не создаётся, даже если явно указано new.
это не проблема и не неожиданность. если конструктор возвращает значение, оно и будет возвращено как результат инициализации(кроме кейса, когда вернули примитив). То есть
function Test(x) {
 if (x instanceof Text) return x;
 this.a = x;
}
var a, b;
a = new Test(2);
console.log(a);
b = new Test(a);
console.log(a === b);
для самописного такое не проблема. почему это проблема для предопределенного конструктора?

Как это работает в js — понятно. Мысль о другом была.

Почему это вызывает удивление? Кто-то говорит про ссылки, кто-то про про прототипы и наследование.
Моё мнение — нет, это всего лишь из-за определения операции new и этого конкретного конструктора.

Скажем если бы new была определена вот так:

function new(class, ...) { this = { __proto__: class.prototype }; class(...); return this }
то вопроса бы не было. Без изменений в механизме наследования и ссылок.
new обычно создаёт новый объект. И в других языках, и в js. Кроме ситуации Object(v) где v уже объект, в которой новый объект внезапно не создаётся, даже если явно указано new.
new создает новый объект и в JS.
можете убедиться:
function test() {
 this.b = 42;
 console.log(this);
 return {a: 13};
}
console.warn(new test());
new ответственно подошел к вопросу, создал объект, закинул __proto__ и передал в функцию для инициализации. А функция взяла, и вернула другой объект :( но мы можем не расстраиваться и просто использовать это дальше.
а насчет Object как инициализатора — он много на себя берет. например, оборачивание примитивов. думаю, это одна из причин, почему для объекта в качестве аргумента ничего не происходит и он сразу ж возвращается обратно.
А то, что вы описали как «альтернативный вариант new», так и есть. кроме того, что не class.call(this); return this; а
var result = class.call(this);
if (result instanceof Object) return result;
else return this;
то есть логика та же, но чуть усложнена.
PS я согласен, что можем запутывать. но не думаю, что стоит отказываться от гибкости Object() ради сомнительного(кто используется явно эту функцию вместо литерала?) однообразия?
new создает новый объект и в JS.

Внешний эффект имелся в виду. Т.е. что a = new A(...) всегда будет новым объектом.
Почему собственно и название «new».

Любой вариант с var result = class.call(...); return result полагается на хорошее поведение класса, new при этом ничего не гарантирует. Но мой вариант тоже плохой. Надо выкидывать this из конструктора вообще.

а насчет Object как инициализатора — он много на себя берет. например, оборачивание примитивов.

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

a = objectify(v); // v если v объект, иначе обёртка для v
b = new Object(o); // эквивалентно b = Object.create(Object.prototype, objectify(o))
Но мой вариант тоже плохой. Надо выкидывать this из конструктора вообще.
а как такой вариант: вообще игнорить аргумент Object()
что бы ни передали, вернется пустой свеженький объект.
PS а можно просто забить на это. не встречал код, где использовался бы new Object() вместо литерала + чтоб это создавало проблемы + чтоб там не было других, куда более серьезных и трудноразруливаемых проблем :)

было бы неплохо, если бы падал по синтаксису из-за отсутствия точки с запятой в первой строке.
JavaScript построен на прототипах. так что поведение в данном случае ожидаемое.

Конструктор Object создаёт объект-обёртку для переданного значения. Если значением является null или undefined, создаёт и возвращает пустой объект, в противном случае возвращает объект такого типа, который соответствует переданному значению. Если значение уже является объектом, конструктор вернёт это значение.

При вызове в не-конструкторном контексте, Object ведёт себя идентично коду new Object()

developer.mozilla.org/...nce/Global_Objects/Object

«Оператор new создает экземпляр объекта, встроенного или определенного пользователем, имеющего конструктор.»
developer.mozilla.org/...t/Reference/Operators/new
Object() - это конструктор?

Object(person) - вызов в не-конструкторном контексте, поэтому ведёт себя идентично коду new Object(person)

Если значение уже является объектом, конструктор вернёт это значение
person — объект, поэтому Object(person) == new Object(person) == person

это понятно. Непонятно ПОЧЕМУ ТАК? Когда логичнее было бы считать Object() стандартной функцией-конструктором.
Ответ «потому что» не устраивает :)

стандартной функцией-конструктором
любая функция может выступать в качестве конструктора(new ...) или не выступать(тогда любые операции над this будут затрагивать текущий контекст)
что значит «считать функцией-конструктором» не понятно.
это всего лишь инициализатор.
нет значительной разницы(кроме установки prototype) между
new SpecialFunction()
и
SpecialFunction.call({})

ну, я не придираюсь к словам. это просто ключевое.
если оценивать «конструктор» как роль, с задачей проинициализировать текущий this — много вопросов даже не возникнут.
если разделять функции на «просто функции» и функции-конструкторы, которые, как будто, что-то аллоцировать должны, то будут непонятки.

если разделять функции на «просто функции» и функции-конструкторы, которые, как будто, что-то аллоцировать должны, то будут непонятки
Почему? Да, для JS есть только функции. В то же время, если программист пишет функцию для использования с new, есть большая вероятность что данную функцию не будет смысла просто вызывать. Почему бы не называть такую функцию конструктором, для удобства?

я бы, скорее, не взял человека, правильно ответившего на такой вопрос. вдруг, он весь свой код в таком же духе пишет?

Оце точно. На співбесіді дали подібну задачу, тільки не по JS.
Питаю: «А хто в своєму розумі таке напише? Якщо у вас такий код, то я не хочу у вас працювати». Мабуть, тому і не взяли, хоча на всі питання відповів))

я думаю, это скорее проверка на вшивость — хочешь ли ты разбирать чужой г0внокод или нет))

Подобный код может вполне оказаться невольным последствием комбинации нескольких переписок и рефакторингов. После этого вся проблема в том, чи будут давать ресурсы на приведение «этого» в порядок.

код — да.
подход — нет.
как только костыль переходит из категории «меньшее зло» в «а почему бы и нет?» наступает жопа.
мы ж про собес говорим, а не легаси код, да?
if (some == false) тоже может возникнуть и укорениться. но если такое обсуждать на собесах, то и в коде оно будет появляться чаще.

Угадал, приятно (js учу с перерывами месяца три).
А вообще к тестам типа «что получится, если написать не как нормальные люди, а задней левой ногой» у меня ненависть страшная еще с момента заваленного теста по джаве в Nix Solutions, который состоял из подобных вопросов как минимум наполовину.

вот вам листинг функции на 30 строк. где здесь ошибка? :D

Людям свойственно ошибаться. Но как говорил Конфуций «Ошибка лишь та, что не исправлена». И необходимо проверять у кандидатов способность находить и фиксить эти ошибки.

В командах работают обычно много людей. И нужна проверка на способность читать и понимать чужой код.

И нужна проверка на способность читать и понимать чужой код.
Угу, код, а не говнокод. Если контора предоставляет реальный код проекта для «разбора» — это таки круто (я такого, правда, ни разу не встречал). Но тут другой момент: если этот код состоит более чем полностью из «своеобразных конструкций» (по типу тех которые описаны в этом топике), то лучше этот проект обходить стороной.

я ответил на коммент, а не на пост

я ответил на коммент, а не на пост
Спасибо за уточнение, Кеп. Но сути это не меняет.

Меняет. Это уже другой контекст. Если вы понимаете, о чём я ;-)

Ответ очевиден. Отношение к результату равнодушное — результат такой, какой должен быть. Отношение к коду — рефакторить.

Хотя ответ и угадал, всегда поражал тупизм задач типа «что получится» в результате некорректно или неявно написанного кода.

Мат.часть:
1) Преобразование типов. В данном случае Object->Object. Каждый, кто программировал сколь-либо боевой (не учебный) код знает, что преобразование типов — крайне нежелательная операция, потому что вы реально не знаете что творит компилятор или интерпретатор с конкретными типами. Единственные случаи, когда этим пользуются — это объяснить компилятору что вы знаете что творите, преобразовывая родственные типы, и не надо давать ворнинга на компиляции. Если есть хоть малейшие сомнения — делается новый объект, и вручную кодится то что вы хотите сделать.
Нет ни единой выгоды в синтаксическом сахаре кроме самого сахара. Если вы пишете одну строчку, компилятор всё равно напишет десять если они необходимы. И если есть сомнения что он сотворит — напишите сами эти строки.

2) Создание одного Object конструктором из другого. Отстойнейшая чушь js, но вероятно как и много чего ещё более убогого — оставленная для совместимости. Вы не обязаны знать, как работает каждый метод каждого класса. Назовите хоть один случай, когда вы получили пользу вызывая new Object(Object), и какая в этом польза.

Как бы выглядел тот же код, написанный минимально грамотно:

var person = {firstName:"John", age:50};
var x = person;
var y = person;
var z = person;
y.age = 10;
z.nnn = "new";
Но так же никаких загадок, даже если такого кода тысячи строк. Прям жить неинтересно. Особенно если переменным даны имена чуть поосмысленней чем x или person.

тупизм задач показывает полноту понимания предмета. Конечно, такого кода реально писать никто не должен, но зато быстро можно проверить, знает ли человек, как работает «new».

Найцікавіше те, що 95% людей, які задають такі питання, валяться на аналогічних інших питаннях, які до цього не встигли побачити в очі.

быстро можно проверить, знает ли человек, как работает «new»
Зачем мне знать как он работает в анатомических подробностях? Просто так? Для работы более чем достаточно того, что оператор new берёт конструктор и создаёт объект. А задача «а что будет, если написать new не перед конструктором» по своей практической ценности равноценна задаче «а что будет, если бросить лом в унитаз в поезде».

С огласен с тем, что

Для работы более чем достаточно...
а что будет, если написать new не перед конструктором
Но где вы тут не увидели конструктора?
new Object
вполне себе является конструктором, у Object-a он есть:
Object.constructor
new Object
вполне себе является конструктором
Конструктором чего? Вот это конструктор:
function Point(x, y) { this.x = x; this.y = y; }
А Object хоть и является конструктором технически, но лично мне непонятно что с его помощью можно создать, и new Object поэтому кажется мне бессмыслицей.
function Point(x, y) { this.x = x; this.y = y; }
Это всего лишь функция. А конструктором она может стать только лишь в том случая, когда она используется вместе с new. Иными словами вызов функции является вызовом конструктора тогда и только тогда, когда он происходит «вместе» с оператором new.

Простой пример:
function a() { console.log('do nothing') } // это ни разу не конструктор, как и Object
потому что
a(); //возвратит undefined, потому что это функция
new a(); //а тут у нас произойдет вызов конструктора, который возвратит объект
точно так же как и ниже:
new Object(); // это конструктор объекта

Потом в итоге начитаются люди про такие «конструкторы» как у вас, приходят на собеседования в роли синьйоров, рассказывают что они знают ООП в JS, что в JS (стандарта ES5) есть классы, единороги и т.п.

Вы немного не поняли о чём я. Я о том, что в приведённом мною примере понятно, что именно создастся. В случае с Object совершенно непонятно, что создастся, и зачем его вызывать, хоть с new, хоть просто так. А в любом коде должен быть какой-то смысл и предполагаемый результат. Иначе зачем такой код писать, если не знаешь, что получится.

function a() { console.log(’do nothing’) } // это ни разу не конструктор, как и Object
потому что
a(); //возвратит undefined, потому что это функция
new a(); //а тут у нас произойдет вызов конструктора, который возвратит объект
Какой объект? Технически произойдёт вызов конструктора, но смысла такой код не имеет, как и
new Object();
начитаются люди про такие «конструкторы» как у вас, приходят на собеседования в роли синьйоров, рассказывают что они знают ООП в JS, что в JS (стандарта ES5) есть классы, единороги и т.п.
И? Они программировать умеют? Придумывать архитектуру? Или вы считаете важными только академические знания?
Приведу в качестве примера перфоратор: не нужно знать как он устроен, чтобы уметь хорошо сверлить. В то же время знание его конструкции лучше сверлить не поможет.

Да, в приведённом вами примере создастся функция с названием Point и не более того. Ниаких конструкторов, объектов и т.п. в вашем примере и близко нет.

А в любом коде должен быть какой-то смысл и предполагаемый результат. Иначе зачем такой код писать, если не знаешь, что получится.
Именно про «что получится» я у вас и спрашивал, но, как видно вы это слабо представляете, либо хорошо притворяетесь, что не понимаете. (Про примеры, приведённые в статье, я писал выше).
И? Они программировать умеют? Придумывать архитектуру? Или вы считаете важными только академические знания?
Как правило такие люди могут написать какой-то код, он даже будет работать, но только до того момента, пока этот код работает в сферическом вакууме. А при появлении серьёзных задач и нагрузок этот код надо переписывать. Про архитектуры я молчу. А что делает код (пусть будет без параметров) new Object() это не академические знания, а необходимый уровень понимания, как и то, что действительно называется конструктором, иначе вы будете говорить на разных языках с другими.
new Object() это не академические знания, а необходимый уровень понимания
Ну расскажите, где может использоваться такая конструкция и зачем, если это необходимо знать. Я сгораю от любопытства.
Вы сейчас написали кучу просто книжной теории, а я вам о практике толкую.

Это не книжная теория, это просто правильные названия вещей. Если вы будете называть кувалду плоскогубцами, то прося плоскогубцы вам всегда будут давать кувалду.

А new Object очень часто встречается у синьйоров, которые пришли из джавы в мир жс-а. Такое так же встречается у обычных жсников, но редко. Так же может встречаться в проектах, куда дописывали костыли (например если к какой-то определённой строке (а не к String) зачем-то понадобилось добавить свойство).

это просто правильные названия вещей
Я бы поспорил. Если называть что-то конструктором, то функцию, которая при вызове с оператором new вернёт какой-то полезный объект, а не говорить, что с new конструктор любая функция, а без new никакая функция не конструктор. Так,
function a() { console.log(’do nothing’) } // это ни разу не конструктор, как и Object
потому что
a(); //возвратит undefined, потому что это функция
new a(); //а тут у нас произойдет вызов конструктора, который возвратит объект
вернёт объект, содержащий что? Ничего, потому что функция a ничего не делает чтобы результирующий объект что-то содержал. Так какой тут конструктор? Есть функция и какой-то странный программист, который решил, что зачем-то нужно вызвать оператор new с этой функцией.
А new Object очень часто встречается у синьйоров, которые пришли из джавы в мир жс-а
Java <> Java Script. Это проблемы тех синьоров, которые хотят видеть в новом языке знакомый синтаксис. И это они должны переучиваться писать нормальный код, понятный другим. Например когда вы приезжаете в другую страну, от вас ожидают знания распространённого в той стране языка или английского. Тут точно такой же принцип. Мало ли кто откуда пришёл. Хочешь писать на JS — пиши на JS. Не знаешь как писать правильно — спроси, а не ожидай от JS поведения Java и такого же синтаксиса.
вернёт объект, содержащий что? Ничего, потому что функция a ничего не делает чтобы результирующий объект что-то содержал.
Как всё запущено. Во-первых она вернёт объект. Во-вторых он далеко не пустой, в нём просто нет «enumerable» свойств.
Так какой тут конструктор?
Обыкновенный конструктор «пустого» объекта.
Есть функция и какой-то странный программист, который решил, что зачем-то нужно вызвать оператор new с этой функцией.
Хочешь писать на JS — пиши на JS.
Кстати говоря new Object() - вполне валидный и правильный код. По ссылке, даже документация есть для особо неверующих developer.mozilla.org/...nce/Global_Objects/Object

А по сути всё это показывает лишь одно, что вы лентяй, оправдывающий свою лень тем, что «Я практик, а не теоретик». И в итоге, пусть даже в этом примере вы и правы, на счёт целесообразности использования new Obejct(), но в другой ситуации вы скорее всего поступите так же. Не разбираясь в сути, что как и почему происходит. А такой подход неизбежно приведёт к говнокоду, который кому-то за вами придется убирать.

Во-вторых он далеко не пустой, в нём просто нет «enumerable» свойств.
Бла-бла-бла. Теоретизируйте дальше без меня.

нет такой сущности как «конструктор».
функция выступает в роли конструктора(инициализатора) будучи вызвана с помощью new, да.

В моём первом комментарии это и было написано.

О, а как сделать такой трюк как у new Object — ну, чтобы конструктор при вызове через new проксанул RHS ссыль или что-то кастомное отдать в assignment?

о_О Можна створити новий об’єкт, як і з {}. Якщо вам

непонятно
це не значить, що це є
бессмыслицей
Читайте доку es5.javascript.ru/x15.2.html#x15.2

Ой, классно, пустой объект. Зачем, я спрашиваю? Что вы с ним будете делать? Это и есть бессмыслица во всей красе.

var o = {};
if (...) {
  o.a = 1;
} else {
  o.b = 2;
  callSomeFunction(o);
  ...
}
var myCacheObject = {};
...
makeAjaxCall('url', function callback(result){
  myCacheObject['url'] = result;
})

Или зайдите и посмотрите в исходники, например, того же гуглоаналитикса, или в ту же jquery.js, которую вы с гордостью указали в профиле и резюме. О ужас, там есть пустые объекты! Там создают пустые массивы! Кошмар!
Даже в столь горячо любимом вами ember.js бессмыслица:

if (typeof Ember === 'undefined') { Ember = {}; };
Кругом ЗРАДА!

Вот так и получается, что в своем резюме вы пишите бессмыслицу «во всей красе».

Бла-бла-бла

Ой всё!

Бла-бла-бла
После вашик комментариев в данной теме именно эти слова как нельзя подходят для описания ваших скиллов программирования :).

Это описание ваших скилов балабольства. Вы прекрасно поняли о чём я написал, но решили позанудствовать на пустом месте. Сочувствую вашим сотрудникам.
А программирование от ваших разговоров так же далеко, как Киев от Пекина.

Я понял, что вы утверждаете, что создание пустых объектов:

var a = {};
я вляется «бессмыслицей». Просили примеров «Что вы с ним будете делать?». Я вам их привёл, на что вы, как обычно ответили в стиле «Ой всё».

var a = {}; - создание пустого объекта, который потом можно наполнить. Имеет смысл в случае, когда структура используется один раз (например, данные для отправки аяксом на сервер). Это нужно и это нормально.
var a = new Object(); - бессмыслица. Больше кода, хуже читаемость, при одинаковом результате.
Вы же утверждаете, что это очень-очень важная конструкция. Которая почему-то нормальными людьми как раз и не используется.

Object.constructor
ну, да. Function. потому что Object — это функция. как это связано с объектами, которые будут создаваться через new Object?

Правильно, но автор комментария пишет:

new берёт конструктор и создаёт объект
На самом деле new ничего не берет и никуда не ложит. А касательно вызова конструктора «new Object», автор комментария пишет:
А задача «а что будет, если написать new не перед конструктором» по своей практической ценности равноценна задаче «а что будет, если бросить лом в унитаз в поезде».
не ложит
кладёт

в данном контексте именно ложит.

На самом деле new ничего не берет и никуда не ложит.
да, не понял вас. тут поддерживаю.

И это печально

Не поверишь, но конструктор не обязательно создаёт объект. Он возвращает объект. И не факт что объект, может вернуть чёрта с рогами.

PS. Если боросить лом — будет гнутый лом, оторванная канализация и ещё много чего по ходу вагона. Что будет гарантированно — так это увольнение. Потому что те кто хочет попробовать — обязательно похвастаются. Были прецеденты.

Кстати, в программировании попробовать — зачастую самый быстрый метод. Особенно со скриптами, который можно тупо набрать в консоли.

Не поверишь, но конструктор не обязательно создаёт объект. Он возвращает объект. И не факт что объект, может вернуть чёрта с рогами.
конструктор — инициализатор свойств. и всё. он не создает объект, а получает его на входе в виде this.
олсо, если конструктор вернет «черта с рогами», то вернется то, что было this в тот момент. если функция вернет объект — это и будет результатом. даже если это не тот this, который мы только что инициализировали.

New — это вызов конструктора. А вот чего творится в конкретном конструкторе — знает лишь мудрец лохматый.

меня больше интересует вопрос зачем такую херню писать

Человек выяснил что объекты в джс это на самом деле не объекты, а ссылки на объекты :)
И поделился своим новым знанием с миром в такой оригинальной форме.
Можем порадоваться за него, в следующий раз на собеседовании если спросят про отличия между примитивами и объектными типами данных в джс он сможет козырнуть и получить плюс в карму (и, возможно, к зарплате). :D

Такую херню нередко дают на тестах при приёме на работу. Так всегда случается, когда пытаются сделать методы «для дурака». Вот дураки и пользуются.

обычно на собеседовании хватает трех вопросов — наследование в джс, замыкания, глобал ивент луп. но не всегда тот кто собеседует сам до конца в этом разбирается...

это если прошли дальше function declaration vs function expression ))))))

Я такую херню только на собеседованиях и вижу, в реальных проектах, слава Богу, не встречается

а что в реальных проектах не бывает такого типа объектов и операций над ними?

это делать-то «new Object(someObject)»?
а зачем? для получения доступа... к чему?

Ну, так иногда пишут люди, пришедшие из «языков, поддерживающих классы» :D

ну счас конечно все начнут ржать, но я видел на сайтах только небольшие вставки джаваскриптов, событие там на кнопку повесить или формы проверить, с жсона данные перетусовать для какого нибудь готового плагина типа D3 или ажакс позвать. даже в ангуляре мне не попадалось что бы вот так объекты по сслыкам туда сюда тусовать. и я типа думал что нормально знаю и джаваскрипт и jQuery, а тут опа и такие задачи.

В реальных проектах за такое сношают.

в «реальных проектах», некоторые даже минифициравонный код апдейтят.
но для этих целей есть код ревью

В реальных проектах нужно находить подходящие библиотеки/компоненты, допиливать их до нужного состояния и объединять между собой. Манипулировать типами нужно не часто. Плюс есть типовые решения для таких манипуляций. Например, копирование такого простого объекта как в примере (без методов) делается в одну строку: var copy = JSON.parse(JSON.stringify(original));

Однако недешёвые у вас «в одну строку». Остальной код точно так же не оптимизируется на скорость аж никак?

Аргументы с цифрами будут, или абстрактный срач?

А надо аргументировать что JSON.parse(JSON.stringify(original)) дорогостоящая операция?

Я выше комментировал более подробно по этому поводу. 24000 операций в секунду — более чем достаточно в большинстве случаев. Если вы собираетесь копировать объекты в цикле на 24000 итераций — тогда это дорогостоящая операция и нужно брать другое решение. Если вы собираетесь скопировать объект один раз по какому-нибудь событию — можно не обращать внимание на стоимость операции и писать как удобнее.

Ну впринципе соглашусь, если операция одиночная, то стоимостью операции можно пренебречь, и делать как удобно в написании. Но это не делает эту операцию менее дорогостоящей, она дорогая сама по себе.

Так же, как и все методы jquery и все клиентские фреймворки.

Наверное так и есть. Я просто мыслю серверной частью где каждая лишняя операция играет роль.

без методов
и, как завещал нам Потап с Настей: "бездаты"©

Не понял шутки

Кроме «без методов» упомянутый подход обладает дополнительными ограничениями, например, конвертация дат.

Обязательная ссылка в любом js треде: WAT.

Разница между Object и new Object наводила на правильные мысли, но результат всё равно неожиданный.

:) по ссылке, конечно, вещи веселые, но настолько же логичные, как и попытки сложить что они там складывают

Ваше отношение к этому вопросу изменится после первой ловли сложного бага, когда какие-то аргументы на 15-м слое взаимосвязи разных сторонних библиотек окажутся не того типа, как ожидается, или неожиданно не будут содержать того, что надо. Например, вы ждёте {x:1,y:2}, а приходит [{x:1,y:2}]. Или вместо 3.14 приходит «3.14». Или вы пытаетесь извлечь x.abc, в то время как x={ABC:14}.
Те, кто прошёл ад поиска таких багов, начинают ценить статическую типизацию, генерацию исключений на извлечение по несуществующему ключу, и множество других свойств языка, которые в JS и близких к нему или отсутствует, или реализованы через попу на другом континенте. (Именно из-за такого я предпочитаю Python для ниши «динамических» языков — в нём, хотя бы, все попытки нарушить типизацию систематически и жёстко пресекаются. В статических таких проблем меньше, хотя есть свои характерные грабли вроде двух делений.)

В одной знакомой компании для решения проблем с неадекватными типами данных на входе были следующие правила:
* если снаружи поступает число, писать не просто x, а +x (унарный плюс переводит строку в число)
* если снаружи поступает строка, писать не просто x, а ""+x (наоборот, форсируется, что это строка)

потому что иначе ни с какими фреймворками нет гарантии, что те не нарушают типы.

Почитайте тут, чего пишут люди, у которых JS — основной рабочий язык на все задачи, со всеми ссылками.

Те, кто прошёл ад поиска таких багов
че-то не представляю сложности. неприятно, да.
но тут и для статически типизируемых будет сюрприз, если вместо коллекции передавать null pointer(в нашем случае — вместо массива на вход получить null или undefined вероятнее, чем [{x: 1, y: 2}] вместо {x: 1, y: 2})
че-то не представляю сложности. неприятно, да.

Сложность — именно когда оно между слоями в чужом фреймворке (ну есть ещё вариантов с такими же проблемами). Там элементарно пропустить ляп логики.

но тут и для статически типизируемых будет сюрприз, если вместо коллекции передавать null pointer

Хм, уже тоже не всегда. В некоторых уже можно делать, например, тип X* как обязательно указывающий на что-то, а Nullable<X*> как возможно являющийся NULL. Конверсия из второго в первый содержит динамическую (если не определяется статически) проверку с генерацией исключения, если указатель оказался равным NULL. Уже есть из коробки для C# и (AFAIK) Haskell, ожидается появление в других.

окажутся не того типа
Почему окажутся? Сами по себе? Или потому что кто-то забыл, что пишет на языке со слабой динамической типизацией и иногда нужно типы проверять/преобразовывать?

Второе. Только не «забыл», а не стал делать проверку типа на входе и выходе каждой функции и каждого сколь-нибудь связного куска кода, потому что 1) задолбался, 2) это всё будет тормозить раз в сто.

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

, чужая сомнительная библиотека (в общем случае — все чужие библиотеки, кроме входящих в сам язык, и многие свои).

К чужой библиотеке есть доки. Также, следует взять за правило, что если метод по документации принимает число и иных вариантов не указано — нужно озаботиться передачей туда числа.

Ну вот потому они на границах интерфейсов и пишут так — не foo(a, b), а foo(+a, ""+b). И чужим не доверяют полностью, и себе.

К чужой библиотеке есть доки.
К 90% библиотекам ноды вся дока состоит из readme файла с именем автора

Если доков нет, их нужно придумать

Те, кто прошёл ад поиска таких багов, начинают ценить статическую типизацию, генерацию исключений на извлечение по несуществующему ключу, и множество других свойств языка, которые в JS и близких к нему или отсутствует, или реализованы через попу на другом континенте.
Самое эпичный баг, который я видел — в одной библиотеке накосячили

if (buffer.length = 10) {}

что в некоторых случаях изменяло размер буфера в сторону увеличения что выливалось в доставляющие исключения рантайма

залип почти на день, чувства были как у чувака, который по отдельности мерял секции забора, получилось 6 метров, а если вместе мерять, то 5.5

Да, это тоже романтика. Но такое в любом объектном языке получится, если допускать грязное залезание во внутренности. А вот укладка его на особенности реализации буфера это уже JS specific...
А ещё вспомнились r/o property, присвоение которым молча игнорируется. Вот сюда бы такую — дебаг был бы ещё дольше.

Кстати, а сможете объяснить разницу между Object и new Object?

Кстати, а сможете объяснить разницу между Object и new Object?
А вы доку смотрели?

Классика жанра habrahabr.ru/post/120193
А если честно, то у авторов Javascript р̶у̶к̶и̶ ̶и̶з̶ ̶ж̶о̶п̶ы̶ ̶р̶о̶с̶л̶и стояла задача быстро сделать простой интерпретатор для малюсеньких скриптов типа a=b+1. Давно пора было написать честный язык программирования для веб, со всеми ништяками объектной ориентированности и поддержкой сотен интерфейсов и протоколов. Но эволюция — вещь тупая от природы, а революцию так просто не сделаешь — война браузеров всё ещё ведётся.

Когда откроют путешествия во времени, напомните пристрелить автора Internet Explorer.

Когда откроют путешествия во времени, напомните пристрелить автора Internet Explorer.

Одного? Да там целый список (и в основном концентрирующийся вокруг Microsoft, что характерно)
* Gary Kildall — за вынос в CP/M имён устройств из пространства, общего с именами дисков, в пространство имён файлов
* Bill Gates — за взятие именно принципиально дефектной CP/M за основу для MS-DOS и за \ как разделитель файлов
* Авторы Winsock — за грубейшее нарушение уровневости (socket стиля BSD — должен быть одноуровневый с CRT descriptor, а не с Win handle)
* Куча народу из Intel — за каждое следующее развитие x86 в стиле «мы не умеем думать даже на шаг вперёд, но зато амбиций выше крыши»
* Аналогично AMD — за x86-84 на коленке и через зад, прошлёпав все возможности для нормализации
& etc etc etc...

А вот у DEC и Sun стрелять надо не технарей, а маркетологов.

Кстати, пересмотрел еще раз, не понял в чем юмор когда он с массивом играет, все довольно логично в отличии от объектов.

Js не знаю.
Предположу — Undefined, 50.

Скиньте потом кто-то правильные ответы под спойлером.

мне казалось логичным, что undefined и 10, но после проверки оказалось, что нет.
но я начинающий в js — мне простительно не знать
p.s. такие задачи любят на собеседованиях подсовывать. скажите, кто-то реально пишет такой код? если да, то почему эти люди вообще работают программистами?

Ок. Тривиальная задача:

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

есть шаблон некой структуры данных. Надо минимальными средствами сделать 2 отдельные копии, а не ссылки на один и тот же объект. В языках, поддерживающих классы, это элементарно. Но не в JS.
Это вы сейчас хотели сделать 2 объекта с одним ... назовем это ... «прототипом»?
Что-то такое:
jsbin.com/...ixopanigu/edit?js,console
?

именно. Способов есть много.
Просто тут хотел показать, как многие ошибочно принимают слово new за новую копию объекта.

ну вы в ленту посмотрите и сразу таких найдете :)

именно. Способов есть много.
Угу, и они __проще__ чем «В языках, поддерживающих классы» :)
Просто тут хотел показать, как многие ошибочно принимают слово new за новую копию объекта.
Ну если не читать доку, то можно и не такого нафантазировать. Но тут проблема не в языке, а в том что кто-то просто ленивая з...ца. И да, этих з...ц таки очень много.
К слову, в вашем примере знание того что есть конструкция «new», не поможет, потому что в доке явно описано поведение для конкретного «класса».

В любом языке есть правила. Они позволяют не заучивать тонны конкретных применений, а выучить одну логическую цепочку, которая позволит правильно построить выражение.
Так вот согласно какому логическому правилу в этом случае конструкция «new» не поможет?
Это особенность конкретного применения к конструктору Object()? Ок, но тогда это не правило, а исключение. А об исключениях в документации принято упоминать. Чего на странице
developer.mozilla.org/...t/Reference/Operators/new
не сделано.
Потому люди, читающие доку, и могут войти в заблуждение.

А об исключениях в документации принято упоминать. Чего на странице
developer.mozilla.org/...t/Reference/Operators/new
не сделано.
Потому люди, читающие доку, и могут войти в заблуждение.
От как раз люди НЕ читавшие или НЕ умеющие доку. :)
В более общем блоке документации не указывают все возможные исключения (как правило), ибо не эффективно чтобы абстракция знала о всех своих реализациях.
.
От только честно, вы же не открывали доку ни по классу Object, ни по оператору new. Вы понадеялись на свою интуицию. Это нормально. Я тоже так часто делаю. Часто это эффективно. Иногда это совсем не эффективно.
В вашем случае, проблема не в Object или new, а в том что вы даже основы языка (про прототипом наследование) не посмотрели, задача, которую вы пытались решить, попросту «вшита» в язык.

Проблема как раз в том, что развитие языков движется в сторону легкой читаемости. И если есть вещи, которые интуитивно воспринимаются не так, как есть на самом деле, они должны быть исключены из синтаксиса.
Кстати, так а какую я задачу хотел решить? :)

Проблема как раз в том, что развитие языков движется в сторону легкой читаемости.
Легкая читаемость != совпадение с фантазиями каждого
Кстати, так а какую я задачу хотел решить? :)
dou.ua/...orums/topic/15572/#812619

это не задача, а лишь один из моментов, который в JS решается не так, как можно было бы подумать. Я ставил себе задачу понять, почему с Object() оператор new работает не так. Особенно если учесть, что:
«Brendan Eich (создатель JavaScript) захотел, чтобы JavaScript был похож на традиционные ОО языки, такие как C++, Java, поэтому был добавлен оператор new. »
Какой был в этом смысл? Вы можете привести пример, где конструкция new Object() была бы оправдана?

да вобщем-то ни в одном языке копия объекта не создается так, как вы пытаетесь ее создать в js

Да по-моему тоже не особо то и сложно.

Object.create() - это для вас сильно сложно?

Object.create() немного не то все-таки. Он создает новый объект, устанавливая переданный аргументом объект в качестве прототипа и потом где-нибудь при проверке hasOwnProperty например это недоразумение всплывет. :)

но для данной задачи это самый правильный путь, но это моя личная точка зрения

Можно взять JSON.stringify/parse потом привязать прототип и конструктор если уж так надо.

Это уже соверешнно не нужный велосипед.

Это пример как решить абстрактный пример средствами нативного js текущего стандарта. Вот пример выше с jQ и _ действительно лишен смысла здесь. Это враперы над несколькими десятками js кода и если для вас это вызов одного библиотечного метода это не делают задачу автоматически простой.

Эту задачу можно решить либо быстро либо удобно.
Быстро — это рекурсивное копирование, удобно — это, при наличии библиотек, упомянутые clone и extend.

Двойной парсинг проигрывает в обоих случаях. Именно поэтому он — ненужный велосипед.

Двойной парсинг проигрывает в обоих случаях.
это называется сериализация. к тому же если почитали мат часть то знали бы, что это не велосипед а один из паттернов при клонировании обьектов.

Прогрывает ли тут надо смотреть. Я бы не был так категоричен высказываясь о том кто проигрывает интерпретируемая итерация по циклам или нативная браузерная сериализация.

Если бы вы, ко всему прочему, поинтересовались скоростью разных методов клонирования, то знали бы, что это сравнение уже проводилось тыщи раз и дало вполне однозначный результат.

Лет ми гугл ит фор ю:
jsperf.com/...n-stringify-json-parse/30

Хорошо. Прогнал. 24,046 операций в секунду против 56,126 в случае рекурсивного копирования. Мне никогда ещё не нужно было скопировать в секунду 24 структуры данных. Когда понадобится делать это в цикле — обращусь к рекурсивному копированию. У него кстати есть одна проблема: когда копируешь объекты, которые генерировала какая-то билиотека — никогда не знаешь когда наткнёшься на рекурсивную ссылку.
UPD. Понял, что речь о 24 тысячах операций в секунду. Тогда тем более это редко когда критично.

проверил на 20000 тыс обектов:

Chrome:
parse: 1668.588ms
recursive: 678.863ms
и
FF:
parse: 1229.00ms
recursive: 2100.45ms

то что ребята оптимальный код для хрома написали — молодцы.

На одном объекте parse/stringify работает в два раза быстрее во обоих браузерах.
Chrome:
parse: 0.282ms
recursive: 0.658ms
FF:
parse: 0.19ms
recursive: 0.55ms

Если это однозначный результат тыщу раз — то видать этот код был нагуглен 5 мин назад и не видан до сего моменту ниразу.

Двойной парсинг проигрывает в обоих случаях
Написать удобно, запомнить удобно. В чём проблема?

Если задача решается в окружении, где нету приблуд вроде андерскора или джейквери, то, вполне вероятно, там во главе угла стоит скорость исполнения. Тут парсинг джейсона проигрывает, ибо медленней. Рекурсивное копирование единожды написать тоже не сложно.

Если в окружении присутствует указанные библиотеки, то для последовательности лучше пользоваться ими.

Насколько медленно? С конкретными цифрами, пожалуйста.

Мне интереснее секунды и миллисекунды, чем относительная скорость. Выше я уже ответил по этому тесту.

— Азербайджанцы лучше, чем армяне
— Чем?
— Чем армяне

появился, но в ES6 этого кажись еще нет.

не чего сразу фейспалм? Почти нигде не видно использования пока. Так что простительно не сенйорам :)

прочтите мой комент ниже, потом поймете почему был фейспалм

подумайте, чем отличается ES6 от ES2015 ? вопрос с подвохом

ок, спасибо, буду знать. Потому как еще весной это был не утвержденный стандарт.

По-поводу сложности создания двух отдельных копий — jsbin.com/...avabaxogu/edit?js,console

Или я как-то неправильно понял идею о шаблоне структуры данных конечно.

есть шаблон некой структуры данных. Надо минимальными средствами сделать 2 отдельные копии
Структуры данных копируются легко, в гугле я как-то видел 3 или 4 способа. Мой любимый — JSON.parse(JSON.stringify(original));

шикарный способ. Но просто «new» выглядит куда изящнее. Жаль, не работает.

Ну, мы можем только пожалеть и идти дальше.

Надо минимальными средствами сделать 2 отдельные копии, а не ссылки на один и тот же объект.
bfy.tw/2juN

Підписатись на коментарі