I have trouble seeing that
Eventually you will have to. Though the exact wording of my statement
may be disputed. It would be as true to say that javascript only has
one
class; the native ECMAScript object. But where there is only one
'class'
there is no real distinction between classes and so it is reasonable
to
say that were there is no distinction between classes there are no
classes.
The native ECMAScript object is amenable to (runtime or pre-applied)
dynamic modification/augmentation, and some notion of object
instances
being of different types or classes follows from the
modifications/augmentations that are applied to different objects
having
a sufficient like-ness (in terms of their internal and external
(public)
members).
This does not mean that javascript is not programmed with the concept
of
'class' being fundamental to those programs, it very often is. But
the
concept of 'class' does not originate in the language, but rather it
is
an addition that follows from the way the language is (or may be)
used.
I found that a bit hard to understand. The way a function
is called?
Yes, the - this - value is determined by the way in which a function
is
called, at the moment of calling it. When you are in control of how a
function is to be called you are in control of the - this - value
(assuming you know the rules).
In javascript functions are objects (specially augmented instances of
the native ECMAScript object) with individual identity, but the same
function could be used as a method of many objects (even many objects
implementing the concept of being instances of different (and
unrelated)
'classes') so there cannot be a fixed relationship between a function
and another object instance in the language.
But mostly that does not matter because in the normal course of
events
you will be calling functions that are operating in the role of
methods
of objects as methods of object instances (using dot an bracket
notation
property accessor) and so application of the rules that set the - this
-
value will set the - this - value to a reference to the object
instance
in question.
I was thinking of that the reference to the object was defined in the
sendRequest-scope.
That was merely for testing - to keep the object away from the
garbage-
collector. I guess the object lives on somehow anyway?
While an XML HTTP request is in progress the browser must keep some
sort
of reference to that object so that it can find the object to handle
the
response when it arrives. So we can probably assume that if the
javascript code does not hang on to any references to that object it
will still not be garbage collected until after the response has been
handled.
*snip*
This one's new to me.
That is a pity as it is the most absolutely basic and standard
approach
to implementing the concept of 'class' in javascript (that is,
defining
the 'like-ness' of a set of object instances such that the resulting
objects may be regarded (by the programmer) as being of the same
'class'). And it is also most efficient approach that can be taken.
It
is an approach that should never be deviated from by a programmer
until/unless they are in a position to clearly state why they are
using
any of the many possible alternatives.
So you should never have been shown an example of your approach above
until after you were shown an example of the way I have it above, and
any later example should have stated its advantages (and in the case
of
the code above there are no advantages to be stated).
However I have taken a little peek at the
prototype-keyword in the context of inheritence.
Thanks for the tip.
It is a bit more than a tip. It brings into question whatever source
you
have been using to learn javascript so far. (Though given that
javascript books tend to range from the poor to the actively harmful,
and that most people start off with books, that may not have been
necessary.)
