I am newbee to JavaScript. When I read the Object.create documentation, it is written like 'The Object.create() method creates a new object, using an existing object' (Ref: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create). It do not mention anything about the shallow copy of the object. But when I experimented with below script, I confirmed that, create method is performing shallow copy.
var foo = {
a : 100,
details : {
version : 1.1,
name : 'Demo of object inheritance'
},
printInfo : function(){
console.log(this.details.version);
console.log(this.details.name);
console.log(this.a);
}
}
var bar = Object.create(foo);
foo.printInfo();
bar.printInfo();
console.log("\n Updating the details and property a of bar object");
bar.details.version = 2.2;
bar.details.name = "Bar object changed the name";
bar.a = 123456;
console.log("\n")
foo.printInfo();
bar.printInfo();
Is my understanding correct? Please point to me any documentation that confirms create() method performs shallow copy.
When I executed in Scratchpad, I seen below output in console.
1.1
Demo of object inheritance
100
1.1
Demo of object inheritance
100
Updating the details and property a of bar object Scratchpad/1:21:1
2.2
Bar object changed the name
100
2.2
Bar object changed the name
123456
Object.Create does not copy anything at all, it just sets
the passed object as the prototype of a new object:
const person = {name: 'Alex', age: 29}
const newPerson = Object.create(person)
console.log(newPerson)
In order to make a shallow copy, you can use Object.assign.
const newPersonObj = Object.assign({}, person)
console.log(newPersonObj)
This will create entirely new copy.
It has nothing to with shallow copy.
Instead, you have figure it out how Prototype Inheritance works in Javascript world.
To have a better understanding, let's break this down into following 2 parts:
Reading property from child object:
When you try to access a property from a child object, Javascript parser will try to search through up prototype chain until it manages to find it else return undefined if not found.
Write property in child object
It will first try to locate that the object to which the your targeted property belongs, and then directly set that property on that object.
Let's take part of your code as example:
bar.details.version = 2.2;
What Javascript parser does:
First, details will be located through prototype chain searching and it will be found on foo (ie: bar.details === foo.details)
Second, version is directly set on details object(that's why this.details.version and this.details.name are both "unexpectedly" changed as you saw in your result and as a result bar.details.version === foo.details.version === 2.2))
bar.a = 123456;
What Javascript parser does:
Before anything gets started, bar is already located and there's no need to search though prototype chain, as a result, a will be directly set on the bar
(ie. that's why only bar.a is affected with foo.a still holding the origin value:123456)
create method is performing shallow copy.
-- EDIT --
Nope, it may seem that way but the term shallow copy would be inaccurate. It would be more in line with prototypal inheritance MDN article here
Given an object oA that has a name property, function Object.create(oA) creates a new object oB. Trying to access property oB.name would look up the prototype chain until it finds one on its prototype at oA.name.
Sample code below:
/* create one object adam */
const adam = {
name: 'Adam',
}
console.log(`does adam have own 'name' property?`, adam.hasOwnProperty('name')) // true
/* create new object bob, whose prototype 'ancestor' is adam */
const bob = Object.create(adam)
console.log(`does bob have own 'name' property? (1)`, bob.hasOwnProperty('name')) // false; the 'name' prop is on adam
/* assigning 'name' on bob doesn't change adam's name, it just 'shadows' it -- accessing 'name' on bob returns the one on bob */
bob.name = 'Bob'
console.log(`does bob have own 'name' property? (2)`, bob.hasOwnProperty('name')) // now true
/* adam and bob now each have their own 'name' property */
console.log(adam.name) // Adam
console.log(bob.name) // Bob
/* show the relationship of adam and bob */
console.log(`is adam a prototype 'ancestor' of bob?`, adam.isPrototypeOf(bob)) // true, linked via Object.create()
console.log(`is bob a prototype 'ancestor' of adam?`, bob.isPrototypeOf(adam)) // false, the prototype points one way
Hope this helps. Cheers,
Related
I'm new to JS. I'm reading a javascript book and get confused with the concept of prototype. The book says
JavaScript objects have a link to another object, known as the prototype, from which they inherit properties and methods.Object is the prototype for most objects, but it also provides some methods that are used directly, rather than through inheritance and below is an example:
let hat = {
name: "Hat",
price: 100,
getPriceIncTax() {
return Number(this.price) * 1.2;
}
};
let hatPrototype = Object.getPrototypeOf(hat);
I'm confused, since Object is the prototype of hat, so when we try to get the prototype of hat, isn't that the prototype is just the Object itself? why we still need to get it like:
let hatPrototype = Object.getPrototypeOf(hat);
isn't that just as simple as :
let hatPrototype = Object?
A prototype is just another object that is used as a fallback source of properties and methods and all objects in javascript derive from "Object.prototype". As you know, "Object.getPrototypeOf" returns the prototype of an object, because you didn't give your "hat" object a prototype, it's prototype will derive from "Object.prototype" by default, if you want to give your "hat" object a prototype, you can use "Object.create" like this.
let hatPrototype = {
getprice: function getPriceIncTax() {
return Number(this.price) * 1.2;
}
}
let hat = Object.create(hatPrototype);
hat.price = 100;
hat.name = "hat";
console.log(hat.getprice()); // returns 120
console.log(Object.getPrototypeOf(hat) == hatPrototype); // returns true
console.log(Object.getPrototypeOf(hatPrototype) == Object.prototype); // returns true
Yes, getPrototypeOf doesn't have that many usecases. Usually you do not care about the prototype chain of a certain object, and if you do, you are usually debugging and then you can find these information in your debugger.
If I wanted to clone any javascript object (that's not null), I would think I could just copy all of its own properties (enumerable and non-enumerable) -- using Object.getOwnPropertyNames -- onto a new empty object.
But I've noticed that an example of a deep cloning function provided by Dojo toolkit (https://davidwalsh.name/javascript-clone) treats RegExp, Date, and Node objects as special cases, and lodash.cloneDeep also has a lot of logic that is a lot more complicated than simply copying properties, including having some special cases of its own and apparently not supporting all types of objects: (https://github.com/lodash/lodash/blob/master/.internal/baseClone.js).
Why is simply copying the object properties not sufficient? What else is there to a javascript object besides its properties that I don't know about?
EDIT: to be clear, I'm talking about deep cloning an object. Sorry for the confusion.
If the top level properties are all value objects like strings and numbers then just copying the top level properties is fine for a clone of an object. If there are any reference objects such as dates, arrays or other objects then all your are doing is copying a reference from one object to another. If you change the reference object on the clone you will mutate the original object.
Take a look at my clone function at https://stackblitz.com/edit/typescript-qmzgf7
If it is an array it clones every item in the array, if it is a date it creates a new date with the same time, if it is an object it clones every property else if just copies the property.
The cloned object can now be mutated without worrying about effects it might have on the original object.
const clone = obj =>
Array.isArray(obj)
? obj.map(item => clone(item))
: obj instanceof Date
? new Date(obj.getTime())
: (typeof obj === 'object') && obj
? Object.getOwnPropertyNames(obj).reduce((o, prop) => ({ ...o, [prop]: clone(obj[prop]) }), {})
: obj;
let original = { prop1: "Original", objProp: { prop1: "Original" } };
let swallowCopy = { ...original };
let clonedObj = clone(original);
clonedObj.prop1 = "Changed";
clonedObj.objProp.prop1 = "Changed";
console.log(`Original objects properties are '${original.prop1}' and '${original.objProp.prop1}'`);
swallowCopy.prop1 = "Changed";
swallowCopy.objProp.prop1 = "Changed";
console.log(`Original objects properties are '${original.prop1}' and '${original.objProp.prop1}'`);
Notice how modifying the property on the object property shallow copy causes the original to change as well.
The easiest way to clone an object in JS is by using the ... spread operator.
Let's say you have this object:
const object = { foo: 1, bar: 2 }
To clone it, you can simply declare:
const objectClone = {...object}.
This will create all the properties present in the original object onto the clone, as well as their values.
Now the problem is, if you have any object nested in there, the copies will be made by reference. Suppose the original object is this instead:
const student = { studentID: 1, tests: { test1: 90, test2: 95}}
If you create a copy of that object by using the spread operator(or Object.assign, spread is just syntactic sugar), the nested object will actually point to the object inside the original object! So repeating this:
const studentClone = {...student}
And now you edit a property of the nested object inside the clone:
studentClone.tests.test1 = 80
This will change the value in both clone, and original object, as the nested object is really just pointing to 1 object in memory.
Now what those utilities, like _.cloneDeep will do, is iterate through all inner objects in the object you're cloning, and repeat the process. You could technically do it yourself, but you wouldn't be able to do it on objects with many nested objects easily. Something like this:
const studentClone = {...studentClone, tests: {...studentClone.tests}}
This would create new objects, with no reference problems.
Hope this helped!
EDIT: Just adding, object spreading would only work properly for prototype objects, of course. Each instantiated objects,such as arrays, Date objects etc, would have their own way of cloning.
Arrays can be copied similarly, through [...array]. It does follow the same rules regarding to references. For dates, you can simply pass the original date object into the Date constructor again:
const clonedDate = new Date(date)
This is where the third-party utilities will come in handy, as they'll usually handle most use cases.
This answer does a good job of explaining two of the problems with cloning a normal JavaScript object: prototype properties and circular references. But to answer your question regarding certain built-in types, the TL;DR answer is that there are 'under the hood' properties that you have no programmatic access to.
Consider:
let foo = [1, 2];
let bar = {};
Object.assign(bar, foo);
Object.setPrototypeOf(bar, foo.constructor.prototype); // aka Array.prototype
bar[0]; // 1
bar instanceof Array; // true
bar.map(x => x + 1); // [] ????
Empty array? Why? Just to make sure we're not crazy
foo.map(x => x + 1); // [2, 3]
The reason why map (and the other array methods) fail to work is that an Array isn't simply an object: it has internal slot properties for the stuff you put in it that you don't get to see as the JavaScript programmer. As another example, every JavaScript object has an internal [[Class]] property that says what kind of object it is. Fortunately for us, there's a loophole in the spec that allows us indirect access to it: the good ol Object.prototype.toString.call hack. So let's see what that has to say about various stuff:
Object.prototype.toString.call(true); // [object Boolean]
Object.prototype.toString.call(3); // [object Number]
Object.prototype.toString.call({}); // [object Object]
Object.prototype.toString.call([]); // [object Array]
Object.prototype.toString.call(null); // [object Null]
Object.prototype.toString.call(/\w/); // [object RegExp]
Object.prototype.toString.call(JSON); // [object JSON]
Object.prototype.toString.call(Math); // [object Math]
Let's see what it says about our foo and bar:
Object.prototype.toString.call(foo); // [object Array]
Object.prototype.toString.call(bar); // [object Object] Doh!
There's no way to 'convert' a random object to an Array... or a Date... or an HTMLElement... or a regex. Now, there are in fact ways to clone all of those things, but they require special logic: you can't just copy properties, or even set the prototype, because they have internal logic you can't access or directly replicate.
In normal everyday JavaScript programming we don't worry too much about this stuff, it's the kind of thing that's generally of interest to library authors (or language implementers). We everyday working stiffs just use a library to cover the edge cases and call it a day. But every once in a while the abstractions we use leak and the ugly bubbles through. This is however a great illustration of why you should probably use battle-tested libraries rather than trying to roll your own.
An object in javascript includes fields and functions together, and every field could be another object (Like Date type). If you copy a date field, it will be a reference type assignment.
Example:
var obj1 = { myField : new Date('2018/9/17') };
var obj2 = {};
obj2.myField = obj1.myField;
Now, if we change "obj2.myField" like this:
obj2.myField.setDate(obj2.myField.getDate() + 2);
console.log(obj1.myField); // Result =====> Wed Sep 19 2018 00:00:00 GMT+0430
As you see, obj1 and obj2 still are linked.
Correct way to copy a date field:
obj2.myField = new Date(obj1.myField.getTime());
Most native objects(like you have mentioned - I don't know for is the correct naming for them; maybe built-in?) are treated as "simple": it does not make sense to copy Date object property-by-property. In the same time they all are mutable in some way.
let a = {test: new Date(1)}; // test === Thu Jan 01 1970 00:00:00GMT
let copy_a = {test: a.test}; // looks like cloned
a.test.setDate(12); // let's mutate original date
console.log(copy_a.test); // Thu Jan 12 1970 00:00:00GMT ooops modified as well
So you either should handle that exceptions(special cases) explicitly or take a risk of side effects for some cases.
I'm a C/Python guy, shifted to 'Javascript' recently.
Basically, I receive an object (named context) in a function as an argument.The caller function's definition is hidden to me. Now I need to add a field(type) to the context. When I add type to context directly, it doesn't reflect changes in 'context'. But when I try to modify the value of one of the existing field of 'context', this change is reflected.
Then I create one more object(new_obj) and copy 'context' in the 'new_object', then tried to add the field in the 'new_object', but unsuccessful. So from this behaviour, I guess the value is not copied but the reference is.
So finally I need to copy field by field in the new_obj and then add the new field 'type'. Also if I create a local object, then new fields are being added and object structure is modified.
So far so good. But I was wondering about the implementation of the 'context' object in background caller function. I mean if there is some 'const' type thing here(as in C, (Random thoughts :P)), then at what level it is applied i.e. there is only restriction of adding new fields or also of changing values of the existing fields. Needed some light over this issue.
But I was wondering about the implementation of the 'context' object in background caller function. I mean if there is some 'const' type thing here(as in C, (Random thoughts :P)), then at what level it is applied i.e. there is only restriction of adding new fields or also of changing values of the existing fields. Needed some light over this issue.
It depends partially on whether the object is a host-provided object (e.g., from the browser or similar), or a true JavaScript object.
A host-provided object can do very nearly anything it wants. :-)
A true JavaScript object can be "sealed" via Object.seal. That prevents new properties being added to it, but doesn't prevent changes to existing properties — exactly matching your description of context. Here's an example:
var o = Object.seal({
answer: 0
});
console.log(o.answer); // 0
o.answer = 42;
console.log(o.answer); // 42
o.question = "Life, the Universe, and Everything";
console.log(o.question); // undefined
If you use strict mode, trying to create a property on a sealed object is a handy error:
"use strict";
var o = Object.seal({
answer: 0
});
console.log(o.answer); // 0
o.answer = 42;
console.log(o.answer); // 42
o.question = "Life, the Universe, and Everything"; // Throws error
console.log(o.question); // (we don't get here)
I'm trying to get my head around prototype inheritance in Javascript. I think I got the basic concept, but when I was playing around with this I ran into the following which still has me puzzled.
There is a very similar question and answer here but it doesn't fully answer why this is happening, at least not for me.
I create a new object like this:
var User = {
username: "",
name: {
first: "",
last: ""
}
}
Next I create two "instances" of that object:
var user1 = Object.create(User);
var user2 = Object.create(User);
Now I set the name property like so:
user1.name = { first: "John", last: "Jackson"}
user2.name = { first: "James", last: "Jameson"}
Now I do
alert(user1.name.first) \\ -> John
alert(user2.name.first) \\ -> James
All as expected. So far so good.
However, if I set the name.first property like this:
user1.name.first = "John";
user2.name.first = "James";
and I get
alert(user1.name.first) \\ -> James
alert(user2.name.first) \\ -> James
Clearly now the property is being set on the prototype object User (or rather the contained name object) instead of overriding it in the current object user1. Why does that occur?
Further if I do
user1.name.middle = "Mortimer"
I can now do
alert(User.name.middle) // -> Mortimer
which is not what I would expect. Generally, whenever a property is set on a derived object, that object either already has that property as an ownProperty in which case the value is simply assigned, or the property is newly created as an ownProperty on the derived object, overriding the prototype property. Just like happens when I assign to user1.name.
So why does assigning to an object contained in the prototype object cause such (at least to me) unexpected and counter-intuitive behavior?
The way I understand it, when the assignment is made the first check is to see if user1 has an ownProperty called name, which it doesn't. If this were a read operation the prototype property would now be looked up and User checked to see if it has ownProperty name. But since this is a set operation why walk the prototype chain when usually a missing ownProperty is simply created?
But since this is a set operation why walk the prototype chain when usually a missing ownProperty is simply created?
When you say user1.name.first = "John", the user1.name part has to be resolved before the .first property can be retrieved or set. And in your example the user1.name part only exists on the prototype object, so it is that object whose .first property you are setting.
Similarly, when you say user1.name.middle = "Mortimer", again the user1.name part resolves to the nested object from the prototype, so then you create a .middle property on that object, which is why User.name.middle also returns "Mortimer".
If you said user1.name.first and user1.name could not be resolved (on the current object or in its prototype chain) then you'd have a TypeError: Cannot set property 'first' of undefined. (You can try that concept with your existing code by saying user1.address.street = "something" - you'd get the TypeError, because user1.address doesn't exist on user1 or its prototype chain.)
Since you've already read over similar questions and answers and still seem to be having trouble understanding the behavior, I'll try to make my explanation as clear as possible. Here is where I think you are going wrong (emphasis mine):
Generally, whenever a property is set on a derived object, that object either already has that property as an ownProperty in which case the value is simply assigned, or the property is newly created as an ownProperty on the derived object, overriding the prototype property. Just like happens when I assign to user1.name.
The problem here is that you assume that user.name.first counts as "a property . . . set on a derived object" (an instance of User). However, this is simply not the case. In JavaScript, inheritance of properties is only shallow (a single layer deep). user.name is just an object value shared by reference through the prototype, so modifications to it from one place are reflected everywhere.
Think of user1.name and user2.name like firstReference and secondReference in the following example snippet, and hopefully the behavior will seem a bit clearer to you.
var User = {
username: "",
name: {
first: "",
last: ""
}
}
var firstReference = User.name
var secondReference = User.name
firstReference.name.first = 'First!'
console.log(secondReference.name) //=> 'First!' (logical and expected result)
The Object.create method creates an object using the first parameter as a prototype, and the second, optional, parameter is an additional object of own properties.
I think the problem here is that name is, by definition, in the prototype, and so not an own property.
If you want separate properties, then you should use the second parameter. The prototype is where you store methods and shared properties.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create
has more details.
The key is that you want both prototype and own properties.
this is my very first post! I have a quick question in regarding inheritance in javascript.
Of course the 'extend2' method is used to inherit child objects from the parent object using a for-in loop.
var extend2 = function (child, parent) {
var c = child.prototype;
var p = parent.prototype;
for (var i in p) {
c[i] = p[i];
}
}
I'm currently reading "Object Oriented Javascript" by Stoyan Stefanov. It's an awesome book.
Can anyone give me a good detailed explanation of how the child's prototype object is not entirely overwritten or replaced but it's just augmented?
How is it that when the objects inherit, they copy (primitive data types) instead of being looked up as a reference by using the extend2 function?
This would really help thanks!
Primitive data types in javascript are passed via value, rather than reference. Thus when you copy a value it is actually copying it, not referring to it.
Traditionally this is because a primitive was literally encoded in the memory in such a way (so the primitive int 7 would be encoded in memory as 0x7. When dealing with objects, however, they are encoded as a pointer to the memory location where the actualy object is. Thus, when you copy the value it is merely a copy of the reference pointer, not the object that that pointer referrs to.
As for the fact that the child's prototype is not replaced, that is because a prototype in java is merely another object. So a prototype may look like:
{
someField: 5
}
Which would indicate that instances of the object would initialize with a field called someField whose value is 5. with the above code, each entry in the object is copied to the child prototype, but nothing is deleted. Thus if the child prototype looks like:
{
someField: 10
someOtherField: 3
}
Then performing the above extend2 command will overwrite someField, but not someOtherField, so the resulting prototype would be:
{
someField: 5
someOtherField: 3
}