JavaScript for grown-ups

[Wm.M.Thompson]

For a computer programmer JavaScript is not difficult. It is pretty
easy to look at some code for the first time and figure out what is
going on.

This is especially true if you have gratuated from an old-fashioned
top-down programmer to an object oriented computer programmer. I mean,
most Javascript has a look where things are sectioned off into
functions.

This is pretty much true until one gets into DHTML and a very cool
open-source thingy called DYNAPI that is all open source and is all
javascript. With DHTML (aka Dynamic HTML) you can do a lot of
interesting things which, when run on an IE browser, looks a lot like
Flash: http://www.gelsana.com/examples/dynapi.fx.fader.html

So naturally I want to experiment with this and figure out how do
modify the examples to this.

The javascript (.js) file looks like this.
http://www.gelsana.com/Flash2.html

Some of it is easy to understand but some of it looks like object
oriented programming.

Does anyone know how all this works or where I can go to find out how
it works?

 

[Wm.M.Thompson]

I understand that javascript can use functions as objects or classes.
But how do I learn how this all works together?
For instance, in the copy of the DynAPI javascrpt file you can see this
bit of code

function DynObject() {
this.id = "DynObject"+DynObject._c++;
DynObject.all[this.id] = this;
};

Where is .id defined? Is it an element of the DynObject class that is
predefined with all javascript classes? Is the same true for the
element .all as well?

Following this object declaration (if that is what it is) there is this

line of code:

var p = DynObject.prototype;

Where is .prototype defined? Is it also a predefined element?
How is it used?

 

[Richard Cornford]

I understand that javascript can use functions as objects

In javascript functions are objects, but that does not seem to be what
you are referring to.

or classes.

There are no classes in javascript (or there is only one class,
depending on how you look at it). When the concept of classes it used
in javascript authoring it is a concept applied from outside, when it
is useful to do so and only to constructs that satisfy 'class'.

But how do I learn how this all works together?

Learning javascript?

For instance, in the copy of the DynAPI javascrpt file you can see this
bit of code

[/QUOTE]

What is this "[code]" stuff about? Are you using a dubious web-based
interface to post to a plain-text newsgroup?
[QUOTE]
function DynObject() {
this.id = "DynObject"+DynObject._c++;
DynObject.all[this.id] = this;
};

Where is .id defined?

Right there in the code. When an assignment is made to a named property
of an object that property is created on the object if it does not
already exist, and the value assigned to it.

Is it an element of the DynObject class that is
predefined with all javascript classes?

There are no classes in javascript. Pre-defined properties are
inherited through prototypes.

Is the same true for the
element .all as well?

The - all - property is a property of the function object, and will be
assigned elsewhere in the code.

Following this object declaration (if that is what it is) there is this
line of code:

var p = DynObject.prototype;

Where is .prototype defined?

All function objects have - prototype - properties, that refer to an
object created and assigned during the creation of the function object
(during 'variable instantiation' for a function declaration and during
the evaluation of function expressions) (or at least they refer to that
object if no other object is assigned to the property). When a function
is used as a constructor the value of its - prototype - property is
transferred to the created object's internal [[Prototype]] property and
then used as the root of the prototype chain when property accessors
are resolved against that object.

Is it also a predefined element?

The term "element" is usually used to refer to DOM Elements when
talking about javascript (because of its primary use in web browsers).
It would be confusing to apply the term to the properties of objects in
addition.

How is it used?

Properties on the - prototype - of a function at the time of creating a
new object by using the function as a constructor are inherited by the
newly created object. That is prototype based inheritance (as opposed
to class-based inheritance which javascript cannot have as it has no
classes).

Richard.

 

[petermichaux]

Richard Cornford wrote:

There are no classes in javascript (or there is only one class,
depending on how you look at it). When the concept of classes it used
in javascript authoring it is a concept applied from outside, when it
is useful to do so and only to constructs that satisfy 'class'.

There are no classes in javascript (or there is only one class,
depending on how you look at it). When the concept of classes it used
in javascript authoring it is a concept applied from outside, when it
is useful to do so and only to constructs that satisfy 'class'.

I know that there isn't a keyword "class" in JavaScript yet, but why
say there are no classes?

function Foo(){}

var a = new Foo();
var b = new Foo();

Are "a" and "b" not in the same class (aka group, species, kind) of
objects in my script? Where does the damage come from calling Foo the
constructor for a class of objects?

Peter

 

[Richard Cornford]

I know that there isn't a keyword "class" in JavaScript
yet, but why say there are no classes?

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.

function Foo(){}

var a = new Foo();
var b = new Foo();

Are "a" and "b" not in the same class (aka group, species,
kind) of objects in my script?

That is a runtime state, both can be modified in a way that would make
thinning of them as the same 'class' impossible. It can be convenient to
think of objects that have undergone like-modifications, are not then
going to undergo further modification that would destroy their like-ness
and are only going to be used in a particular way, as being of the same
'class', but thinking of them as being of the same distinct 'class' does
not make it so.

(And that is a set of conditions that can apply to any non-primitive
value and the modifications that impose like-ness may be applied in any
of many ways.)

Where does the damage come from calling Foo the
constructor for a class of objects?

It would promote thinking of javascript as a language that is other than
the language that it is. There are always consequences of ding that,
mostly disappointed expectations (such as people expecting the - this -
value to behave as it would in class-based languages, when in a dynamic
language - this - has to be determined at runtime, in the context of its
use).

When the programmer appreciates that any concept of 'class' employed in
designing scripts is applied by the programmer to how the language is
being used, and is not something inherent in the language, they can apply
the concept to any construct/use that satisfies it. While fixating on
constructor/prototype combinations (or any formalised inheritance scheme)
as in some way defining 'classes' will be restricting, both in what can
be achieved and how it can be conceived.

Class-based languages are very far from being dynamic, but being dynamic
is what makes javascript so good for browser scripting.

Richard.

 

[John G Harris]

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. The word
"class" is too useful to throw away, and it's a word that has been in
use since long before OO languages appeared. 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?

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

John

 

[Richard Cornford]

Richard Cornford writes>


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

 

[John G Harris]

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?


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

<snip>

This is also what I am saying. If instead of writing
"There are no classes."
you had qualified it just a little, for instance by saying
"There are no declared classes.",
then I wouldn't have commented on it.

John