Question about constructor property vs. instanceof
in [JavaScript]
|
Prev: How to link CSS(s) already linked to parent frame into child iframe using javascript
Next: Error getElementbyClassName
From: Garrett Smith on 13 Jan 2010 15:27 Thomas 'PointedEars' Lahn wrote: > Dmitry A. Soshnikov wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Dmitry A. Soshnikov wrote: [...] Shadow property in prototype with instance property is used where default property values are in the prototype and more specific values are set in the constructor or an instance method. function A(){} A.prototype = { v : 0, valueOf : function(){ return this.v; } }; A.prototype.addV = function(v) { this.v += v; // Shadow `v` with own property. return this; }; +new A().addV(1); This works because [[Get]] looks up the prototype to get the value of `v`, while [[Put]] sets the value of a `v` property on the instance. [[Put]] sets values on the instance, not the prototype. Instance properties are resolved quicker (though the difference of one [[Get]] would not be measurable in todays browsers). That same technique can be used with methods. An instance method can shadow a prototype method. When the default method behavior is desired, simply use delete. In the right context, that can work. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 13 Jan 2010 15:47 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Dmitry A. Soshnikov wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Dmitry A. Soshnikov wrote: > > [...] > > Shadow property in prototype with instance property is used where > default property values are in the prototype and more specific values > are set in the constructor or an instance method. > > function A(){} > A.prototype = { > v : 0, > valueOf : function(){ return this.v; } > }; > > A.prototype.addV = function(v) { > this.v += v; // Shadow `v` with own property. > return this; > }; > > +new A().addV(1); > > This works because [[Get]] looks up the prototype to get the value of > `v`, while [[Put]] sets the value of a `v` property on the instance. > [[Put]] sets values on the instance, not the prototype. > > Instance properties are resolved quicker (though the difference of one > [[Get]] would not be measurable in todays browsers). Interesting idea (not that it would be original), only that it misses all of the points of this discussion completely. > That same technique can be used with methods. No, it cannot. > An instance method can shadow a prototype method. When the default method > behavior is desired, simply use delete. In the right context, that can > work. That is _not_ the same technique at all, and we have already established that what you are proposing is a bad idea and why. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Garrett Smith on 13 Jan 2010 18:42 Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Dmitry A. Soshnikov wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> Dmitry A. Soshnikov wrote: >> [...] >> >> Shadow property in prototype with instance property is used where >> default property values are in the prototype and more specific values >> are set in the constructor or an instance method. >> [snip] >> Instance properties are resolved quicker (though the difference of one >> [[Get]] would not be measurable in todays browsers). > > Interesting idea (not that it would be original), only that it misses all > of the points of this discussion completely. > I used example to show how shadowing a property in the prototype works. Id does not matter if the property is a primitive, an object, callable object. That is beside the point I am trying to make. >> That same technique can be used with methods. > > No, it cannot. > Whether or not the value is Object or primitive does not change how the property is resolved. Do you believe that property resolution works differently, depending on the value of the property that is to be resolved? >> An instance method can shadow a prototype method. When the default method >> behavior is desired, simply use delete. In the right context, that can >> work. > > That is _not_ the same technique at all, and we have already established > that what you are proposing is a bad idea and why. > I missed that. Whatever point was made about that being a bad idea was lost amid the "nonsense," "demagogy," "idiot," offerings for crackers (I'm totally lost on the cracker metaphor), and other such noise. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Richard Cornford on 14 Jan 2010 03:56 "wmc" wrote: > Thomas 'PointedEars' Lahn wrote: > >> The problem is that one needs to have a minimum clue before being in >> a position to make an informed assessment about what was written. >> Apparently you are not, at least with regard to Flanagan. (Need >> proof? Ask Google.) > > Heh... I was noting only that with Flanagan and Crockford at least I > knew with some precision what they were *trying* to say, as opposed > to the Resig book in which the prose itself was so sloppy and vague > that I frequently had to take a WAG. In reading it, I wondered how much of the text of "Pro JavaScript Techniques" was primarily there as padding; to get the word count up to whatever was demanded by the publisher. For example:- "Since valid HTML is simply a subset of XML, having an efficient way to parse and browser DOM documents is an absolutely essential for making JavaScript development easier." - John Resig: Pro JavaScript Techniques. 2006 - is not so much vague as it is gibberish reasoning; the latter does not, in any sense, follow from the former (even if the former were not technically false (valid HTML not being a subset of XML, indeed much valid HTML does not even satisfy XML's well-formed-ness rules)). Richard.
From: John G Harris on 14 Jan 2010 10:35
On Tue, 12 Jan 2010 at 20:09:41, in comp.lang.javascript, Thomas 'PointedEars' Lahn wrote: >John G Harris wrote: > >> Remember that the 'constructor' property is entirely voluntary if you >> build the prototype object yourself instead of using the Function's >> default object. > >True. > >> I don't see a good case for having that property anyway. An object >> surely knows how to do its own job. If it doesn't then something has >> gone wrong with OO. > >IBTD. A user-defined `constructor' property of the prototype of an object >can be most useful. One basic principle of OOP is polymorphism, and one >method of achieving that is overloading; that is, a method is defined on an >object that is also defined on a superordinate object (in class-based OOP: >the superclass; in prototype-based OOP: the next object in the prototype >chain). In other languages there is Overloading and there is Overriding. Although there is no well established terminology for javascript I think that Overriding is more appropriate here. Overloading is when two different functions have the same name but different parameter types. The compiler's job is to decide which to use depending on the types used in each function call. Javascript doesn't have this feature but it can be simulated. The result is messy, fragile, and causes huge arguments when trying to test for arrays. Overriding is when two functions have the same name and the same parameter types but are defined for different levels in the same inheritance hierarchy. The compiler's job is to ensure that the more-derived function will be called even if the object is accessed via a pointer/reference to a less-derived type. Javascript has this feature built in. It's what the prototype chain does. A minor difference is that all objects are accessed via a referenced to the least-derived kind (Object). >Having the `constructor' property of the prototype of an instance allows to >overload a method in the instance's prototype (or the instance itself) and >still call the overloaded method as the Function object that is the >constructor can have (can be added) a user-defined property that refers to >the constructor of the prototype object that is next in the prototype >chain. This allows for code re-use, such as common property initialization >(and is thus most useful in constructors themselves). So you have two cases. Case 1 x.f x.constructor.prototype.f when they are different functions, and Case 2 x.f x.constructor.base_constructor.prototype.f which gets you the immediate less-derived function, if it exists. I'd have thought that Case 1 is fairly rare, as the usual arrangement is for instances to hold most of the data properties and prototype objects to hold all of the function properties. For both cases wouldn't it be cleaner to write x.protoT.f x.base_protoT.f It's less typing and nothing bad happens if constructor.prototype is reassigned. >It also allows for >an object to refer to its constructor without explicitly using the >constructor's identifier, which makes code re-use and maintenance easier. Copy and paste reuse maybe, but I'm not so sure about maintenance. Explicit constructor names make it obvious what the original coder was thinking. >One should be aware, though, that a user-defined `constructor' property, >like most user-defined properties, is enumerable. If the user-defined >object should be subject to for-in iteration, it appears necessary that it >provides an iterator that ignores those properties and other user-defined >properties that should not show up in the loop. I thought using hasOwnProperty is normal practice there. John -- John Harris |