Terminology? Object structure definition, not a class?
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? (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
> On Jul 22, 8:41 pm, Josh Russo<josh.r.ru...@gmail.com> 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
Stefan Weiss
> 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
David Mark
> On 2010-07-22 06:34 PM, David Mark wrote:
>
> > On Jul 22, 8:41 pm, Josh Russo<josh.r.ru...@gmail.com> 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. :(
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.
--
Rob
Garrett Smith
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
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
David Mark
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
In your own fantasy world I presume. In reality, your response
demonstrated a stunning lack of comprehension.
Garrett Smith
> On Jul 23, 1:27 am, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>> On 2010-07-22 09:36 PM, David Mark wrote:
>>
>>
>>
>>
>>
>>> On Jul 23, 12:24 am, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>>> On 2010-07-22 06:34 PM, David Mark wrote:
>>
>>>>> On Jul 22, 8:41 pm, Josh Russo<josh.r.ru...@gmail.com> 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
Josh Russo
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
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
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
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 - al...@blogometer.com - http://twitter.com/bigeasy
David Mark
> On 2010-07-22 10:50 PM, David Mark wrote:> On Jul 23, 1:27 am, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
> >> On 2010-07-22 09:36 PM, David Mark wrote:
>
> >>> On Jul 23, 12:24 am, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
> >>>> On 2010-07-22 06:34 PM, David Mark wrote:
>
> >>>>> On Jul 22, 8:41 pm, Josh Russo<josh.r.ru...@gmail.com> 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
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
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
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
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?
David Mark
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. :)
Alan Gutierrez
Sure there is. A single instance of an object that encapsulates its
state and can possibly be a pluggable implementation. There's a lot of
value there still, even if you don't have a class, you still the concept
of type and a singleton is still a single instance of the type.
>>>> 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.
Where is the advertisement? I illustrated clearly my understanding of
how instanceof works. You have not questioned that. You only keep saying
that I seem confused based on words in my sentences, not on the
reasoning of my logic.
I understand now how it works and how it would be useful. It is useful
to determine if an instance of an object is an instanceof a particular
prototype. So long as you keep a reference to the the prototype around
and in the place where it is expected to be, it could be quite useful
indeed.
Is there some way in which it fails to work?
>> 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.
To what end? I made a point here that you won't address.
JavaScript has user defined "type". I know it. You know it. We all know it.
>>>> 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.
I find it very interesting. I wish there was someone here who would
simply affirm what I've observed. That would help me learn.
>>>> 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.
Hmm... You've made some point about "instance" being a misnomer. I
disagree with you. You can't seem to accept that.
>> 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.
I'm be very considerate. I'm responding to you when you respond to me.
You're fortunate to have my attentions, just as I am fortunate to have
yours.
>>>> 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).
It is not appropriate to admonish me. It can be taken as an attempt to
establish yourself as a superior, when there can be no such relationship
on USENET. It can be taken as an attempt to discredit my point by
discrediting me by saying I'm not experienced enough to make my point.
That would the definition of ad hominem. Arguing the man instead of
arguing the point.
>> 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.
No its not. You've not addressed my reasoning on the applicability of
the word "instance".
>> 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.
No, it doesn't. But, the key point here is that I'm making a valid
inquiry, and not directly to you. I expressed my understanding of
"instanceof" and sought validation, but have received none. I'd expect
someone in the group to address that directly.
>> Is it not equality clear that you have much to learn?
>
> No.
Well, then. I am a humble man. You are not. I am not obligated to share
your with you your certainty in yourself.
>> 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.
Hmm... I'm not sure you understand the question. Do you feel you have
anything to learn from the software communities in which *you* participate?
Currently, I'm participating in com.lang.javascript because there is
much for me to learn from the other members, or at least there could be,
if this is a forum that is functioning as a forum of peers. If it is a
place for a pedagog to hold court, then it is of no value to me. It
might be of value to other people, but I don't learn that way.
John G Harris
wrote:
<snip>
>I believe David Mark was trying to argue that instance is a bad term to
>describe an object instance because you can reassign the reference used
>to reach the constructor when the object was created and the instanceof
>operator will fail when the constructor is sought through that
>reference. Therefore, instanceof, is to David Mark a misnomer, when in
>reality, the object is still an instanceof the constructor that created
>it, but that constructor is no longer reachable from the reference used
>to reach it at the time of construction.
<snip>
I'm afraid you've misunderstood the instanceof operator. In
v instanceof f (v must be an object and f a function object)
it tests whether the head of the prototype chain *currently* in
f.prototype is in the prototype chain of v.
Thus instanceof tests an object's relationship with a prototype chain.
This is reasonable since it's the prototype chain that affects the
object's future behaviour, not the constructor object.
If the object's constructor has had its prototype property changed and
the object is tested with a no longer suitable function object then
that's the programmer's problem.
John
--
John Harris
Alan Gutierrez
Thank you. Learn something new every day.
David Mark
> John G Harris wrote:
[...]
>
> > If the object's constructor has had its prototype property changed and
> > the object is tested with a no longer suitable function object then
> > that's the programmer's problem.
>
> Thank you. Learn something new every day.
>
You could have saved yourself a lot of time by carefully reading my
examples and thinking about what I was trying to illustrate with them.
In other words, you should have heeded my previous warning(s) instead
of conflating them to ad hominems.
HTH
Alan Gutierrez
> On Jul 23, 4:12 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>> John G Harris wrote:
>
> [...]
>
>>> If the object's constructor has had its prototype property changed and
>>> the object is tested with a no longer suitable function object then
>>> that's the programmer's problem.
>> Thank you. Learn something new every day.>
>
> You could have saved yourself a lot of time by carefully reading my
> examples and thinking about what I was trying to illustrate with them.
That would have saved time? I don't think so. This was lightening fast.
I asked a question and got an answer that clarified my understanding.
This is how I learn. I ask pointed questions seeking pointed answers.
> In other words, you should have heeded my previous warning(s) instead
> of conflating them to ad hominems.
> HTH
No. It doesn't. I believe you are simply trying to assert yourself
again. This comment adds nothing to the conversation. Your descriptions
were opaque. You were hammering home some point about what is or is not
confusing to other people, not speaking directly to inquiries.
This is truly helpful, to have direct questions answered. What you've
done, so far, has not been very helpful to me at all. You still have not
address the point I made in the other branch of the thread, that
"instance" is a valid description of an "instance" of a "prototype" in
JavaScript.
David Mark
> David Mark wrote:
> > On Jul 23, 4:12 pm, Alan Gutierrez <a...@blogometer.com> wrote:
> >> John G Harris wrote:
>
> > [...]
>
> >>> If the object's constructor has had its prototype property changed and
> >>> the object is tested with a no longer suitable function object then
> >>> that's the programmer's problem.
> >> Thank you. Learn something new every day.>
>
> > You could have saved yourself a lot of time by carefully reading my
> > examples and thinking about what I was trying to illustrate with them.
>
> That would have saved time? I don't think so. This was lightening fast.
I thought it was pretty heavy myself. Granted you diluted the hell
out of it by the end. :)
> I asked a question and got an answer that clarified my understanding.
You already had the answers under your nose.
>
> This is how I learn. I ask pointed questions seeking pointed answers.
And you are constantly getting stuck.
>
> > In other words, you should have heeded my previous warning(s) instead
> > of conflating them to ad hominems.
> > HTH
>
> No. It doesn't. I believe you are simply trying to assert yourself
> again.
You like talking about me, don't you?
> This comment adds nothing to the conversation. Your descriptions
> were opaque.
Not to everyone it seems. Doesn't that indicate that you had a
problem?
> You were hammering home some point about what is or is not
> confusing to other people, not speaking directly to inquiries.
Oddly enough, that was the point of the discussion until you tried to
turn it into a private tutoring session.
>
> This is truly helpful, to have direct questions answered. What you've
> done, so far, has not been very helpful to me at all.
In case you hadn't noticed, this is not a help desk. :)
> You still have not
> address the point I made in the other branch of the thread, that
> "instance" is a valid description of an "instance" of a "prototype" in
> JavaScript.
I'm through repeating myself for your admitted lack of benefit. Best
of luck!
Alan Gutierrez
> On Jul 23, 4:45 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>> David Mark wrote:
>>> On Jul 23, 4:12 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>>>> John G Harris wrote:
>>> [...]
>>>>> If the object's constructor has had its prototype property changed and
>>>>> the object is tested with a no longer suitable function object then
>>>>> that's the programmer's problem.
>>>> Thank you. Learn something new every day.>
>>> You could have saved yourself a lot of time by carefully reading my
>>> examples and thinking about what I was trying to illustrate with them.
>> That would have saved time? I don't think so. This was lightening fast.
>
> I thought it was pretty heavy myself. Granted you diluted the hell
> out of it by the end. :)
>
>> I asked a question and got an answer that clarified my understanding.
>
> You already had the answers under your nose.
>
>> This is how I learn. I ask pointed questions seeking pointed answers.
>
> And you are constantly getting stuck.
How would you know? I've only asked one question so far, and I've
received one answer. There is no history of me being stuck on this
newsgroup.
>>> In other words, you should have heeded my previous warning(s) instead
>>> of conflating them to ad hominems.
>>> HTH
>> No. It doesn't. I believe you are simply trying to assert yourself
>> again.
>
> You like talking about me, don't you?
I'm kind of creeping into characterizing your half of this conversation,
but otherwise, I'd say that you've been very quick to characterize me as
a person. I will say that I don't feel you've addressed my argument,
that "instance" is a proper description of an "instance" of a "prototype".
>> This comment adds nothing to the conversation. Your descriptions
>> were opaque.
>
> Not to everyone it seems. Doesn't that indicate that you had a
> problem?
I've not accepted a role in our relationship that would put the burden
of understanding on me. If I consider you a peer, then I consider
misunderstandings to be shared responsibilities. Considering you a peer
is part of the casual grace of the Internet, that we enter into
conversations as equals. Asking a question of someone on through the
Internet is not an admission of educational inferiority.
>> You were hammering home some point about what is or is not
>> confusing to other people, not speaking directly to inquiries.
>
> Oddly enough, that was the point of the discussion until you tried to
> turn it into a private tutoring session.
See above. I didn't receive any answers from you for my questions. Only
from another poster, who answered the one question I had.
>> This is truly helpful, to have direct questions answered. What you've
>> done, so far, has not been very helpful to me at all.
>
> In case you hadn't noticed, this is not a help desk. :)
I've not asked a help desk question. I've asked a question to expand my
understanding of JavaScript. To use the newsgroup as a help desk would
mean that I was asking a (likely) time sensitive question to an
implementation. I'm simply another USENET participant engaging in a
threaded conversation about the topic at hand. Asking questions is part
of communication.
>> You still have not
>> address the point I made in the other branch of the thread, that
>> "instance" is a valid description of an "instance" of a "prototype" in
>> JavaScript.
>
> I'm through repeating myself for your admitted lack of benefit. Best
> of luck!
You never repeated yourself and you never answered the question. You've
only taken apart sentences.
I wish you well as well.
David Mark
> David Mark wrote:
> > On Jul 23, 4:45 pm, Alan Gutierrez <a...@blogometer.com> wrote:
> >> David Mark wrote:
> >>> On Jul 23, 4:12 pm, Alan Gutierrez <a...@blogometer.com> wrote:
> >>>> John G Harris wrote:
> >>> [...]
> >>>>> If the object's constructor has had its prototype property changed and
> >>>>> the object is tested with a no longer suitable function object then
> >>>>> that's the programmer's problem.
> >>>> Thank you. Learn something new every day.>
> >>> You could have saved yourself a lot of time by carefully reading my
> >>> examples and thinking about what I was trying to illustrate with them.
> >> That would have saved time? I don't think so. This was lightening fast.
>
> > I thought it was pretty heavy myself. Granted you diluted the hell
> > out of it by the end. :)
>
> >> I asked a question and got an answer that clarified my understanding.
>
> > You already had the answers under your nose.
>
> >> This is how I learn. I ask pointed questions seeking pointed answers.
>
> > And you are constantly getting stuck.
>
> How would you know? I've only asked one question so far, and I've
> received one answer. There is no history of me being stuck on this
> newsgroup.
Considering that this is your first thread, you are off to a pretty
sticky start. :)
>
> >>> In other words, you should have heeded my previous warning(s) instead
> >>> of conflating them to ad hominems.
> >>> HTH
> >> No. It doesn't. I believe you are simply trying to assert yourself
> >> again.
>
> > You like talking about me, don't you?
>
> I'm kind of creeping into characterizing your half of this conversation,
> but otherwise, I'd say that you've been very quick to characterize me as
> a person.
I'd agree that you are kind of a creep. Be fair, a repetitive, self-
righteous blow-hard. That won't serve you well in this group. ;)
And if you aren't a person then the joke really is on me, isn't
it? :)
> I will say that I don't feel you've addressed my argument,
> that "instance" is a proper description of an "instance" of a "prototype".
We've been over that ad nauseam. For one, nobody refers to instances
as "of a prototype". The languages own instanceof operator makes a
comparison between a constructor and a constructed object. See how
confusing that can be?
>
> >> This comment adds nothing to the conversation. Your descriptions
> >> were opaque.
>
> > Not to everyone it seems. Doesn't that indicate that you had a
> > problem?
>
> I've not accepted a role in our relationship that would put the burden
> of understanding on me.
Ah, I see where you have gone off the path. We have no relationship.
> If I consider you a peer, then I consider
> misunderstandings to be shared responsibilities.
Neither are you my peer.
> Considering you a peer
> is part of the casual grace of the Internet, that we enter into
> conversations as equals.
But on this subject, that's clearly a false assumption. I'm telling
you that a new one of you blows in here every other week. It's always
the same story.
> Asking a question of someone on through the
> Internet is not an admission of educational inferiority.
Who said it was? But I put it to you that you are relatively ignorant
about JS and browser scripting. You'd do well to listen and learn for
a while and stop trying to lecture me on Usenet protocol.
>
> >> You were hammering home some point about what is or is not
> >> confusing to other people, not speaking directly to inquiries.
>
> > Oddly enough, that was the point of the discussion until you tried to
> > turn it into a private tutoring session.
>
> See above. I didn't receive any answers from you for my questions. Only
> from another poster, who answered the one question I had.
You are seeing what you want to see. My question is why you want to
see such things (perhaps you've formed some sort of knee-jerk opinion
of me?) In other words, I answered your question at least a half-
dozen times before the same answer (with a slightly different
explanation) was posted. Furthermore, I am under no obligation to
teach you anything. Again, this is a discussion group and not a help
desk.
>
> >> This is truly helpful, to have direct questions answered. What you've
> >> done, so far, has not been very helpful to me at all.
>
> > In case you hadn't noticed, this is not a help desk. :)
>
> I've not asked a help desk question. I've asked a question to expand my
> understanding of JavaScript.
And what is your definition of a "help desk" question? Rhetorical,
don't answer (please).
> To use the newsgroup as a help desk would
> mean that I was asking a (likely) time sensitive question to an
> implementation.
Dammit. You definitely seemed pressed for time on the question. Your
replies were relentless that it be spelled out for you immediately, to
the point where you started to complain about the bad service.
> I'm simply another USENET participant engaging in a
> threaded conversation about the topic at hand.
No, as I see it, you didn't seem interested in the topic at hand. You
veered off onto some quasi-related topic that, in turn, did not
interest me.
> Asking questions is part
> of communication.
Is it?
>
> >> You still have not
> >> address the point I made in the other branch of the thread, that
> >> "instance" is a valid description of an "instance" of a "prototype" in
> >> JavaScript.
>
> > I'm through repeating myself for your admitted lack of benefit. Best
> > of luck!
>
> You never repeated yourself and you never answered the question.
If that's your take, you didn't read my numerous posts to this thread
(several of which were replies to your posts). Your homework is to re-
read the entire thread from start to finish and to post an essay on
where you went wrong.
> You've
> only taken apart sentences.
I don't recall doing that. (?)
>
> I wish you well as well.
Take care. :)
Alan Gutierrez
> On Jul 23, 7:45 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>> David Mark wrote:
>>> On Jul 23, 4:45 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>>>> David Mark wrote:
>>>>> On Jul 23, 4:12 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>>>>>> John G Harris wrote:
>>>>> [...]
>>>>> In other words, you should have heeded my previous warning(s) instead
>>>>> of conflating them to ad hominems.
>>>>> HTH
>>>> No. It doesn't. I believe you are simply trying to assert yourself
>>>> again.
>>> You like talking about me, don't you?
>> I'm kind of creeping into characterizing your half of this conversation,
>> but otherwise, I'd say that you've been very quick to characterize me as
>> a person.
>
> I'd agree that you are kind of a creep. Be fair, a repetitive, self-
> righteous blow-hard. That won't serve you well in this group. ;)
Adding a smiley doesn't change the fact that you have just insulted me.
You have called me a creep. That is offensive and I take offense.
>> I will say that I don't feel you've addressed my argument,
>> that "instance" is a proper description of an "instance" of a "prototype".
>
> We've been over that ad nauseam. For one, nobody refers to instances
> as "of a prototype". The languages own instanceof operator makes a
> comparison between a constructor and a constructed object. See how
> confusing that can be?
Apparently, it is very confusing for you...
In v instanceof f (v must be an object and f a function object)
it tests whether the head of the prototype chain *currently* in
f.prototype is in the prototype chain of v.
Apparently, you have not known the answer to the question all this time
and you're now only able to answer it incorrectly.
>> If I consider you a peer, then I consider
>> misunderstandings to be shared responsibilities.
>
> Neither are you my peer.
Hard to imagine that I'm not your peer, in the sense that we probably
both have knowledge about software development. I'm here to exchange
knowledge, and to learn, and to discuss. I can't really see people on
USENET as anything but peers and fellow programmers. Again, it is a
causal grace that dominates the Internet, that we approach each other as
equals. Asking a question of a newsgroup does not put a person in a
position of being admonished. I am not inclined to accept admonishments
from strangers.
> But on this subject, that's clearly a false assumption. I'm telling
> you that a new one of you blows in here every other week. It's always
> the same story.
If the turnover of this newsgroup is that bad, you should really look at
what's gone off the tracks with the community. You'd hope that people
would come and stay. If they are coming and probably, like me, standing
their ground when they are condescended to, they are going to leave. It
is a shame if that is the case.
Truly, if it is the same story that someone engages with you until you
insult them, then don't you feel that this pattern begs some
self-observation?
>> Asking a question of someone on through the
>> Internet is not an admission of educational inferiority.
>
> Who said it was? But I put it to you that you are relatively ignorant
> about JS and browser scripting. You'd do well to listen and learn for
> a while and stop trying to lecture me on Usenet protocol.
I don't believe that listening to you would teach me very much, I'm
afraid. There is way to much noise in the signal. Maybe it's just me,
but I'm not really responding to well to your rather Socratic method of
conveying information. I much prefer direct answers to sincere
questions. The sort given by the other poster. I'm able to pocket that
information and move on.
>>>> You were hammering home some point about what is or is not
>>>> confusing to other people, not speaking directly to inquiries.
>>> Oddly enough, that was the point of the discussion until you tried to
>>> turn it into a private tutoring session.
>> See above. I didn't receive any answers from you for my questions. Only
>> from another poster, who answered the one question I had.
>
> You are seeing what you want to see. My question is why you want to
> see such things (perhaps you've formed some sort of knee-jerk opinion
> of me?) In other words, I answered your question at least a half-
> dozen times before the same answer (with a slightly different
> explanation) was posted. Furthermore, I am under no obligation to
> teach you anything. Again, this is a discussion group and not a help
> desk.
You're not teaching me anything. You're not able to answer simple
questions. Your whole line of reasoning has been that you've already
answer the question and that I'm supposed to comb over your writings and
extract it, but that is not how I want to spend my time.
I don't imagine that you're obliged to me in any way at all.
>> To use the newsgroup as a help desk would
>> mean that I was asking a (likely) time sensitive question to an
>> implementation.
>
> Dammit. You definitely seemed pressed for time on the question. Your
> replies were relentless that it be spelled out for you immediately, to
> the point where you started to complain about the bad service.
Never did I complain about bad service. I am not working on or in
JavaScript today. This is all a doodle.
>> I'm simply another USENET participant engaging in a
>> threaded conversation about the topic at hand.
>
> No, as I see it, you didn't seem interested in the topic at hand. You
> veered off onto some quasi-related topic that, in turn, did not
> interest me.
I've only been trying to pin down the meaning of "instance" and
"instanceof". At this point I'm only responding to your
mis-characterizations.
>>>> You still have not
>>>> address the point I made in the other branch of the thread, that
>>>> "instance" is a valid description of an "instance" of a "prototype" in
>>>> JavaScript.
>>> I'm through repeating myself for your admitted lack of benefit. Best
>>> of luck!
>> You never repeated yourself and you never answered the question.
>
> If that's your take, you didn't read my numerous posts to this thread
> (several of which were replies to your posts). Your homework is to re-
> read the entire thread from start to finish and to post an essay on
> where you went wrong.
That's my take. We're going to have to agree to disagree.
David Mark
So confusing that I wrote an in-depth analysis of the issue about
fifty posts back. :)
>
> In v instanceof f (v must be an object and f a function object)
> it tests whether the head of the prototype chain *currently* in
> f.prototype is in the prototype chain of v.
That was demonstrated by my earlier post.
>
> Apparently, you have not known the answer to the question all this time
> and you're now only able to answer it incorrectly.
That would seem impossible given the timeline, wouldn't it? I asked
you to re-read the thread from the start. :)
>
> >> If I consider you a peer, then I consider
> >> misunderstandings to be shared responsibilities.
>
> > Neither are you my peer.
>
> Hard to imagine that I'm not your peer, in the sense that we probably
> both have knowledge about software development. I'm here to exchange
> knowledge, and to learn, and to discuss. I can't really see people on
> USENET as anything but peers and fellow programmers.
You are speaking in a general sense. I was not as this is a very
specific discussion (and group).
> Again, it is a
> causal grace that dominates the Internet, that we approach each other as
> equals.
I didn't approach you. I just had to deal with dozens of rapid-fire
queries, each roughly the same. It's irritating.
> Asking a question of a newsgroup does not put a person in a
> position of being admonished. I am not inclined to accept admonishments
> from strangers.
Stick around. :)
>
> > But on this subject, that's clearly a false assumption. I'm telling
> > you that a new one of you blows in here every other week. It's always
> > the same story.
>
> If the turnover of this newsgroup is that bad, you should really look at
> what's gone off the tracks with the community.
There's no turnover. Most of the people I refer to end up sticking
around forever (for better or worse).
> You'd hope that people
> would come and stay.
They do.
> If they are coming and probably, like me, standing
> their ground when they are condescended to, they are going to leave.
You are imagining things again.
> It
> is a shame if that is the case.
Good thing it is not (well, depending on how you look at it).
>
> Truly, if it is the same story that someone engages with you until you
> insult them, then don't you feel that this pattern begs some
> self-observation?
You are telling a different story than I am. That seems to be a
recurring problem in this thread.
>
> >> Asking a question of someone on through the
> >> Internet is not an admission of educational inferiority.
>
> > Who said it was? But I put it to you that you are relatively ignorant
> > about JS and browser scripting. You'd do well to listen and learn for
> > a while and stop trying to lecture me on Usenet protocol.
>
> I don't believe that listening to you would teach me very much, I'm
> afraid.
That's what they all say; and yet, they keep asking me questions. Go
figure. :)
> There is way to much noise in the signal.
That too.
> Maybe it's just me,
> but I'm not really responding to well to your rather Socratic method of
> conveying information.
And I'm not really responding well to your neurotic method of asking
questions.
> I much prefer direct answers to sincere
> questions. The sort given by the other poster.
The other poster? Nobody has added anything new to this discussion in
about a hundred posts.
> I'm able to pocket that
> information and move on.
Please do. :)
>
> >>>> You were hammering home some point about what is or is not
> >>>> confusing to other people, not speaking directly to inquiries.
> >>> Oddly enough, that was the point of the discussion until you tried to
> >>> turn it into a private tutoring session.
> >> See above. I didn't receive any answers from you for my questions. Only
> >> from another poster, who answered the one question I had.
>
> > You are seeing what you want to see. My question is why you want to
> > see such things (perhaps you've formed some sort of knee-jerk opinion
> > of me?) In other words, I answered your question at least a half-
> > dozen times before the same answer (with a slightly different
> > explanation) was posted. Furthermore, I am under no obligation to
> > teach you anything. Again, this is a discussion group and not a help
> > desk.
>
> You're not teaching me anything. You're not able to answer simple
> questions. Your whole line of reasoning has been that you've already
> answer the question and that I'm supposed to comb over your writings and
> extract it, but that is not how I want to spend my time.
Again, this is not a help desk. And why should I repeat what has
already been posted? Because you are too lazy to go back and read
carefully?
>
> I don't imagine that you're obliged to me in any way at all.
Your words don't match your (many) actions.
>
> >> To use the newsgroup as a help desk would
> >> mean that I was asking a (likely) time sensitive question to an
> >> implementation.
>
> > Dammit. You definitely seemed pressed for time on the question. Your
> > replies were relentless that it be spelled out for you immediately, to
> > the point where you started to complain about the bad service.
>
> Never did I complain about bad service. I am not working on or in
> JavaScript today. This is all a doodle.
Yes, you got quite irritable when I refused to repeat myself
endlessly.
>
> >> I'm simply another USENET participant engaging in a
> >> threaded conversation about the topic at hand.
>
> > No, as I see it, you didn't seem interested in the topic at hand. You
> > veered off onto some quasi-related topic that, in turn, did not
> > interest me.
>
> I've only been trying to pin down the meaning of "instance" and
> "instanceof". At this point I'm only responding to your
> mis-characterizations.
LOL. I made no mis-characterizations. I explained the differences to
a tee at the very start of the thread. That's why I told you to go
back and re-read for comprehension.
>
> >>>> You still have not
> >>>> address the point I made in the other branch of the thread, that
> >>>> "instance" is a valid description of an "instance" of a "prototype" in
> >>>> JavaScript.
> >>> I'm through repeating myself for your admitted lack of benefit. Best
> >>> of luck!
> >> You never repeated yourself and you never answered the question.
>
> > If that's your take, you didn't read my numerous posts to this thread
> > (several of which were replies to your posts). Your homework is to re-
> > read the entire thread from start to finish and to post an essay on
> > where you went wrong.
>
> That's my take. We're going to have to agree to disagree.
Agreed! :)
Garrett Smith
> John G Harris wrote:
>> On Fri, 23 Jul 2010 at 11:53:30, in comp.lang.javascript, Alan Gutierrez
>> wrote:
>>
[snip informative explanation]
>
> Thank you. Learn something new every day.
>
Example:
function Person(){}
Person.prototype = {};
var a = new Person;
var isBefore = a instanceof Person
Person.prototype = {};
[isBefore, a instanceof Person]
Result:
[true, false]
(please don't feed the trolls).
--
Garrett
David Mark
> On 2010-07-23 01:12 PM, Alan Gutierrez wrote:
>
> > John G Harris wrote:
> >> On Fri, 23 Jul 2010 at 11:53:30, in comp.lang.javascript, Alan Gutierrez
> >> wrote:
>
> [snip informative explanation]
>
>
>
> > Thank you. Learn something new every day.
>
> Example:
>
> function Person(){}
> Person.prototype = {};
> var a = new Person;
Use the call operator. Thanks.
> var isBefore = a instanceof Person
> Person.prototype = {};
> [isBefore, a instanceof Person]
>
> Result:
> [true, false]
>
That's a virtually identical reworking of an example I had posted at
the very beginning of the thread. Somebody else posts it and you call
it "informative"? ISTM that you have popped in here more than a few
times to call my explanation(s) wrong, even going so far as to post a
ridiculous half-example that somewhat seemed (to beginners) to
demonstrate an opposite point (i.e. the instanceof operator is not
confusing). So make up your mind.
Alan Gutierrez
>> In v instanceof f (v must be an object and f a function object)
>> it tests whether the head of the prototype chain *currently* in
>> f.prototype is in the prototype chain of v.
>
> That was demonstrated by my earlier post.
You don't see how your definition differs from the correct definition?
>> That's my take. We're going to have to agree to disagree.
>
> Agreed!
I'm content with this outcome. I'm heartened by the exchange with two
other posters. I'm quite certain that we're not going to resolve
anything at this point. I will note that you owe me an apology for
calling me a creep and a blow-hard. I never resorted to calling you
names. I don't know you well enough to accept insults even accompanied
by emoticons, so you will have to address that if should we ever find
that we have to work together. Otherwise, to ingratiate myself to other
readers of this newsgroup, I will allow you to have the last word,
allowing anything more that you have to say, admonishments, homework
assignments, or insults to go un-addressed.
David Mark
You still don't get it. The *other* posters restated part of what I
had stated in my original answer (way back when). You know, the bit
you were so pleased with about the binding between the constructor's
prototype property and the constructed object (and the subsequent
examples demonstrating the fleeting nature of this binding and how the
instanceof operator could be fooled). Yeah, those. In other words,
you wasted a ton of time (including some of mine) for no reason, other
than perhaps laziness. Apology accepted. :)
Kenneth Tilton
> On Jul 23, 4:12 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>> John G Harris wrote:
>
> [...]
>
>>> If the object's constructor has had its prototype property changed and
>>> the object is tested with a no longer suitable function object then
>>> that's the programmer's problem.
>> Thank you. Learn something new every day.
>>
>
> You could have saved yourself a lot of time by carefully reading my
> examples and thinking about what I was trying to illustrate with them.
Sounds like you are a terrible communicator if all that is necessary. A
good communicator meets their audience half-way.
kt
--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
David Mark
> David Mark wrote:
> > On Jul 23, 4:12 pm, Alan Gutierrez <a...@blogometer.com> wrote:
> >> John G Harris wrote:
>
> > [...]
>
> >>> If the object's constructor has had its prototype property changed and
> >>> the object is tested with a no longer suitable function object then
> >>> that's the programmer's problem.
> >> Thank you. Learn something new every day.
>
> > You could have saved yourself a lot of time by carefully reading my
> > examples and thinking about what I was trying to illustrate with them.
>
> Sounds like you are a terrible communicator if all that is necessary. A
> good communicator meets their audience half-way.
>
In other words, you didn't read the preceding posts either.
Garrett Smith
>> On 2010-07-23 01:12 PM, Alan Gutierrez wrote:
>>
>>> John G Harris wrote:
>>>> On Fri, 23 Jul 2010 at 11:53:30, in comp.lang.javascript, Alan Gutierrez
>>>> wrote:
>>
>> [snip informative explanation]
>>
>>
>>
>>> Thank you. Learn something new every day.
>>
>> Example:
>>
>> function Person(){}
>> Person.prototype = {};
>> var a = new Person;
>
> Use the call operator. Thanks.
>
--
Garrett
David Mark
Oh brother. And, in your world, what do you call it?
John G Harris
wrote:
<snip>
>The languages own instanceof operator makes a
>comparison between a constructor and a constructed object. See how
>confusing that can be?
<snip>
Now you're in danger of causing confusion. Whether the function was
designed to be a constructor or not is irrelevant. Whether the function
was the one that actually constructed the object is irrelevant.
The only thing that matters is the value of the prototype property of
the function.
John
--
John Harris
David Mark
> On Fri, 23 Jul 2010 at 17:14:15, in comp.lang.javascript, David Mark
> wrote:
>
> <snip>>The languages own instanceof operator makes a
> >comparison between a constructor and a constructed object. See how
> >confusing that can be?
>
> <snip>
>
> Now you're in danger of causing confusion. Whether the function was
> designed to be a constructor or not is irrelevant.
That was certainly not my intent. But I am sure you know what I
meant.
> Whether the function
> was the one that actually constructed the object is irrelevant.
Yes, which is highly confusing with regard to the instanceof
operator. That's been my point from the start.
>
> The only thing that matters is the value of the prototype property of
> the function.
>
Yes, as explained and demonstrated in my original answer.
John G Harris
wrote:
>On Jul 24, 11:15 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>> On Fri, 23 Jul 2010 at 17:14:15, in comp.lang.javascript, David Mark
>> wrote:
>>
>> <snip>>The languages own instanceof operator makes a
>> >comparison between a constructor and a constructed object. See how
>> >confusing that can be?
>>
>> <snip>
>>
>> Now you're in danger of causing confusion. Whether the function was
>> designed to be a constructor or not is irrelevant.
>
>That was certainly not my intent. But I am sure you know what I
>meant.
It's noticeable that the outline description of [[HasInstance]] (sec
8.6.2) in the ES3 standard has the same confusion, and that the
rewording in the ES5 standard is a fudge that is no better.
John
--
John Harris
David Mark
Yes. The specs are an invaluable (and slightly flawed) resource, but
will definitely confuse absolute beginners. That's why many opt for
the comfortable sales pitch of jQuery or the like (then they can
ostensibly skip the "hard" stuff and straight to the head of the
class).
Garrett Smith
If you weren't a perpetual jerk or if you had at least asked a smart
question non-insulting manner, I'd probably try and guess as to what I
think you might have meant.
But instead, you posted -- and it was pointed out -- your own made-up
terminology to make a rather pointless comment. You followed that up
with a loaded question[1] about "my world" (how ironic). And we just
covered "my world" a day or two prior...
Found it. You wrote:
| In your own fantasy world I presume. In reality, your response
| demonstrated a stunning lack of comprehension.
And my reply:
| I see you've snipped what was written and replied flippantly. It
| reflects typical behavior of David Mark.
And again, another typical DM reply. After a brief hiatus, I see the NG
littered with more of the same from you.
Ironically, you missed the actual problem in the code I posted. The
problem is that my code omitted a semicolon. Two, actually. What is more
ironic is that in the code guidelines document[2] goes to great length
to explain the problem and in so doing, explains the lexical grammar
production for what might likely be your "call operator" thing.
The production is called `Arguments`. Then again, you've not explained
yourself; so about the best I can do is guess as to what you wanted to ask.
See also:
[1] <http://catb.org/esr/faqs/smart-questions.html>
[2] <http://jibbering.com/faq/notes/code-guidelines/>
--
Garrett
David Mark
> On 2010-07-23 11:10 PM, David Mark wrote:
>
>
>
>
>
> > On Jul 24, 1:52 am, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
> >> On 2010-07-23 08:18 PM, David Mark wrote:
>
> >>> On Jul 23, 11:07 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
> >>>> On 2010-07-23 01:12 PM, Alan Gutierrez wrote:
>
> >>>>> John G Harris wrote:
> >>>>>> On Fri, 23 Jul 2010 at 11:53:30, in comp.lang.javascript, Alan Gutierrez
> >>>>>> wrote:
>
> >>>> [snip informative explanation]
>
> >>>>> Thank you. Learn something new every day.
>
> >>>> Example:
>
> >>>> function Person(){}
> >>>> Person.prototype = {};
> >>>> var a = new Person;
>
> >>> Use the call operator. Thanks.
>
> >> There isn't a call operator in ECMAScript.
>
> > Oh brother. And, in your world, what do you call it?
>
> If you weren't a perpetual jerk or if you had at least asked a smart
> question non-insulting manner, I'd probably try and guess as to what I
> think you might have meant.
If you weren't such a perpetual loser, perhaps you wouldn't have to be
corrected so often.
>
> But instead, you posted -- and it was pointed out -- your own made-up
> terminology to make a rather pointless comment.
I did no such thing. Your nonsensical reply demonstrates nothing but
your own ignorance.
> You followed that up
> with a loaded question[1] about "my world" (how ironic).
Not ironic at all given your history.
> And we just
> covered "my world" a day or two prior...
>
> Found it. You wrote:
Oh here we go...
>
> | In your own fantasy world I presume. In reality, your response
> | demonstrated a stunning lack of comprehension.
No context, but it sounds like a reasonable response to some
nonsensical comment of yours.
>
> And my reply:
> | I see you've snipped what was written and replied flippantly. It
> | reflects typical behavior of David Mark.
And that was the proverbial pot calling the kettle black (as evidenced
here once again).
>
> And again, another typical DM reply. After a brief hiatus, I see the NG
> littered with more of the same from you.
If you have something to say about my "litter" then say it.
>
> Ironically, you missed the actual problem in the code I posted.
What code?
> The
> problem is that my code omitted a semicolon.
So?
> Two, actually. What is more
> ironic is that in the code guidelines document[2] goes to great length
> to explain the problem and in so doing, explains the lexical grammar
> production for what might likely be your "call operator" thing.
You are such a numb-skull.
>
> The production is called `Arguments`. Then again, you've not explained
> yourself; so about the best I can do is guess as to what you wanted to ask.
>
It was a rhetorical question.
And so, instead of calling the call operator what it is, you refer to
it as "Arguments". I'm sure that won't cause any confusion.
Garrett Smith
Do you have a special version of ECMA-262 that defines a call operator,
or did you just not RTFM?
>>
>> Ironically, you missed the actual problem in the code I posted.
>
> What code?
>
You made a comment on code I wrote just few posts back "Please use the
call operator thanks".
>> The
>> problem is that my code omitted a semicolon.
>
> So?
>
So you missed the problem and made up some nonsense. Ironically, the
document that explains the actual problem sheds light on your irrelevant
nonsense.
>> Two, actually. What is more
>> ironic is that in the code guidelines document[2] goes to great length
>> to explain the problem and in so doing, explains the lexical grammar
>> production for what might likely be your "call operator" thing.
>
> You are such a numb-skull.
>
No, that's you.
>>
>> The production is called `Arguments`. Then again, you've not explained
>> yourself; so about the best I can do is guess as to what you wanted to ask.
>>
>
> It was a rhetorical question.
>
That's not how I saw it.
> And so, instead of calling the call operator what it is, you refer to
> it as "Arguments". I'm sure that won't cause any confusion.
I refer to `Arguments` as `Arguments`; not as "call operator" -- that's
your made-up terminology. The production for `Arguments` is clearly
defined in ECMA-262 under 11.2 Left-Hand-Side Expressions.
Anyone can see quickly that production is defined under "Left-Hand-Side
Expressions" in ECMA-262. For convenience:
<http://bclary.com/2004/11/07/#a-11.2>
| Arguments:
| ()
| ( ArgumentList )
And so continuing to call `Arguments` the "call operator" shouldn't be
fooling anybody at this point. It is somewhat revealing to the facade
that there actually is such a thing (there isn't, go RTFM) and that you
know what you're talking about (pretty obvious that you don't).
If there were such a thing, then the pertinent part of the spec could
have been cited and the discussion of the alleged "call operator" would
have been quickly resolved. However anyone can RTFM see that you're full
of shit.
The reason it is misleading to call `Arguments` a "call operator" is
that the production `Arguments` is used in NewExpression and
CallExpression, respectively, as:
new MemberExpression Arguments
and
MemberExpression Arguments
- and so it wouldn't make sense to refer to something used for `new` as
a "call" operator; the example code I posted was using `new`, which
calls `[[Construct]]`, not [[Call]].
Being faced with a fact with overwhelming evidence is too uncomfortable
for you to accept and so you reject reality and use name calling instead.
Now here's a rhetorical question: What does it say about you when you
hurl insults while continuing to use your own made-up terminology, even
after it being pointed out to you?
You could have stopped with "unreliable source of information regarding
ECMAScript," but you seem intent on destroying your reputation with
obvious falsehoods.
--
Garrett
David Mark
I know you are but what am I? :)
>
>
>
> >> The production is called `Arguments`. Then again, you've not explained
> >> yourself; so about the best I can do is guess as to what you wanted to ask.
>
> > It was a rhetorical question.
>
> That's not how I saw it.
Your reading comprehension has never been in question (it seems to be
non-existent).
>
> > And so, instead of calling the call operator what it is, you refer to
> > it as "Arguments". I'm sure that won't cause any confusion.
>
> I refer to `Arguments` as `Arguments`; not as "call operator" -- that's
> your made-up terminology.
It is certainly not made-up terminology.
> The production for `Arguments` is clearly
> defined in ECMA-262 under 11.2 Left-Hand-Side Expressions.
There's no water in Coca-Cola. It's called H20. :)
Again, the specs are aimed at implementors. There is a lot of talk
about productions as implementors must write code that parses the
language. Much of the language in the specs is out of place in
discussions among programmers. In other words, you have a serious
communication problem.
>
> Anyone can see quickly that production is defined under "Left-Hand-Side
> Expressions" in ECMA-262. For convenience:
> <http://bclary.com/2004/11/07/#a-11.2>
>
> | Arguments:
> | ()
> | ( ArgumentList )
See above. Remember when you wanted to replace every occurrence of
"Javascript" in the FAQ to "ECMAScript"? That was the mother of all
such related communication breakdowns. Learn from your mistakes.
>
> And so continuing to call `Arguments` the "call operator" shouldn't be
> fooling anybody at this point.
You come off as a petulant child.
> It is somewhat revealing to the facade
> that there actually is such a thing (there isn't, go RTFM) and that you
> know what you're talking about (pretty obvious that you don't).
No, it's pretty obvious to anyone who reads this group that you are an
obsessive, beetle-browed nitwit with serious communication issues.
>
> If there were such a thing, then the pertinent part of the spec could
> have been cited and the discussion of the alleged "call operator" would
> have been quickly resolved. However anyone can RTFM see that you're full
> of shit.
See above. You haven't got a leg to stand on (except in your own
confused head).
>
> The reason it is misleading to call `Arguments` a "call operator" is
> that the production `Arguments` is used in NewExpression and
> CallExpression, respectively, as:
>
> new MemberExpression Arguments
> and
> MemberExpression Arguments
See above. Quoting the specs over and over is just underscoring my
points.
>
> - and so it wouldn't make sense to refer to something used for `new` as
> a "call" operator; the example code I posted was using `new`, which
> calls `[[Construct]]`, not [[Call]].
Again.
>
> Being faced with a fact with overwhelming evidence is too uncomfortable
> for you to accept and so you reject reality and use name calling instead.
Nope. That's another one of your irritating little habits. You
resort to name-calling and then whine when it is reciprocated.
>
> Now here's a rhetorical question: What does it say about you when you
> hurl insults while continuing to use your own made-up terminology, even
> after it being pointed out to you?
Your delusions say nothing about me (except perhaps to you).
>
> You could have stopped with "unreliable source of information regarding
> ECMAScript," but you seem intent on destroying your reputation with
> obvious falsehoods.
You seem intent on posting childish OT nonsense. For years you
haven't had a reputation as anything but a loon and amnesiac, who
misquotes, misconstrues, misunderstands and ultimately makes up
stories to deflect attention from his own ineptitude. In that regard,
your place in history is secure.
David Mark
I suppose I better head off el nitwit by pointing out my typo. Can
you spot it?
Garrett Smith
> On Aug 8, 1:52 am, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>> On 2010-08-07 09:13 PM, David Mark wrote:
>>
>>
>>
>>
>>
>>> On Aug 6, 10:26 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>>> On 2010-07-23 11:10 PM, David Mark wrote:
>>
>>>>> On Jul 24, 1:52 am, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>>>>> On 2010-07-23 08:18 PM, David Mark wrote:
>>
>>>>>>> On Jul 23, 11:07 pm, Garrett Smith<dhtmlkitc...@gmail.com> wrote:
>>>>>>>> On 2010-07-23 01:12 PM, Alan Gutierrez wrote:
>>
>>>>>>>>> John G Harris wrote:
>>>>>>>>>> On Fri, 23 Jul 2010 at 11:53:30, in comp.lang.javascript, Alan Gutierrez
>>>>>>>>>> wrote:
>>
>>>>>>>> [snip informative explanation]
>>
>>>>>>>>> Thank you. Learn something new every day.
>>
>>>>>>>> Example:
>>
>>>>>>>> function Person(){}
>>>>>>>> Person.prototype = {};
>>>>>>>> var a = new Person;
>>
>>>>>>> Use the call operator. Thanks.
>>
>>>>>> There isn't a call operator in ECMAScript.
>>
>>>>> Oh brother. And, in your world, what do you call it?
>>
Part of the misthinking that went into calling `Arguments` a "call
operator" is the believe that `Arguments` is an operator -- possibly
some sort of unary operator, like the delete, void, typeof, any postfix
or prefix operators, or any of the logical operators. It isn't.
Parenthesis is either `Arguments` or as Grouping Operator, depending on
the context in which it appears. When parenthesis appear to the right of
a MemeberExpression, then a CallExpression is formed. This makes
Arguments look like it is being used as an operator and it does act like
one here.
However, when parenthesis appears to the right of a NewExpression, then
it is used to pass values to the constructor function being called. The
`Arguments` doesn't cause the function to be called. In contrast, it is
the new Operator that causes the function to be called.
A related thread that explains it (for those who are not completely
incorrigable):
<http://groups.google.vu/group/comp.lang.javascript/browse_thread/thread/defa46670afd31b7>
[ranting]
>
>>
>> You could have stopped with "unreliable source of information regarding
>> ECMAScript," but you seem intent on destroying your reputation with
>> obvious falsehoods.
>
> You seem intent on posting childish OT nonsense. For years you
> haven't had a reputation as anything but a loon and amnesiac, who
> misquotes, misconstrues, misunderstands and ultimately makes up
> stories to deflect attention from his own ineptitude. In that regard,
> your place in history is secure.
Uh-huh. Seems you agree with me about you being a jerk.
--
Garrett
David Mark
It is well-established that the paranthesis (or call operator as it is
commonly known) is optional when using the - new - operator. Leaving
it off is bad form though (as I told you). Your subsequent,
irrelevant rant about what the specs call it is typical.
>
> A related thread that explains it (for those who are not completely
> incorrigable):
> <http://groups.google.vu/group/comp.lang.javascript/browse_thread/thre...>
Whatever. Call me incorrigible, but I don't follow your links.
>
> [ranting]
>
>
>
> >> You could have stopped with "unreliable source of information regarding
> >> ECMAScript," but you seem intent on destroying your reputation with
> >> obvious falsehoods.
>
> > You seem intent on posting childish OT nonsense. For years you
> > haven't had a reputation as anything but a loon and amnesiac, who
> > misquotes, misconstrues, misunderstands and ultimately makes up
> > stories to deflect attention from his own ineptitude. In that regard,
> > your place in history is secure.
>
> Uh-huh. Seems you agree with me about you being a jerk.
Reading comprehension problem flaring up again? :)
John G Harris
wrote:
<snip>
>It is well-established that
So well established that it got written into ECMA 262 v2, but of course
programmers wouldn't read that.
>the paranthesis (or call operator as it is
>commonly known)
But not commonly known as such round here.
C++ has operator(), used to attach a [[Call]] interface to user-defined
objects, but that's not needed in javascript.
>is optional when using the - new - operator. Leaving
>it off is bad form though (as I told you).
<snip>
new Date is to be expected in a scripting language aimed at people
who don't like semicolons.
John
--
John Harris