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: Thomas 'PointedEars' Lahn on 12 Jan 2010 14:09 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). 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). 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. 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. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Jorge on 12 Jan 2010 20:32 On Jan 12, 8:09 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > > 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). (...) The need to access a superclass in order to achieve polymorphism is ~non-inexistent, for in a weakly typed language such as JS a single method is usually enough -> there's no need to overload anything, nor access a superclass. And, in any case, in order for a method "method" of an instance "this" to access its superclass' method "method", there's no need to use neither "this.__proto__", nor this.constructor, nor this.constructor.prototype, nor an "explicit constructor's identifier". -- Jorge.
From: David Mark on 13 Jan 2010 01:25 On Jan 11, 10:01 am, wmc <...> wrote: > I'm currently reading a JS book (Zakas, Prof. JavaScript for Web > Developers, 2nd. Ed.) Do not waste money on browser scripting books by Zakas. He's been proven clueless about the subject as recently as a week ago. ;)
From: Thomas 'PointedEars' Lahn on 13 Jan 2010 03:14 Jorge wrote: > Thomas 'PointedEars' Lahn wrote: >> 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). (...) > > The need to access a superclass in order to achieve polymorphism is > ~non-inexistent, for in a weakly typed language such as JS a single > method is usually enough -> there's no need to overload anything, nor > access a superclass. A need that you are unable to perceive is still a need. I am using this pattern to my advantage, with the exception of the use of the word "superclass" (as there are no classes). > And, in any case, in order for a method "method" of an instance "this" > to access its superclass' method "method", there's no need to use > neither "this.__proto__", nor this.constructor, nor > this.constructor.prototype, nor an "explicit constructor's > identifier". Then, pray tell, how would you call it then (ignoring in your favor again that there are no classes, and so no superclasses)? PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: David Mark on 13 Jan 2010 03:24
Thomas 'PointedEars' Lahn wrote: > Jorge wrote: [...] > >> And, in any case, in order for a method "method" of an instance "this" >> to access its superclass' method "method", there's no need to use >> neither "this.__proto__", nor this.constructor, nor >> this.constructor.prototype, nor an "explicit constructor's >> identifier". > > Then, pray tell, how would you call it then (ignoring in your favor again > that there are no classes, and so no superclasses)? > Even without the "class" confusion, the cited paragraph makes no sense (on any level). Why ask why? |