Prototype and instanceof
Robert
I was playing a bit with prototype to find some alternative ways to do
some inheritance.
I tried the next bit of script and do not understand the output.
function instantiate(superClass, subClass)
{
function F() {};
F.prototype = superClass.prototype;
var f = new F();
subClass.prototype = f; // was curious what would happen
var obj = new subClass();
return obj;
}
function Animal() {}
function Cat() {}
Cat.create = function()
{
return instantiate(Animal, Cat);
}
function test()
{
var cat1 = Cat.create();
log("cat1 instanceof Cat: " + (cat1 instanceof Cat));
log("cat1 instanceof Animal: " + (cat1 instanceof Animal));
var cat2 = Cat.create();
log("cat2 instanceof Cat: " + (cat2 instanceof Cat));
log("cat2 instanceof Animal: " + (cat2 instanceof Animal));
log("cat1 instanceof Cat: " + (cat1 instanceof Cat));
log("cat1 instanceof Animal: " + (cat1 instanceof Animal));
}
The output is
cat1 instanceof Cat: true
cat1 instanceof Animal: true
cat2 instanceof Cat: true
cat2 instanceof Animal: true
cat1 instanceof Cat: false
cat1 instanceof Animal: true
I was surprised to see that cat1 no longer is an instance of Cat, but
still an instance of Animal. I thought the relation would be from Cat to
Animal.
So that makes me wonder what make an object an instance of something.
And what happens to the prototype chain when the prototype is changed on
the constructor function.
Jon Gómez
> Hi,
>
> I was playing a bit with prototype to find some alternative ways to do
> some inheritance.
> I tried the next bit of script and do not understand the output.
>
> function instantiate(superClass, subClass)
> {
> function F() {};
> F.prototype = superClass.prototype;
> var f = new F();
> subClass.prototype = f; // was curious what would happen
> var obj = new subClass();
> return obj;
> }
I'm a beginner with Javascript, but I believe I understand what is
happening. Here is what I think, anyway. May those who know better
feel free to correct me.
You're assigning a different object as the prototype for subClass each
time instantiate() is called. This field is used to match subClass
against instances.
The expression "cat1 instanceof Cat" causes a search through the
[[prototype]] chain of cat1 for something matching Cat.prototype. The
chain of cat1 consists of the first call's new F(), followed by the
value of Animal.prototype. Since Animal.prototype isn't changing, "cat
instanceof Animal" continues to be true, but on the second call to
instantiate(), Cat receives a new prototype property (the second new
F()) which isn't in cat1's prototype chain.
If you change the code so that everything up to "subClass.prototype = f"
only happens once in your test, then it should work. For example, I got
all trues for the following changed code (I wouldn't recommend doing it
this way, though).
function instantiate(superClass, subClass)
{
if(subClass.prototype == null) {
function F() {};
F.prototype = superClass.prototype;
var f = new F();
subClass.prototype = f; // was curious what would happen
}
var obj = new subClass();
return obj;
}
function Animal() {}
function Cat() {}
Cat.prototype = null;
See 11.8.6 and 15.3.5.3 in EMCA 262 3rd Edition for information about
how instanceof works. See 13.2 and 13.2.2 for information about prototypes.
Hope you find that useful.
Jon.
Richard Cornford
<snip>
> So that makes me wonder what make an object an instance
> of something.
The - instanceof - operator makes an assertion about the runtime
relationship between the objects on an object's prototype chain and the
current value of a function's - prototype - property. (It is not a very
useful operator in javascript.)
Specifically, - instanceof - evaluates to true if the current value of
the - prototype - property of its right hand operand (which much be a
function) is one of the objects on the internal prototype chain of the
object that is its left hand operand (if it is an object). Thus changing
the value of a function's - prototype - impacts on the outcome of -
instanceof - operations.
> And what happens to the prototype chain when the prototype is changed
> on the constructor function.
The internal prototype chain of an object is fixed at the point of the
creation of the object, because the internal [[Prototype]] property is
not exposed (and when environments expose an alternative __proto__
property they generally make it read-only).
Richard.
Robert
> The expression "cat1 instanceof Cat" causes a search through the
> [[prototype]] chain of cat1 for something matching Cat.prototype.
Ah I see, so that would be equal to this then?
I think my javascript got a bit rusty...
function isInstanceOf(obj, func)
{
var proto = obj.__proto__;
while (proto != null)
{
if (proto == func.prototype)
return true;
proto = proto.__proto__;
}
return false;
}
kangax
> Robert wrote:
[...]
>> And what happens to the prototype chain when the prototype is changed
>> on the constructor function.
>
> The internal prototype chain of an object is fixed at the point of the
> creation of the object, because the internal [[Prototype]] property is
> not exposed (and when environments expose an alternative __proto__
> property they generally make it read-only).
It is actually writable in latest versions of both Firefox and WebKit
(with some discrepancies between two). Such spoofing, of course leads to
questionable results:
// in FF 3.0.7
function f(){};
f.__proto__ = Array.prototype;
f.push(1, 2);
f[0]; // 1
f[1]; // 2
f.length; // 2
f.reverse();
f[0]; // 2
f instanceof Array; // true
f.toString(); // TypeError
In Firefox `__proto__` seems to be "DontDelete", but not "ReadOnly".
This actually makes it possible to "cut off" prototype chain of an
object, simulating a hashtable implementation (there are dozens of
alternative ways of doing so, of course, but neither should be as fast
as this one - an advantage of pure property access).
Something along the lines of:
function Hash() {
this.hash = { };
this.hash.__proto__ = null;
}
Hash.prototype.get = function(prop) {
return this.hash[prop];
};
Hash.prototype.set = function(prop, value) {
this.hash[prop] = value;
return this;
};
var h = new Hash();
typeof h.get('toString'); // "undefined"
h.set('constructor', 45).get('constructor'); // 45
--
kangax
Jon Gómez
> Richard Cornford wrote:
>> The internal prototype chain of an object is fixed at the point of the
>> creation of the object, because the internal [[Prototype]] property is
>> not exposed (and when environments expose an alternative __proto__
>> property they generally make it read-only).
>
> It is actually writable in latest versions of both Firefox and WebKit
> (with some discrepancies between two). Such spoofing, of course leads to
> questionable results:
Neat! Good to know.
Jon.
Richard Cornford
> Richard Cornford wrote:
>> Robert wrote:
> [...]
>>> And what happens to the prototype chain when the prototype is
>>> changed on the constructor function.
>>
>> The internal prototype chain of an object is fixed at the point
>> of the creation of the object, because the internal [[Prototype]]
>> property is not exposed (and when environments expose an alternative
>> __proto__ property they generally make it read-only).
>
> It is actually writable in latest versions of both Firefox and WebKit
Hence my use of the word "generally". There have always been exceptions.
> (with some discrepancies between two). Such spoofing, of course
> leads to questionable results:
<snip>
"Questionable" at minimum. It (theoretically) allows for the creation
of, for example, circular prototype chains, and a look-up of a
non-existing property on an object with a circular prototype chain
should be an endless process (as the process should only end when a -
null - [[Prototype]] appears in the chain).
> In Firefox `__proto__` seems to be "DontDelete", but not "ReadOnly".
Look closer, there are more interesting things to observe (write-once?).
> This actually makes it possible to "cut off" prototype chain of an
> object, simulating a hashtable implementation ...
<snip>
It is a nice try. You are describing an attempt to create an 'empty'
object, which is how a 'proper' hashtable should start out being (and
something ECMAScript does not provide). However, you create that object
by assigning a value to one if its properties (logically making it
non-empty from the outset).
> alternative ways of doing so, of course, but neither should be as fast
> as this one - an advantage of pure property access).
>
> Something along the lines of:
>
> function Hash() {
> this.hash = { };
> this.hash.__proto__ = null;
> }
> Hash.prototype.get = function(prop) {
> return this.hash[prop];
> };
> Hash.prototype.set = function(prop, value) {
> this.hash[prop] = value;
> return this;
> };
>
> var h = new Hash();
> typeof h.get('toString'); // "undefined"
> h.set('constructor', 45).get('constructor'); // 45
In a system where writing to - __proto__ - modifies the prototype chain,
what would be the expected outcome/consequences/side-effects of:-
h.set('__proto__', {toString:function(){return
'hello';}}).get('__proto__');
-? Alternative hashtable implementations may be slower but at least the
are predictable.
Richard.
Thomas 'PointedEars' Lahn
> kangax wrote:
>> This actually makes it possible to "cut off" prototype chain of an
>> object, simulating a hashtable implementation ...
> <snip>
>
> It is a nice try. You are describing an attempt to create an 'empty'
> object, which is how a 'proper' hashtable should start out being (and
> something ECMAScript does not provide).
ECMAScript does provide it, however not with an Object object alone:
> However, you create that object by assigning a value to one if its
> properties (logically making it non-empty from the outset).
In the hash table implementation, the value of the property to usually refer
to the Object object that is used for lookups can and should be `null' when
the hash table is empty.
> Alternative hashtable implementations may be slower but at least the
> are predictable.
Exactly, thanks for making me think.
PointedEars
kangax
> kangax wrote:
>> (with some discrepancies between two). Such spoofing, of course
>> leads to questionable results:
> <snip>
>
> "Questionable" at minimum. It (theoretically) allows for the creation
> of, for example, circular prototype chains, and a look-up of a
> non-existing property on an object with a circular prototype chain
> should be an endless process (as the process should only end when a -
> null - [[Prototype]] appears in the chain).
Interesting.
>
>> In Firefox `__proto__` seems to be "DontDelete", but not "ReadOnly".
>
> Look closer, there are more interesting things to observe (write-once?).
Ahha. I didn't notice it first time :)
In Firefox, a setter for `__proto__` seems to follow certain rules.
As my superficial observations show:
- Setting to a non-null primitive has no effect (i.e. no type conversion
to object occurs (as one might expect); assignment is simply ignored)
- Setting to an non-primitive (i.e. object type) value assigns that
value as a new one for [[Prototype]] (with all (?) of the consequences,
like proper property resolution)
- Setting to a `null` sets [[Prototype]] to `null` and (strangely)
deletes (own) `__proto__` property of an object:
function f(){};
f.__proto__ = null;
typeof f.__proto__; // "undefined"
Object.prototype.hasOwnProperty.call(f, '__proto__'); // false
It's as if `null` assignment is "special-cased" exactly for such
purposes - creating a "blank" object. Wishful thinking : )
As for the "write-once", it looks like this behavior only occurs with
`null` assignment. I suspect that when `null` "deletes" `__proto__`
property, later assignments to that property do not associate
'__proto__' with the [[Prototype]]. `__proto__` just becomes a regular
"own" property of an object:
function f(){};
f.__proto__ = Array.prototype;
'push' in f; // true
// reassigning to another object works "as expected"
f.__proto__ = RegExp.prototype;
'test' in f; // true
// null destroys __proto__ association with [[Prototype]]
f.__proto__ = null;
f.__proto__ = Array.prototype;
'push' in f; // false
// but the object is still referenced properly
typeof f.__proto__.push; // "function"
>
>> This actually makes it possible to "cut off" prototype chain of an
>> object, simulating a hashtable implementation ...
> <snip>
>
> It is a nice try. You are describing an attempt to create an 'empty'
> object, which is how a 'proper' hashtable should start out being (and
> something ECMAScript does not provide). However, you create that object
> by assigning a value to one if its properties (logically making it
> non-empty from the outset).
Good point. It's a "lucky" coincidence that assigning to `null` also
deletes a property in Firefox :)
>
>> alternative ways of doing so, of course, but neither should be as fast
>> as this one - an advantage of pure property access).
>>
>> Something along the lines of:
>>
>> function Hash() {
>> this.hash = { };
>> this.hash.__proto__ = null;
>> }
>> Hash.prototype.get = function(prop) {
>> return this.hash[prop];
>> };
>> Hash.prototype.set = function(prop, value) {
>> this.hash[prop] = value;
>> return this;
>> };
>>
>> var h = new Hash();
>> typeof h.get('toString'); // "undefined"
>> h.set('constructor', 45).get('constructor'); // 45
>
> In a system where writing to - __proto__ - modifies the prototype chain,
> what would be the expected outcome/consequences/side-effects of:-
>
> h.set('__proto__', {toString:function(){return
> 'hello';}}).get('__proto__');
If `__proto__` can be "reattached" after assigning a `null` to it (not
the case in FF), I suppose setting to `__proto__` will compromise
hashtable integrity. This can be tested upfront, of course.
>
> -? Alternative hashtable implementations may be slower but at least the
> are predictable.
Agreed. I think a strategy of coercing property names into a "safe"
subset (before reading/writing to/from hash) is the safest way to go.
I've seen implementations relying on `hasOwnProperty` but support for
`hasOwnProperty` doesn't seem to be wide enough these days - Safari <=
2.0.4 comes to mind.
--
kangax
Lasse Reichstein Nielsen
> Richard Cornford wrote:
>> It is a nice try. You are describing an attempt to create an 'empty'
>> object, which is how a 'proper' hashtable should start out being (and
>> something ECMAScript does not provide).
>
> ECMAScript does provide it, however not with an Object object alone:
Could you say how it provides it?
I can't see ECMAScript providing an empty object anywhere. Activation
objects is the closest I can get, but they will include an "arguments"
property (and they aren't available to the user).
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
David Mark
wrote:
> Thomas 'PointedEars' Lahn <PointedE...@web.de> writes:
>
> > Richard Cornford wrote:
> >> It is a nice try. You are describing an attempt to create an 'empty'
> >> object, which is how a 'proper' hashtable should start out being (and
> >> something ECMAScript does not provide).
>
> > ECMAScript does provide it, however not with an Object object alone:
>
> Could you say how it provides it?
>
> I can't see ECMAScript providing an empty object anywhere. Activation
> objects is the closest I can get, but they will include an "arguments"
> property (and they aren't available to the user).
I believe Thomas means that ECMAScript provides the means to build a
"proper" hash-table. Certainly isn't a freebie.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Richard Cornford wrote:
>>> It is a nice try. You are describing an attempt to create an 'empty'
>>> object, which is how a 'proper' hashtable should start out being (and
>>> something ECMAScript does not provide).
>> ECMAScript does provide it, however not with an Object object alone:
>
> Could you say how it provides it?
Not *again*.
PointedEars
David Mark
wrote:
> Lasse Reichstein Nielsen wrote:
> > Thomas 'PointedEars' Lahn <PointedE...@web.de> writes:
> >> Richard Cornford wrote:
> >>> It is a nice try. You are describing an attempt to create an 'empty'
> >>> object, which is how a 'proper' hashtable should start out being (and
> >>> something ECMAScript does not provide).
> >> ECMAScript does provide it, however not with an Object object alone:
>
> > Could you say how it provides it?
>
> Not *again*.
>
The explanation can't be *that* long-winded. Rename keys that are in
conflict with properties inherited by Object objects?
Lasse Reichstein Nielsen
I might have misunderstood your comment to be about providing an
"empty object", not a hash table.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Lasse Reichstein Nielsen wrote:
>>> Thomas 'PointedEars' Lahn <PointedE...@web.de> writes:
>>>> Richard Cornford wrote:
>>>>> It is a nice try. You are describing an attempt to create an
>>>>> 'empty' object, which is how a 'proper' hashtable should start
>>>>> out being (and something ECMAScript does not provide).
>>>> ECMAScript does provide it, however not with an Object object
>>>> alone:
This colon indicates that what follows it is relevant to the response.
>>> Could you say how it provides it?
>> Not *again*.
>
> The explanation can't be *that* long-winded. Rename keys that are in
> conflict with properties inherited by Object objects?
Sigh. [psf 10.1] That prevents collisions once there are entries in the
"hash table" and is therefore a good idea, but it can still be improved.
For those who haven't been paying attention:
>>>> In the hash table implementation, the value of the property to
>>>> usually refer to the Object object that is used for lookups can and
>>>> should be `null' when the hash table is empty.
PointedEars
kangax
> On Mar 22, 1:08 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> Lasse Reichstein Nielsen wrote:
>>> Thomas 'PointedEars' Lahn <PointedE...@web.de> writes:
>>>> ECMAScript does provide it, however not with an Object object alone:
>>> Could you say how it provides it?
>> Not *again*.
>>
>
> The explanation can't be *that* long-winded. Rename keys that are in
> conflict with properties inherited by Object objects?
>
That's not safe at all. It's hard to tell which keys are "in conflict"
with properties inherited from `Object.prototype` since many clients
provide proprietary ones - "__proto__", "watch", "__defineGetter__",
etc. Keeping a blacklist of all "known" keys is a silly thing to do.
Coercing all keys is a much safer way to go.
--
kangax
Thomas 'PointedEars' Lahn
> David Mark wrote:
>>> Lasse Reichstein Nielsen wrote:
>>>> Thomas 'PointedEars' Lahn <PointedE...@web.de> writes:
>>>>> ECMAScript does provide it, however not with an Object object alone:
>>>> Could you say how it provides it?
>>> Not *again*.
>> The explanation can't be *that* long-winded. Rename keys that are in
>> conflict with properties inherited by Object objects?
>
> That's not safe at all. It's hard to tell which keys are "in conflict"
> with properties inherited from `Object.prototype` since many clients
> provide proprietary ones - "__proto__", "watch", "__defineGetter__",
> etc. Keeping a blacklist of all "known" keys is a silly thing to do.
It would certainly not be sufficient. In any case, I can't see David
recommending that.
> Coercing all keys is a much safer way to go.
Just to be sure: What do you mean by that?
PointedEars
kangax
> kangax wrote:
[...]
>> Coercing all keys is a much safer way to go.
>
> Just to be sure: What do you mean by that?
Modifying property names in such way that the possibility of a conflict
is sufficiently small. For example, appending/removing a random n-length
string to each property seems pretty safe:
function Hash() {
this.hash = { };
}
(function(){
var id = '_' + (Math.random()+'').slice(2);
Hash.prototype.get = function(key) {
return this.hash[key + id];
}
Hash.prototype.set = function(key, value) {
this.hash[key + id] = value;
}
return Hash;
})();
The possibility of an environment implementing
"Object.prototype.toString_27805513696970585" seems close to nonexistent.
Of course, no matter in which convoluted ways we coerce a property name,
a client can always implement a "methodMissing"-like behavior and, say,
return certain values for certain properties even without defining those
properties on an object (or in its prototype chain).
Would this go against ECMA specs?
It's also a bit unfortunate that `hasOwnProperty` can not be trusted
either; as we can see, Firefox, for example, defines "__proto__" on
every object as an *own* property (not sharing it via `Object.prototype`
as one might think):
({}).hasOwnProperty('__proto__'); // true
How can a reliable hashtable be implemented with "hasOwnProperty" if a
newly created object (used as an internal "holder") might already have
"own" proprietary properties?
--
kangax
David Mark
var F = function() {};
(new F()).constructor.prototype.__proto__ == {}.__proto__; // true
[].constructor.prototype.__proto__ == {}.__proto__; // true
{}.constructor.prototype.__proto__ == {}.__proto__; // false
So, if x.constructor.prototype.foo is undefined or not equal to x.foo,
I think you can declare a winner (an "own" property.) Granted, as the
last result indicates, the __proto__ property is not inherited, but
created through construction. That makes sense to me, but this is not
really my department (I never use __proto__ for anything.)
Never interested in implementing a hash in Javascript, but this issue
comes up in for-in filters as well.
>
> How can a reliable hashtable be implemented with "hasOwnProperty" if a
> newly created object (used as an internal "holder") might already have
> "own" proprietary properties?
If you alias properties (yes, all of them) with a suitably long (and
documented) prefix, then what would be the problem?
kangax
>> It's also a bit unfortunate that `hasOwnProperty` can not be trusted
>> either; as we can see, Firefox, for example, defines "__proto__" on
>> every object as an *own* property (not sharing it via `Object.prototype`
>> as one might think):
>>
>> ({}).hasOwnProperty('__proto__'); // true
>
> var F = function() {};
> (new F()).constructor.prototype.__proto__ == {}.__proto__; // true
`(new F()).constructor.prototype` should reference same object as
`F.prototype` and `F.prototype` is just a result of `new Object` (when
function object is being created). Its `__proto__` of course references
`Object.prototype` as that is the next object in prototype chain:
F.prototype.__proto__ === Object.prototype; // true
`({}).__proto__` also references `Object.prototype`.
Both are same objects and so their comparison, obviously, evaluates to
true, as your example shows:
(new F()).constructor.prototype.__proto__ == ({}).__proto__; // true
> [].constructor.prototype.__proto__ == {}.__proto__; // true
Same here - `Object.prototype` on the RHS and `Array.prototype`'s
[[Prototype]] referencing `Object.prototype` as well.
> {}.constructor.prototype.__proto__ == {}.__proto__; // false
LHS should evaluate to `null` in this example, since
`Object.prototype`'s [[Prototype]] is obviously `null`. RHS still
evaluates to `Object.prototype` which `null` is not equal to :)
>
> So, if x.constructor.prototype.foo is undefined or not equal to x.foo,
> I think you can declare a winner (an "own" property.) Granted, as the
AFAIK, that's what most of the `hasOwnProperty` implementations I've
seen do (e.g. YUI). I think I've seen it in your library as well. The
common pain points here are that:
1) if an object has a property which references same object as the
same-named property of a [[Prototype]], the test will give false
positives. This is kind of an edge case of course.
var o = { toString: Object.prototype.toString };
o.constructor.prototype.toString === o.toString; // true
2) if an object has same *value* as an object referenced by the
same-named property of a [[Prototype]], the test will give false
positives as well:
var arr = [];
Array.prototype.foo = 1;
arr.foo = 1;
arr.constructor.prototype.foo === arr.foo; // true
3) host objects often don't implement `constructor` so the test falls
short on them:
typeof window.alert.constructor; // "undefined" in IE
I've also seen hacks where `__proto__` is temporarily stored, deleted
(or `null`ed), property is checked with `in` and is written to result,
`__proto__` is "restored" and then result is returned :)
I can't remember now but I think this has actually worked in at least
Safari 2.x (which is lacking native `hasOwnProperty`). Such hacks are
probably too slow and are not justified as a replacement for such
low-level (frequently called) method.
At least, that's why we never implemented this particular workaround in
Prototype.js
[...]
>> How can a reliable hashtable be implemented with "hasOwnProperty" if a
>> newly created object (used as an internal "holder") might already have
>> "own" proprietary properties?
>
> If you alias properties (yes, all of them) with a suitably long (and
> documented) prefix, then what would be the problem?
No problem. That's what I would use :)
--
kangax
David Mark
Yes, the series of comparisons were an attempt to see what a
hasOwnProperty replacement would do with __proto__. I shouldn't have
expected it to work in all cases as it couldn't be an inherited
property. All academic as I only use such things to filter for-in
loops.
[snip]