Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Terminology? Object structure definition, not a class?

Reply
Thread Tools

Terminology? Object structure definition, not a class?

 
 
Josh Russo
Guest
Posts: n/a
 
      07-23-2010
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.
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      07-23-2010
On Jul 22, 8:41*pm, Josh Russo <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
 
 
 
Garrett Smith
Guest
Posts: n/a
 
      07-23-2010
On 2010-07-22 06:34 PM, David Mark wrote:
> On Jul 22, 8:41 pm, Josh Russo<(E-Mail Removed)> wrote:
>> This is mainly for Dave, but anyone feel free to jump in.

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

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

var p = new Person();

// Check to see if `p` is an instance of Person.
p instanceof Person; // true
--
Garrett
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-23-2010
On Jul 23, 12:24*am, Garrett Smith <(E-Mail Removed)> wrote:
> On 2010-07-22 06:34 PM, David Mark wrote:
>
> > On Jul 22, 8:41 pm, Josh Russo<(E-Mail Removed)> *wrote:
> >> This is mainly for Dave, but anyone feel free to jump in.

>
> > Hi again, Josh.

>
> 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?

[...]

>
>
> >> 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?

>
> var p = new Person();
>
> // Check to see if `p` is an instance of Person.
> p instanceof Person; // true


I see. You didn't.
 
Reply With Quote
 
RobG
Guest
Posts: n/a
 
      07-23-2010
On Jul 23, 10:41 am, Josh Russo <(E-Mail Removed)> wrote:
> 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.


--
Rob
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      07-23-2010
On 2010-07-22 09:36 PM, David Mark wrote:
> On Jul 23, 12:24 am, Garrett Smith<(E-Mail Removed)> wrote:
>> On 2010-07-22 06:34 PM, David Mark wrote:
>>
>>> On Jul 22, 8:41 pm, Josh Russo<(E-Mail Removed)> wrote:
>>>> This is mainly for Dave, but anyone feel free to jump in.

>>
>>> Hi again, Josh.

>>
>> 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?
>
> [...]
>
>>
>>
>>>> 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.

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
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      07-23-2010
On 2010-07-22 10:01 PM, RobG wrote:
> On Jul 23, 10:41 am, Josh Russo<(E-Mail Removed)> wrote:
>> 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.
--
Garret
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-23-2010
On Jul 23, 1:39*am, Garrett Smith <(E-Mail Removed)> wrote:
> On 2010-07-22 10:01 PM, RobG wrote:
>
>
>
>
>
> > On Jul 23, 10:41 am, Josh Russo<(E-Mail Removed)> *wrote:
> >> 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?

> --
> Garret


You misspelled your name.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-23-2010
On Jul 23, 1:27*am, Garrett Smith <(E-Mail Removed)> wrote:
> On 2010-07-22 09:36 PM, David Mark wrote:
>
>
>
>
>
> > On Jul 23, 12:24 am, Garrett Smith<(E-Mail Removed)> *wrote:
> >> On 2010-07-22 06:34 PM, David Mark wrote:

>
> >>> On Jul 22, 8:41 pm, Josh Russo<(E-Mail Removed)> * *wrote:
> >>>> This is mainly for Dave, but anyone feel free to jump in.

>
> >>> Hi again, Josh.

>
> >> 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?

>
> > [...]

>
> >>>> 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.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      07-23-2010
On 2010-07-22 10:50 PM, David Mark wrote:
> On Jul 23, 1:27 am, Garrett Smith<(E-Mail Removed)> wrote:
>> On 2010-07-22 09:36 PM, David Mark wrote:
>>
>>
>>
>>
>>
>>> On Jul 23, 12:24 am, Garrett Smith<(E-Mail Removed)> wrote:
>>>> On 2010-07-22 06:34 PM, David Mark wrote:

>>
>>>>> On Jul 22, 8:41 pm, Josh Russo<(E-Mail Removed)> 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.

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.lang.javascript/browse_thread/thread/7e8b1e8c0db19896/b0bbd013c5b6f9d5>
[3]
<http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/301d0f5053ff914f/d897d1c410909c21>
--
Garrett
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Difference between c structure and c++ structure raghunandan_1081@yahoo.com C++ 9 11-11-2011 07:34 AM
Memory allocation in Structure to Structure pra_ramli@rediffmail.com C++ 2 03-09-2006 05:51 AM
Object creation - Do we really need to create a parent for a derieved object - can't the base object just point to an already created base object jon wayne C++ 9 09-22-2005 02:06 AM
Copy String structure "A" to string structure "B" Leo Nunez C Programming 3 02-09-2005 05:14 AM
Pointers to structure and array of structure. Excluded_Middle C Programming 4 10-26-2004 05:39 AM



Advertisments