From: Josh Russo on
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
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
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
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
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
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: CreateTextFile
Next: Precise printing from Javascript?