John G Harris wrote:
Richard Cornford writes>
<snip>
>>There are no classes. Javascript only has one object type;
the dynamic native ECMAScript object. All apparent
distinctions between objects follow from augmentations of
the native ECMAScript object, but no modification renders
that object unmodifiable.
<snip>
I think you go too far when you say this so emphatically.
How emphatic am I being when I have already said that the concept of
'class' is a useful tool for a programmer to apply to javascript code
design and am only insisting that the programmer appreciate that the
'class' concept is not inherent in the language (which it certainly is
not) but is something imposed by them on the design?
The word "class" is too useful to throw away,
It is, but it should be applied to the right thing. In javascript the
concept of 'class' is imposed from outside, and only applicable to a
combination of constructs _and_ the way in which they are _used_.
and it's a word that has been in
use since long before OO languages appeared.
Let us just stick the OO interpretation of the word. If it is to be
relevant to javascript that is the meaning that applies.
How else do you talk about all the objects created by
the Date constructor? How else do you talk about all
the objects that share the same prototype chain?
Sharing a prototype chain and/or being an instance resulting from a call
to the Date constructor are insufficient in themselves to determine or
exclude the appropriateness of the 'class' concept.
Consider a parallel with Java, where you want to create a subclass of
Date that implement a particular interface that is not currently
implemented by Date, and in addition you want a number of other classes
to implement that same interface. In javascript you might choose to do
that with an object augmenting function. It takes an instance of the
original object (a Date object in this instance), adds methods and
properties to that object, and returns it. This same function can then be
used to add the same interface to any number of other 'classes', and the
result is conceptually a sub-class that implements an interface in
addition to whatever methods/properties the original had.
Now this sub-class (if applied to a Date instance) is also the product of
the Date constructor, and shares its prototype with all instances that
are products of the Date constructor, but it should not be considered as
being of the same class as an instance of Date (it should be considered a
sub-class of Date).
The class - sub-class relationship suitably parallels similar concepts in
Java (for example) but they are the result of how the javascript has been
written and used, not an inherent characteristic of objects being
employed.
What javascript doesn't have is "class definitions".
In Java, C++, etc, the class definition tells the
compiler what data and methods an object has. These
can't be altered by the programmer when the program
runs. In javascript there are no class definitions and
the javascript engine does nothing to stop you changing
objects after construction, whether this gives you
something very clever or just a terrible mess. On the
other hand, it doesn't force you to change them if you
don't want to.
It is partly the fact that it would be unusual to be modifying objects
once some sort of concept of being of a particular 'class' has been
applied to them that makes employing the concepts in the design
appropriate and useful.
It's right to be suspicious when the word "class" is used
by people coming from a Java or C# background, but wrong
to condemn the word outright.
And I have never condemned it outright, but I don't think people will
learn javascript as a language by fixating on 'classes' as they only come
into the picture at the design stage, where the design stage is better
executed with a good foundation in the real language being used.
Richard.
