Terminology? Object structure definition, not a class?
in [JavaScript]
|
Prev: CreateTextFile
Next: Precise printing from Javascript?
From: Josh Russo on 22 Jul 2010 20:41 This is mainly for Dave, but anyone feel free to jump in. So I've been reading up on prototype and I think I have a pretty good handle on it now. What I am confused about is the general terminology. function Person(pname){ this.name = pname; this.children = [] this.addChild(cname){ this.children.push(new Person(cname)); } } If a class is the definition of an object, why can I not refer to the above as a class? (btw Dave the crockford.com site you referred me to does from time to time refer to them as classes.) What is the preferred description? Object structure, Object function, Object definition, [any statement that conveys the fact that it is representing the structure of an object without calling it a class]? Instances. Dave, you have said that calling JS variables instances creates confusion. The only confusion I have is around this statement. What does it matter? *Why* shouldn't we call them instances? And if not, what should we call them? Thanks for your help.
From: Stefan Weiss on 23 Jul 2010 00:33 On 23/07/10 02:41, Josh Russo wrote: > So I've been reading up on prototype and I think I have a pretty good > handle on it now. What I am confused about is the general terminology. > > function Person(pname){ > this.name = pname; > this.children = [] > > this.addChild(cname){ > this.children.push(new Person(cname)); > } > } > > If a class is the definition of an object, why can I not refer to the > above as a class? Because the Person function is not the definition of the object; it is just the constructor. There is no static definition of properties in JS*. Prototype-based object oriented languages are also often described as "class-less". Calling something a "class" in a class-less language is bound to create confusion. I agree with most of what David wrote in his reply, particularly about the misnamed "instanceof" operator, but I also have no problem with calling certain objects in JavaScript "instances". The term is not completely useless, it just has a slightly different meaning: in classic OOP, Blarg instances are the group of objects created by the constructor of class Blarg (or one of its derived classes); in JS, Blarg instances would be the group of objects created by the constructor "Blarg". I'm of two minds about the usefulness or correctness of calling something a "singleton" in JS. A singleton could be seen as an object created by a constructor, where certain measures are taken so that only this single instance can ever be created/accessed. I would consider this to be different from var foo = { x:42 }; which is little more than a fancy way of creating an Object instance and setting a property. Admittedly, this distinction is a rather vague. JS gives us several other - and often more natural - ways to have singular objects than class-based OOP. If the only purpose is to have "only one" object like this, an object literal will work just as well. Nobody will be interested in what the name of this object's constructor is (if it even has a name). For example, a pattern like this could be used: var singleton = new function () { var secret = "xyzzy"; this.x = 42; this.getSecret = function () { return rot13(rot13(secret)); // double safe }; }; Not that I'm recommending this. In any case, the creation of a "singleton" in JS will be quite different from the singleton pattern in classic OOP. This would suggest that the name doesn't fit well. The concept itself, on the other hand, is useful and easily understood: if a singleton is mentioned in a code comment, the author's intention is pretty clear - there can be only one. Maybe we should call them Highlanders instead of Singletons. *) this could change with ES5, I suppose -- stefan
From: Josh Russo on 23 Jul 2010 05:48 On Jul 23, 3:33 am, Stefan Weiss <krewech...(a)gmail.com> wrote: > On 23/07/10 02:41, Josh Russo wrote: > > > So I've been reading up on prototype and I think I have a pretty good > > handle on it now. What I am confused about is the general terminology. > > > function Person(pname){ > > this.name = pname; > > this.children = [] > > > this.addChild(cname){ > > this.children.push(new Person(cname)); > > } > > } > > > If a class is the definition of an object, why can I not refer to the > > above as a class? > > Because the Person function is not the definition of the object; it is > just the constructor. There is no static definition of properties in > JS*. Prototype-based object oriented languages are also often described > as "class-less". Calling something a "class" in a class-less language is > bound to create confusion. > > I agree with most of what David wrote in his reply, particularly about > the misnamed "instanceof" operator, but I also have no problem with > calling certain objects in JavaScript "instances". The term is not > completely useless, it just has a slightly different meaning: in classic > OOP, Blarg instances are the group of objects created by the constructor > of class Blarg (or one of its derived classes); in JS, Blarg instances > would be the group of objects created by the constructor "Blarg". > > I'm of two minds about the usefulness or correctness of calling > something a "singleton" in JS. A singleton could be seen as an object > created by a constructor, where certain measures are taken so that only > this single instance can ever be created/accessed. I would consider this > to be different from > > var foo = { x:42 }; > > which is little more than a fancy way of creating an Object instance and > setting a property. Admittedly, this distinction is a rather vague. JS > gives us several other - and often more natural - ways to have singular > objects than class-based OOP. If the only purpose is to have "only one" > object like this, an object literal will work just as well. Nobody will > be interested in what the name of this object's constructor is (if it > even has a name). For example, a pattern like this could be used: > > var singleton = new function () { > var secret = "xyzzy"; > this.x = 42; > this.getSecret = function () { > return rot13(rot13(secret)); // double safe > }; > }; > > Not that I'm recommending this. In any case, the creation of a > "singleton" in JS will be quite different from the singleton pattern in > classic OOP. This would suggest that the name doesn't fit well. The > concept itself, on the other hand, is useful and easily understood: if a > singleton is mentioned in a code comment, the author's intention is > pretty clear - there can be only one. Maybe we should call them > Highlanders instead of Singletons. > > *) this could change with ES5, I suppose > > -- > stefan Ok, I think I have my head around constructors now. Thanks As far as singletons go. I kind of agree with both sides of the argument. Because of the nature of JS any variable can become just about anything. Alternately, the term is extremely helpful to understand what a developer was trying to accomplish is a real world application.
From: John G Harris on 23 Jul 2010 16:06 On Fri, 23 Jul 2010 at 11:53:30, in comp.lang.javascript, Alan Gutierrez wrote: <snip> >I believe David Mark was trying to argue that instance is a bad term to >describe an object instance because you can reassign the reference used >to reach the constructor when the object was created and the instanceof >operator will fail when the constructor is sought through that >reference. Therefore, instanceof, is to David Mark a misnomer, when in >reality, the object is still an instanceof the constructor that created >it, but that constructor is no longer reachable from the reference used >to reach it at the time of construction. <snip> I'm afraid you've misunderstood the instanceof operator. In v instanceof f (v must be an object and f a function object) it tests whether the head of the prototype chain *currently* in f.prototype is in the prototype chain of v. Thus instanceof tests an object's relationship with a prototype chain. This is reasonable since it's the prototype chain that affects the object's future behaviour, not the constructor object. If the object's constructor has had its prototype property changed and the object is tested with a no longer suitable function object then that's the programmer's problem. John -- John Harris
From: Alan Gutierrez on 23 Jul 2010 16:12
John G Harris wrote: > On Fri, 23 Jul 2010 at 11:53:30, in comp.lang.javascript, Alan Gutierrez > wrote: > > <snip> >> I believe David Mark was trying to argue that instance is a bad term to >> describe an object instance because you can reassign the reference used >> to reach the constructor when the object was created and the instanceof >> operator will fail when the constructor is sought through that >> reference. Therefore, instanceof, is to David Mark a misnomer, when in >> reality, the object is still an instanceof the constructor that created >> it, but that constructor is no longer reachable from the reference used >> to reach it at the time of construction. > <snip> > > I'm afraid you've misunderstood the instanceof operator. In > v instanceof f (v must be an object and f a function object) > it tests whether the head of the prototype chain *currently* in > f.prototype is in the prototype chain of v. > > Thus instanceof tests an object's relationship with a prototype chain. > This is reasonable since it's the prototype chain that affects the > object's future behaviour, not the constructor object. > > If the object's constructor has had its prototype property changed and > the object is tested with a no longer suitable function object then > that's the programmer's problem. Thank you. Learn something new every day. -- Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy |