Terminology? Object structure definition, not a class?

Discussion in 'Javascript' started by Josh Russo, Jul 23, 2010.

  1. Josh Russo

    Josh Russo Guest

    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.
     
    Josh Russo, Jul 23, 2010
    #1
    1. Advertising

  2. Josh Russo

    David Mark Guest

    On Jul 22, 8:41 pm, Josh Russo <> 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.
     
    David Mark, Jul 23, 2010
    #2
    1. Advertising

  3. On 2010-07-22 06:34 PM, David Mark wrote:
    > On Jul 22, 8:41 pm, Josh Russo<> 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
     
    Garrett Smith, Jul 23, 2010
    #3
  4. Josh Russo

    David Mark Guest

    On Jul 23, 12:24 am, Garrett Smith <> wrote:
    > On 2010-07-22 06:34 PM, David Mark wrote:
    >
    > > On Jul 22, 8:41 pm, Josh Russo<>  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. :(
     
    David Mark, Jul 23, 2010
    #4
  5. Josh Russo

    RobG Guest

    On Jul 23, 10:41 am, Josh Russo <> 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
     
    RobG, Jul 23, 2010
    #5
  6. On 2010-07-22 09:36 PM, David Mark wrote:
    > On Jul 23, 12:24 am, Garrett Smith<> wrote:
    >> On 2010-07-22 06:34 PM, David Mark wrote:
    >>
    >>> On Jul 22, 8:41 pm, Josh Russo<> 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
     
    Garrett Smith, Jul 23, 2010
    #6
  7. On 2010-07-22 10:01 PM, RobG wrote:
    > On Jul 23, 10:41 am, Josh Russo<> 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
     
    Garrett Smith, Jul 23, 2010
    #7
  8. Josh Russo

    David Mark Guest

    On Jul 23, 1:39 am, Garrett Smith <> wrote:
    > On 2010-07-22 10:01 PM, RobG wrote:
    >
    >
    >
    >
    >
    > > On Jul 23, 10:41 am, Josh Russo<>  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. :(
     
    David Mark, Jul 23, 2010
    #8
  9. Josh Russo

    David Mark Guest

    On Jul 23, 1:27 am, Garrett Smith <> wrote:
    > On 2010-07-22 09:36 PM, David Mark wrote:
    >
    >
    >
    >
    >
    > > On Jul 23, 12:24 am, Garrett Smith<>  wrote:
    > >> On 2010-07-22 06:34 PM, David Mark wrote:

    >
    > >>> On Jul 22, 8:41 pm, Josh Russo<>    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.
     
    David Mark, Jul 23, 2010
    #9
  10. On 2010-07-22 10:50 PM, David Mark wrote:
    > On Jul 23, 1:27 am, Garrett Smith<> wrote:
    >> On 2010-07-22 09:36 PM, David Mark wrote:
    >>
    >>
    >>
    >>
    >>
    >>> On Jul 23, 12:24 am, Garrett Smith<> wrote:
    >>>> On 2010-07-22 06:34 PM, David Mark wrote:

    >>
    >>>>> On Jul 22, 8:41 pm, Josh Russo<> 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
     
    Garrett Smith, Jul 23, 2010
    #10
  11. Josh Russo

    Josh Russo Guest

    On Jul 23, 3:24 am, Garrett Smith <> wrote:
    > On 2010-07-22 06:34 PM, David Mark wrote:
    >
    > > On Jul 22, 8:41 pm, Josh Russo<>  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.


    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, Jul 23, 2010
    #11
  12. Josh Russo

    Josh Russo Guest

    On Jul 23, 4:39 am, Garrett Smith <> wrote:
    > On 2010-07-22 10:01 PM, RobG wrote:
    >
    >
    >
    >
    >
    > > On Jul 23, 10:41 am, Josh Russo<>  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


    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, Jul 23, 2010
    #12
  13. Josh Russo

    Josh Russo Guest

    On Jul 23, 3:33 am, Stefan Weiss <> 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.
     
    Josh Russo, Jul 23, 2010
    #13
  14. Garrett Smith wrote:
    > On 2010-07-22 10:50 PM, David Mark wrote:
    >> On Jul 23, 1:27 am, Garrett Smith<> wrote:
    >>> On 2010-07-22 09:36 PM, David Mark wrote:
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>> On Jul 23, 12:24 am, Garrett Smith<> wrote:
    >>>>> On 2010-07-22 06:34 PM, David Mark wrote:
    >>>
    >>>>>> On Jul 22, 8:41 pm, Josh Russo<> 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.

    --
    Alan Gutierrez - - http://twitter.com/bigeasy
     
    Alan Gutierrez, Jul 23, 2010
    #14
  15. Josh Russo

    David Mark Guest

    On Jul 23, 3:08 am, Garrett Smith <> wrote:
    > On 2010-07-22 10:50 PM, David Mark wrote:> On Jul 23, 1:27 am, Garrett Smith<>  wrote:
    > >> On 2010-07-22 09:36 PM, David Mark wrote:

    >
    > >>> On Jul 23, 12:24 am, Garrett Smith<>    wrote:
    > >>>> On 2010-07-22 06:34 PM, David Mark wrote:

    >
    > >>>>> On Jul 22, 8:41 pm, Josh Russo<>      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, Jul 23, 2010
    #15
  16. Josh Russo

    David Mark Guest

    On Jul 23, 12:53 pm, Alan Gutierrez <> wrote:
    > Garrett Smith wrote:
    > > On 2010-07-22 10:50 PM, David Mark wrote:
    > >> On Jul 23, 1:27 am, Garrett Smith<>  wrote:
    > >>> On 2010-07-22 09:36 PM, David Mark wrote:

    >
    > >>>> On Jul 23, 12:24 am, Garrett Smith<>    wrote:
    > >>>>> On 2010-07-22 06:34 PM, David Mark wrote:

    >
    > >>>>>> On Jul 22, 8:41 pm, Josh Russo<>      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).
     
    David Mark, Jul 23, 2010
    #16
  17. David Mark wrote:
    > On Jul 23, 12:53 pm, Alan Gutierrez <> wrote:
    >> Garrett Smith wrote:
    >>> On 2010-07-22 10:50 PM, David Mark wrote:
    >>>> On Jul 23, 1:27 am, Garrett Smith<> wrote:
    >>>>> On 2010-07-22 09:36 PM, David Mark wrote:
    >>>>>> On Jul 23, 12:24 am, Garrett Smith<> wrote:
    >>>>>>> On 2010-07-22 06:34 PM, David Mark wrote:
    >>>>>>>> On Jul 22, 8:41 pm, Josh Russo<> 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.

    --
    Alan Gutierrez - - http://twitter.com/bigeasy
     
    Alan Gutierrez, Jul 23, 2010
    #17
  18. Josh Russo

    David Mark Guest

    On Jul 23, 2:10 pm, Alan Gutierrez <> wrote:
    > David Mark wrote:
    > > On Jul 23, 12:53 pm, Alan Gutierrez <> wrote:
    > >> Garrett Smith wrote:
    > >>> On 2010-07-22 10:50 PM, David Mark wrote:
    > >>>> On Jul 23, 1:27 am, Garrett Smith<>  wrote:
    > >>>>> On 2010-07-22 09:36 PM, David Mark wrote:
    > >>>>>> On Jul 23, 12:24 am, Garrett Smith<>    wrote:
    > >>>>>>> On 2010-07-22 06:34 PM, David Mark wrote:
    > >>>>>>>> On Jul 22, 8:41 pm, Josh Russo<>      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.
     
    David Mark, Jul 23, 2010
    #18
  19. David Mark wrote:
    > On Jul 23, 2:10 pm, Alan Gutierrez <> wrote:
    >> David Mark wrote:
    >>> On Jul 23, 12:53 pm, Alan Gutierrez <> wrote:
    >>>> Garrett Smith wrote:
    >>>>> On 2010-07-22 10:50 PM, David Mark wrote:
    >>>>>> On Jul 23, 1:27 am, Garrett Smith<> wrote:
    >>>>>>> On 2010-07-22 09:36 PM, David Mark wrote:
    >>>>>>>> On Jul 23, 12:24 am, Garrett Smith<> wrote:
    >>>>>>>>> On 2010-07-22 06:34 PM, David Mark wrote:
    >>>>>>>>>> On Jul 22, 8:41 pm, Josh Russo<> 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'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 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.

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


    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.

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


    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.

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


    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.

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


    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?

    --
    Alan Gutierrez - - http://twitter.com/bigeasy
     
    Alan Gutierrez, Jul 23, 2010
    #19
  20. Josh Russo

    David Mark Guest

    On Jul 23, 3:06 pm, Alan Gutierrez <> wrote:
    > David Mark wrote:
    > > On Jul 23, 2:10 pm, Alan Gutierrez <> wrote:
    > >> David Mark wrote:
    > >>> On Jul 23, 12:53 pm, Alan Gutierrez <> wrote:
    > >>>> Garrett Smith wrote:
    > >>>>> On 2010-07-22 10:50 PM, David Mark wrote:
    > >>>>>> On Jul 23, 1:27 am, Garrett Smith<>  wrote:
    > >>>>>>> On 2010-07-22 09:36 PM, David Mark wrote:
    > >>>>>>>> On Jul 23, 12:24 am, Garrett Smith<>    wrote:
    > >>>>>>>>> On 2010-07-22 06:34 PM, David Mark wrote:
    > >>>>>>>>>> On Jul 22, 8:41 pm, Josh Russo<>     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.

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

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

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

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

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

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

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

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

    >
    > 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. :)
     
    David Mark, Jul 23, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jianli Shen
    Replies:
    1
    Views:
    637
    Victor Bazarov
    Mar 13, 2005
  2. Ludovic Kuty
    Replies:
    3
    Views:
    2,509
    Ludovic Kuty
    Nov 2, 2009
  3. Paul
    Replies:
    63
    Views:
    1,314
  4. Hal Fulton

    Singleton class terminology

    Hal Fulton, May 8, 2005, in forum: Ruby
    Replies:
    15
    Views:
    179
    Martin DeMello
    May 10, 2005
  5. Richard A. DeVenezia

    Q: terminology function, object

    Richard A. DeVenezia, Sep 5, 2003, in forum: Javascript
    Replies:
    18
    Views:
    180
    Richard Cornford
    Sep 9, 2003
Loading...

Share This Page