Terminology? Object structure definition, not a class?

[Josh Russo]

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.

 

[David Mark]

This is mainly for Dave, but anyone feel free to jump in.

Hi again, Josh.

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.

I'd be happy to help you with that problem today.

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 it is a constructor function.

(btw Dave the crockford.com site you referred me to
does from time to time refer to them as classes.)

Are you sure he's not referring to emulating classes in JS?

What is the
preferred description?

Constructor. It's used to construct objects, which are not members of
any class.

Object structure, Object function,

No, but it is a Function object. Of course, not all Function objects
are constructors (intended to be called with the - new - operator).

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.

I mentioned that calling constructed objects instances was likely to
be confusing (for those who are used to classical OO schemes). In
ECMAScript implementations (JS as I've been calling them) you
construct objects that inherit from prototypes. In other OO languages
you instantiate objects that inherit from classes (and are forever
instances of those classes).

The only confusion I have is around this statement.
What does it matter? *Why* shouldn't we call them instances?

To avoid confusion. With one exception, there's no binding between an
object and its constructor. The exception is the (mostly useless) -
constructor - property of its prototype, which may or may not be a
reference to the function used to construct the object. OTOH, there
is a binding between the constructed object and whatever object was
referenced by the constructor function's prototype property at the
time of construction. The unfortunately named - instanceof - operator
checks for that binding.

Take your example:-

function Person(pname){
  this.name = pname;
  this.children = []

  this.addChild(cname){
    this.children.push(new Person(cname));
  }
}

....please (jk). If you create a Person called josh:-

var josh = new Person('Josh');

Then, according to the - instanceof - operator, josh is an "instance"
of Person:-

josh instanceof Person; // true

But suppose you then change the prototype of Person:-

Person.prototype = {};

Is josh no longer a Person?

josh instanceof Person; // false

The josh object didn't change a bit, but according to this odd
operator, it is no longer related to the function that created it.
Furthermore, you could eliminate all references to the constructor:-

Person = null;

....and the josh remains the same. How is this possible? Because the
binding is to the object that was referenced by Person's prototype
property at the time of construction, not to the function itself.

Not quite the same as classical inheritance is it? That's why it is
best to stress the differences, rather than use terms that lump them
together.

And if
not, what should we call them?
Objects.


Thanks for your help.

NP.

 

[Garrett Smith]

Hi again, Josh.

This a public discussion newsgroup.

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.

I'd be happy to help you with that problem today.

function Person(pname){
this.name = pname;
this.children = []

this.addChild(cname){
this.children.push(new Person(cname));
}

}

The code throws errors. I suspect that's not what you wanted.
Code should be executable as transmitted.

Looking at that code, I see two missing semicolons, one after an
assignment to `this.children = []` and another after the call to
`this.addChild(cname)`. That second one will result in a SyntaxError
because the block which follows it is on the same line, and so ASI
(automatic semicolon insertion) cannot take place.

If a semicolon is inserted after the call to `this.addChild(cname)`, a
TypeError will result because `this.addChild` is not defined. If the
`addChild` method is then defined so that it can be called (without
erring), then a `ReferenceError` will result because `cname` is not
defined.

[...]

Suggested reading:
http://jibbering.com/faq/notes/posting/

Comments, including on typos, welcome.

I mentioned that calling constructed objects instances was likely to
be confusing

Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.

var p = new Person();

// Check to see if `p` is an instance of Person.
p instanceof Person; // true

 

[David Mark]

This a public discussion newsgroup.

Thanks. Sometimes I get confused.

I'd be happy to help you with that problem today.

function Person(pname){
   this.name = pname;
   this.children = []
   this.addChild(cname){
     this.children.push(new Person(cname));
   }
}

The code throws errors. I suspect that's not what you wanted.
Code should be executable as transmitted.

He's clearly got a typo in there. I'm sure that addChild was meant to
be a method created with a function expression. Why are you
responding to me about this anyway?

[...]

Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.

Not as I see it (or the confusion it creates). Did you read my post
at all?

var p = new Person();

// Check to see if `p` is an instance of Person.
p instanceof Person; // true

I see. You didn't.

 

[RobG]

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?

Because the term "class" will be interpreted by those not familiar
with ECMAScript as a class in a classic class-based object oriented
language. The general term "class" probably does apply, but the chance
of misunderstanding is very high so it's better not to use it in
regard to ECMAScript.

(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.

A function called as a constructor is called a constructor. An object
created by a constructor might reasonably be called an instance, but
that can be misleading as it has connotations in classic OO that do
not apply to ECMAScript.

The ECMAScript specification uses the term instance, however it
probably shouldn't be used outside of conversations specifically about
constructed objects and the context (or a clearly stated definition)
makes the meaning clear.

Dave, you have said that calling JS variables instances

If you are referring in general to variables declared with the var
keyword, then calling them instances is wrong. A variable is just an
identifier declared in a certain scope that might be assigned a value
(or might be left undefined). But you might be referring to variables
that reference constructed objects.

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?

Just name them after the constructor, e.g. "If I have a person object
created from a Person constructor..." then afterward just call it a
person. To differentiate it from the real person, call it a person
object, or give it a specific name, like personA or personB.

 

[Garrett Smith]

This a public discussion newsgroup.

Thanks. Sometimes I get confused.

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.

I'd be happy to help you with that problem today.

function Person(pname){
this.name = pname;
this.children = []

this.addChild(cname){
this.children.push(new Person(cname));
}

}

The code throws errors. I suspect that's not what you wanted.
Code should be executable as transmitted.

He's clearly got a typo in there. I'm sure that addChild was meant to
be a method created with a function expression. Why are you
responding to me about this anyway?

[...]

Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.

Not as I see it (or the confusion it creates). Did you read my post
at all?

What was written was corrected as it was misleading.

Even if ECMA-262 did not use the term "instance" itself, the concept of
instance would still be correctly explained by the term.

However, ECMA-262 does use the term "intance" to describe instances of
types using just that terminology (instance). Casually reading the
specification or even searching for the string "instance " would show
several examples of usage of the term:

| When an ECMAScript implementation detects a runtime error, it throws
| an instance of one of the NativeError objects

And many other such examples.

The ECMAScript specification, Eds 3 and 5 are linked from the resources
section of the FAQ
<http://jibbering.com/faq/#onlineResources>

- and for (a non-normative) convenience, in HTML:
<http://bclary.com/2004/11/07/>

 

[Garrett Smith]

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?

Because the term "class" will be interpreted by those not familiar
with ECMAScript as a class in a classic class-based object oriented
language. The general term "class" probably does apply, but the chance
of misunderstanding is very high so it's better not to use it in
regard to ECMAScript.

(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.

A function called as a constructor is called a constructor. An object
created by a constructor might reasonably be called an instance, but
that can be misleading as it has connotations in classic OO that do
not apply to ECMAScript.

Not just OO languages, other functional languages use the term
"instance" to describe the concept.

The ECMAScript specification uses the term instance, however it
probably shouldn't be used outside of conversations specifically about
constructed objects and the context (or a clearly stated definition)
makes the meaning clear.

The term "instance" can be used to describe the situation. Another way
to describe "a person instance" would be simply to call it a person.
Neither should be confusing.

 

[David Mark]

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?

Because the term "class" will be interpreted by those not familiar
with ECMAScript as a class in a classic class-based object oriented
language. The general term "class" probably does apply, but the chance
of misunderstanding is very high so it's better not to use it in
regard to ECMAScript.

(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.

A function called as a constructor is called a constructor. An object
created by a constructor might reasonably be called an instance, but
that can be misleading as it has connotations in classic OO that do
not apply to ECMAScript.

Not just OO languages, other functional languages use the term
"instance" to describe the concept.

The ECMAScript specification uses the term instance, however it
probably shouldn't be used outside of conversations specifically about
constructed objects and the context (or a clearly stated definition)
makes the meaning clear.

The term "instance" can be used to describe the situation. Another way
to describe "a person instance" would be simply to call it a person.
Neither should be confusing.

As discussed, one has the potential to be confusing for developers
used to classical OO (e.g. Java) and the other does not. Why would be
preferable?

You misspelled your name.

 

[David Mark]

Thanks.  Sometimes I get confused.

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.
I'd be happy to help you with that problem today.
function Person(pname){
    this.name = pname;
    this.children = []
    this.addChild(cname){
      this.children.push(new Person(cname));
    }
}
The code throws errors. I suspect that's not what you wanted.
Code should be executable as transmitted.

He's clearly got a typo in there.  I'm sure that addChild was meant to
be a method created with a function expression.  Why are you
responding to me about this anyway?

[...]

Instances. Dave, you have said that calling JS variables instances
creates confusion.
I mentioned that calling constructed objects instances was likely to
be confusing
Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.

Not as I see it (or the confusion it creates).  Did you read my post
at all?

What was written was corrected as it was misleading.

In your own fantasy world I presume. In reality, your response
demonstrated a stunning lack of comprehension.

 

[Garrett Smith]

[...]

What was written was corrected as it was misleading.

In your own fantasy world I presume. In reality, your response
demonstrated a stunning lack of comprehension.

I see you've snipped what was written and replied flippantly. It
reflects typical behavior of David Mark.

The specification is (still) correct.

The term "instance" is (still) a standard programming term can be -- and
is -- used to describe the concept as it exists ECMAScript. You may not
like those facts (and apparently that is the case) but that does not put
me "in a fantasy world" for stating them.

Continuing to argue that it is incorrect to use the term "instance" to
describe an ECMAScript object instance is a flagrant display of
ignorance. Especially considering that you are linking to tutorials that
use the term "instance" as reference material.
<http://www.crockford.com/javascript/private.html>

Describes "private instance members" in javascript.

The term "instance" is used to describe programming constructs in
ECMAScript such as the runtime resolution of object properties and
"instance methods" of an object itself or resolved in its prototype can
be called "instance methods".

The term is in very common. The attempt to refute its validity can't
really be rationally explained and so irrational and flippant response
such as yours came as no surprise.

The term "instance" appears in the closures article[1] in the notes, in
archived threads[2][3] (and many more), used by reliable sources (that's
not you) to describe how an instance of a particular object shares the
methods in the prototype.

[1]<http://www.jibbering.com/faq/notes/closures/>
[2]
<http://groups.google.com/group/comp...read/thread/7e8b1e8c0db19896/b0bbd013c5b6f9d5>
[3]
<http://groups.google.com/group/comp...read/thread/301d0f5053ff914f/d897d1c410909c21>

 

[Josh Russo]

Hi again, Josh.

This a public discussion newsgroup.

I'd be happy to help you with that problem today.

function Person(pname){
   this.name = pname;
   this.children = []
   this.addChild(cname){
     this.children.push(new Person(cname));
   }
}

The code throws errors. I suspect that's not what you wanted.
Code should be executable as transmitted.

Looking at that code, I see two missing semicolons, one after an
assignment to `this.children = []` and another after the call to
`this.addChild(cname)`. That second one will result in a SyntaxError
because the block which follows it is on the same line, and so ASI
(automatic semicolon insertion) cannot take place.

If a semicolon is inserted after the call to `this.addChild(cname)`, a
TypeError will result because `this.addChild` is not defined. If the
`addChild` method is then defined so that it can be called (without
erring), then a `ReferenceError` will result because `cname` is not
defined.

[...]

Suggested reading:http://jibbering.com/faq/notes/posting/

Comments, including on typos, welcome.

I apologize for that. I started writing the post and then realized I
really need to test a couple of things. This test was fully vetted
through Lint and such. I just forgot to paste it back into the post.

 

[Josh Russo]

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?

Because the term "class" will be interpreted by those not familiar
with ECMAScript as a class in a classic class-based object oriented
language. The general term "class" probably does apply, but the chance
of misunderstanding is very high so it's better not to use it in
regard to ECMAScript.

(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.

A function called as a constructor is called a constructor. An object
created by a constructor might reasonably be called an instance, but
that can be misleading as it has connotations in classic OO that do
not apply to ECMAScript.

Not just OO languages, other functional languages use the term
"instance" to describe the concept.

The ECMAScript specification uses the term instance, however it
probably shouldn't be used outside of conversations specifically about
constructed objects and the context (or a clearly stated definition)
makes the meaning clear.

The term "instance" can be used to describe the situation. Another way
to describe "a person instance" would be simply to call it a person.
Neither should be confusing.

I agree with Garret. In general I very much support calling a duck a
duck, but in this instance I fail to see the functional difference
between a classical instance and a JavaScript object as you Dave would
like to call them. How must I behave differently as a programmer when
faced with a JavaScript object vs a classical instance?

Furthermore I think that other dynamic languages like PHP, Python, and
others make your fight a loosing battle and actually end up doing
exactly the opposite of what you believe you are doing. If I
understand you correctly, the difference is that a classical instance
has a static structure. The aforementioned languages also do not have
a static structure but still refer to variables as instances.
Therefore I think you are actually creating more confusion by trying
to not call them instances. I think that it suffices to say that in
the context of a dynamic language instances are dynamic and
programmers understand that.

 

[Josh Russo]

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

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.

 

[Alan Gutierrez]

On 2010-07-22 09:36 PM, David Mark wrote:





On 2010-07-22 06:34 PM, David Mark wrote:

This is mainly for Dave, but anyone feel free to jump in.

[...]

Instances. Dave, you have said that calling JS variables instances
creates confusion.

I mentioned that calling constructed objects instances was likely to
be confusing

Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.

Not as I see it (or the confusion it creates). Did you read my post
at all?

What was written was corrected as it was misleading.

In your own fantasy world I presume. In reality, your response
demonstrated a stunning lack of comprehension.

I see you've snipped what was written and replied flippantly. It
reflects typical behavior of David Mark.

The specification is (still) correct.

The term "instance" is (still) a standard programming term can be -- and
is -- used to describe the concept as it exists ECMAScript. You may not
like those facts (and apparently that is the case) but that does not put
me "in a fantasy world" for stating them.

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.

<script>
function Person(firstName, lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
var person = new Person();
alert(person instanceof Person); // true
var Robot = Person
Person = function() {};
alert(person instanceof Person); // false
alert(person instanceof Robot); // true
</script>

I'd say he's wrong by his own reasoning. That which is returned by
calling a constructor are certainly instances.

 

[David Mark]

On 2010-07-22 09:36 PM, David Mark wrote:
On 2010-07-22 06:34 PM, David Mark wrote:
This is mainly for Dave, but anyone feel free to jump in.

[...]

Instances. Dave, you have said that calling JS variables instances
creates confusion.
I mentioned that calling constructed objects instances was likely to
be confusing
Calling a constructed object an instance is unlikely to be confusing..
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.
Not as I see it (or the confusion it creates).  Did you read my post
at all?
What was written was corrected as it was misleading.

In your own fantasy world I presume.  In reality, your response
demonstrated a stunning lack of comprehension.

I see you've snipped what was written and replied flippantly. It
reflects typical behavior of David Mark.

Nope. Your "retort" was simply a paste of *half* of one of my
examples that couldn't have been less relevant by itself. As I said,
you either didn't read my post, didn't comprehend it, or are simply
trying to turn yet another thread into a hopeless mess (what do you
get out of that BTW?)

 

[David Mark]

On 2010-07-22 09:36 PM, David Mark wrote:
On 2010-07-22 06:34 PM, David Mark wrote:
This is mainly for Dave, but anyone feel free to jump in.

[...]

Instances. Dave, you have said that calling JS variables instances
creates confusion.
I mentioned that calling constructed objects instances was likely to
be confusing
Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance"is
the correct term for what was described.
Not as I see it (or the confusion it creates).  Did you read my post
at all?
What was written was corrected as it was misleading.
In your own fantasy world I presume.  In reality, your response
demonstrated a stunning lack of comprehension.

I see you've snipped what was written and replied flippantly. It
reflects typical behavior of David Mark.

The specification is (still) correct.

The term "instance" is (still) a standard programming term can be -- and
is -- used to describe the concept as it exists ECMAScript. You may not
like those facts (and apparently that is the case) but that does not put
me "in a fantasy world" for stating them.

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.

That was but one example of the dubious nature of the instanceof
operator. The concept that it is unfortunately named and misleading
is not new (certainly not around here).

The only real point is that the term "instance" has connotations that
can easily confuse those used to classical OO. Same for "class" and
"singleton". As for the latter, why would you need to pigeonhole
objects as singles if there are no multiples? In fact, the use of
that term implies that there must be some other type of object (which
is the case in many other OO languages).

 

[Alan Gutierrez]

On 2010-07-22 10:50 PM, David Mark wrote:
On 2010-07-22 09:36 PM, David Mark wrote:
On 2010-07-22 06:34 PM, David Mark wrote:
This is mainly for Dave, but anyone feel free to jump in.
[...]
Instances. Dave, you have said that calling JS variables instances
creates confusion.
I mentioned that calling constructed objects instances was likely to
be confusing
Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.
Not as I see it (or the confusion it creates). Did you read my post
at all?
What was written was corrected as it was misleading.
In your own fantasy world I presume. In reality, your response
demonstrated a stunning lack of comprehension.
I see you've snipped what was written and replied flippantly. It
reflects typical behavior of David Mark.
The specification is (still) correct.
The term "instance" is (still) a standard programming term can be -- and
is -- used to describe the concept as it exists ECMAScript. You may not
like those facts (and apparently that is the case) but that does not put
me "in a fantasy world" for stating them.

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.

That was but one example of the dubious nature of the instanceof
operator. The concept that it is unfortunately named and misleading
is not new (certainly not around here).

The only real point is that the term "instance" has connotations that
can easily confuse those used to classical OO. Same for "class" and
"singleton". As for the latter, why would you need to pigeonhole
objects as singles if there are no multiples? In fact, the use of
that term implies that there must be some other type of object (which
is the case in many other OO languages).

Is your argument that "instance" is confusing because it is overloaded
with meaning? That is true of so many words in computing. I'm not sure
where you're going with "class" and "singleton". I'm not arguing those
meanings, so I'll leave you to do that on your own.

The word "instance" is meaningful. It defines and "instance" of a type
defined by a constructor.

I find this behavior interesting.

<script>
function Person(firstName, lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
var person = new Person("Alan", "Gutierrez");
alert(person instanceof Person); // true
Person.prototype = {};
alert(person instanceof Person); // false
var person = new Person("Alan", "Gutierrez");
alert(person.firstName); // Alan
alert(person instanceof Person); // true
</script>

Thus, it seems that type is defined by a relationship between the
prototype instance and the object instance. What specification to you
all consider the authority here? The following?

http://www.ecmascript.org/docs.php

In any case, programmers porting their knowledge form another language
can be told that an instance is defined by a prototype and not a class
and then they should be on their way.

 

[David Mark]

Garrett Smith wrote:
On 2010-07-22 10:50 PM, David Mark wrote:
On 2010-07-22 09:36 PM, David Mark wrote:
On 2010-07-22 06:34 PM, David Mark wrote:
This is mainly for Dave, but anyone feel free to jump in.
[...]
Instances. Dave, you have said that calling JS variables instances
creates confusion.
I mentioned that calling constructed objects instances was likely to
be confusing
Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.
Not as I see it (or the confusion it creates).  Did you read my post
at all?
What was written was corrected as it was misleading.
In your own fantasy world I presume.  In reality, your response
demonstrated a stunning lack of comprehension.
I see you've snipped what was written and replied flippantly. It
reflects typical behavior of David Mark.
The specification is (still) correct.
The term "instance" is (still) a standard programming term can be -- and
is -- used to describe the concept as it exists ECMAScript. You may not
like those facts (and apparently that is the case) but that does not put
me "in a fantasy world" for stating them.
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.

That was but one example of the dubious nature of the instanceof
operator.  The concept that it is unfortunately named and misleading
is not new (certainly not around here).

The only real point is that the term "instance" has connotations that
can easily confuse those used to classical OO.  Same for "class" and
"singleton".  As for the latter, why would you need to pigeonhole
objects as singles if there are no multiples?  In fact, the use of
that term implies that there must be some other type of object (which
is the case in many other OO languages).

Is your argument that "instance" is confusing because it is overloaded
with meaning?

Partly that and partly due to the inherently confusing nature of the -
instanceof - operator. I think I've made my points quite clear.

That is true of so many words in computing.

We aren't discussing other words.

I'm not sure
where you're going with "class" and "singleton". I'm not arguing those
meanings, so I'll leave you to do that on your own.

I think those points were clear enough as well. If everything is
black, then there is no need to consider the concept of color is
there? In fact, referring to such things as "black" implies that
there must be other things that are "white".

The word "instance" is meaningful. It defines and "instance" of a type
defined by a constructor.

Constructors don't define "types". All native objects are the same
type. See how easy it is to get confused if you don't understand the
basic concepts?

I find this behavior interesting.

<script>
function Person(firstName, lastName) {
     this.firstName = firstName;
     this.lastName = lastName;}

var person = new Person("Alan", "Gutierrez");
alert(person instanceof Person); // true
Person.prototype = {};
alert(person instanceof Person); // false
var person = new Person("Alan", "Gutierrez");
alert(person.firstName); // Alan
alert(person instanceof Person); // true
</script>

Yes, that's a rewrite of one of my examples. But it's only of
particular interest if you don't understand how the language works
(and such programmers are prone to confusion).

Thus, it seems that type is defined by a relationship between the
prototype instance and the object instance. What specification to you
all consider the authority here?

The behavior of ECMAScript implementations is clearly defined and
formally specified. Use of the word "seems" is only applicable when
there is confusion about its definition.

The following?

http://www.ecmascript.org/docs.php

That's a good starting off point.

In any case, programmers porting their knowledge form another language
can be told that an instance is defined by a prototype and not a class
and then they should be on their way.

I'm afraid you have oversimplified my arguments, much in the same way
as your characterization of "no libraries" arguments in another
thread. Clearly you have much to learn. That's no crime, but you
should spend your initial time here reading more and arguing less.

 

[Alan Gutierrez]

Garrett Smith wrote:
On 2010-07-22 10:50 PM, David Mark wrote:
On 2010-07-22 09:36 PM, David Mark wrote:
On 2010-07-22 06:34 PM, David Mark wrote:
This is mainly for Dave, but anyone feel free to jump in.
[...]
Instances. Dave, you have said that calling JS variables instances
creates confusion.
I mentioned that calling constructed objects instances was likely to
be confusing
Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.
Not as I see it (or the confusion it creates). Did you read my post
at all?
What was written was corrected as it was misleading.
In your own fantasy world I presume. In reality, your response
demonstrated a stunning lack of comprehension.
I see you've snipped what was written and replied flippantly. It
reflects typical behavior of David Mark.
The specification is (still) correct.
The term "instance" is (still) a standard programming term can be -- and
is -- used to describe the concept as it exists ECMAScript. You may not
like those facts (and apparently that is the case) but that does not put
me "in a fantasy world" for stating them.
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.
That was but one example of the dubious nature of the instanceof
operator. The concept that it is unfortunately named and misleading
is not new (certainly not around here).
The only real point is that the term "instance" has connotations that
can easily confuse those used to classical OO. Same for "class" and
"singleton". As for the latter, why would you need to pigeonhole
objects as singles if there are no multiples? In fact, the use of
that term implies that there must be some other type of object (which
is the case in many other OO languages).

Is your argument that "instance" is confusing because it is overloaded
with meaning?

Partly that and partly due to the inherently confusing nature of the -
instanceof - operator. I think I've made my points quite clear.

That is true of so many words in computing.

We aren't discussing other words.

We were discussing instance. You argue that it is overloaded.

I think those points were clear enough as well. If everything is
black, then there is no need to consider the concept of color is
there? In fact, referring to such things as "black" implies that
there must be other things that are "white".

The concept of "class" my indeed not directly apply to JavaScript, but
the concept of a "singleton" is design pattern and is as applicable to
JavaScript as it is to any language.

Constructors don't define "types". All native objects are the same
type. See how easy it is to get confused if you don't understand the
basic concepts?

In this sense I'm talking about the abstract concept of "type". Which is
meaningful if there is an "instanceof" operator, it must be an
"instanceof" something. JavaScript does have the concept "prototype"
built into it, and "instanceof" has a relationship with "prototype". The
"prototype" is how users define "types" in JavaScript.

Yes, that's a rewrite of one of my examples. But it's only of
particular interest if you don't understand how the language works
(and such programmers are prone to confusion).

It is of particular interest because it illustrates the value of the
word "instance" to a discussion of JavaScript. That JavaScript does
create "instances" and that your pedagogy is deeply flawed.

The behavior of ECMAScript implementations is clearly defined and
formally specified. Use of the word "seems" is only applicable when
there is confusion about its definition.

Yes. And by simply picking at the phrasing of my statements, this
indicates that you are unable or unwilling to lend any insight. All you
are doing is using my sincere, inquisitive nature to attempt to
establish yourself as an authority.

That's a good starting off point.


I'm afraid you have oversimplified my arguments, much in the same way
as your characterization of "no libraries" arguments in another
thread. Clearly you have much to learn. That's no crime, but you
should spend your initial time here reading more and arguing less.

Ad Hominem much?

I'm afraid your acting the pedant and not making a sincere attempt at
dialog. In my last message, I attempted to move away from argument, and
toward inquiry, but your insistence on your own authority has brought us
back to argument. Is it not equality clear that you have much to learn?
Much to learn not only from me but from other members of the software
communities in which you participate?

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
On 2010-07-22 10:50 PM, David Mark wrote:
On 2010-07-22 09:36 PM, David Mark wrote:
On 2010-07-22 06:34 PM, David Mark wrote:
This is mainly for Dave, but anyone feel free to jump in.
[...]
Instances. Dave, you have said that calling JS variables instances
creates confusion.
I mentioned that calling constructed objects instances was likely to
be confusing
Calling a constructed object an instance is unlikely to be confusing.
The concept of instances exists in many other languages. "Instance" is
the correct term for what was described.
Not as I see it (or the confusion it creates).  Did you read my post
at all?
What was written was corrected as it was misleading.
In your own fantasy world I presume.  In reality, your response
demonstrated a stunning lack of comprehension.
I see you've snipped what was written and replied flippantly. It
reflects typical behavior of David Mark.
The specification is (still) correct.
The term "instance" is (still) a standard programming term can be -- and
is -- used to describe the concept as it exists ECMAScript. You maynot
like those facts (and apparently that is the case) but that does not put
me "in a fantasy world" for stating them.
I believe David Mark was trying to argue that instance is a bad termto
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.
That was but one example of the dubious nature of the instanceof
operator.  The concept that it is unfortunately named and misleading
is not new (certainly not around here).
The only real point is that the term "instance" has connotations that
can easily confuse those used to classical OO.  Same for "class" and
"singleton".  As for the latter, why would you need to pigeonhole
objects as singles if there are no multiples?  In fact, the use of
that term implies that there must be some other type of object (which
is the case in many other OO languages).
Is your argument that "instance" is confusing because it is overloaded
with meaning?

Partly that and partly due to the inherently confusing nature of the -
instanceof - operator.  I think I've made my points quite clear.

We aren't discussing other words.

We were discussing instance. You argue that it is overloaded.

I think those points were clear enough as well.  If everything is
black, then there is no need to consider the concept of color is
there?  In fact, referring to such things as "black" implies that
there must be other things that are "white".

The concept of "class" my indeed not directly apply to JavaScript, but
the concept of a "singleton" is design pattern and is as applicable to
JavaScript as it is to any language.

No classes means that there is no need to refer to singletons. Quite
the contrary, such references can and will lead to confusion among
those indoctrinated in classical OOP.

In this sense I'm talking about the abstract concept of "type". Which is
meaningful if there is an "instanceof" operator, it must be an
"instanceof" something.

What you don't seem to realize is that that operator doesn't work as
"advertised". More confusion.

JavaScript does have the concept "prototype"
built into it, and "instanceof" has a relationship with "prototype". The
"prototype" is how users define "types" in JavaScript.

See my examples (which you recently quoted) with regard to that
operator's behavior.

It is of particular interest because it illustrates the value of the
word "instance" to a discussion of JavaScript. That JavaScript does
create "instances" and that your pedagogy is deeply flawed.

It's of no interest at all at this point (except perhaps to those who
arrived late). And no, my "pedagogy" is not deeply flawed; you are
simply a newcomer who thinks he knows more than he does. There's a
new one every week.

Yes. And by simply picking at the phrasing of my statements, this
indicates that you are unable or unwilling to lend any insight.

I've given you considerable insight; but you seem not to have grasped
some (or all) of it.

All you
are doing is using my sincere, inquisitive nature to attempt to
establish yourself as an authority.

No, I'm really getting tired of your rapid-fire "sincerity" and
accompanying questions. You've either got it at this point or you
don't.

Ad Hominem much?

That wasn't an ad hominem either (it was an admonition). You seem to
have a problem with using terms in a slightly-off manner. *That* was
an ad hominem (though relevant to the current discussion).

I'm afraid your acting the pedant and not making a sincere attempt at
dialog.

The relevant dialog related to the OP's question is long over.

In my last message, I attempted to move away from argument, and
toward inquiry, but your insistence on your own authority has brought us
back to argument.

I hope it doesn't surprise you that I have no interest in getting into
an "inquiry vs. argument" debate with you.

Is it not equality clear that you have much to learn?
No.

Much to learn not only from me but from other members of the software
communities in which you participate?

No. And I can't help but ask, what communities would those be? If
you are referring to projects like jQuery and Dojo, then much to learn
you have.