Class or Type?

[Robert Mark Bram]

Hi All!

Instead of calling an object definition a class in JavaScript, should we say
that it is a type or definition or something like this?

So I might say "The object type is defined by its constructor."

Thanks for any advice!

Rob
:)

--
Robert Mark Bram
Doctor of Philosophy Student
School of Network Computing
Monash University, Frankston, Australia
Email: robert.bram@you rshoesinfotech. monash.edu.au
Remove your shoes to reply

[George M Jempty]

Re: Class or Type?

Robert Mark Bram wrote:[color=blue]
> Hi All!
>
> Instead of calling an object definition a class in JavaScript, should we say
> that it is a type or definition or something like this?
>
> So I might say "The object type is defined by its constructor."
>
> Thanks for any advice![/color]

I think whatever you need to make your decision is on pp. 3-4 of the
EcmaScript standard, available for download at:

http://www.ecma-international.org/publications/standards/ECMA-262.HTM

Note, if you download the standard in Adobe format, this would be pp.
15-16 of the PDF.

G

[Richard Cornford]

Re: Class or Type?

"Robert Mark Bram" <robert.bram@yo urshoesinfotech .monash.edu.au> wrote
in message news:3f580404$0 $4186$afc38c87@ news.optusnet.c om.au...[color=blue]
>Instead of calling an object definition a class in
>JavaScript, should we say that it is a type or definition
>or something like this?[/color]
[color=blue]
>So I might say "The object type is defined by its constructor."[/color]

Terminology is all about being understood. You can call anything by any
name you like but if you stray too far from excepted definitions and
meanings you may as well keep quiet. But understanding goes both ways
and the person on the receiving end has to be willing to engage in the
process in order to understand what is being said.

I don't have a big problem with using the term "class" to describe a
particular aggregation of JavaScript constructs that go towards
determining the nature of an instantiated JavaScript object (The
constructor, any associated custom prototype, function definitions
assigned to object properties or prototype members, etc.).

The term is reasonably questionable because (at minimum) unlike
class-based languages the code that defines an object is open to
modification at any point so one object created with a constructor can
be very different from another object created with the same constructor
at some subsequent point in terms of its structure and behaviour (and
all object instances are open to independent modification).

That means you would have to say "The object "type" is defined by its
constructor, prototype, etc, etc, at the moment it was constructed plus
the influence of any relevant modifications." . Which makes "type" or
"class" seem like fairly pointless concepts to attempt to apply.

In reality, though that wonderful mutability of JavaScript objects opens
up some interesting possibilities (particularly in terms of conception
related to OO programming in JavaScript), it is not something that you
will want to do in the normal course of events. Usually you will write
your object code and instantiate your objects and the one thing that you
would not then do is set about modifying the code structure that would
constitute the "class" while the script was executing.

So, if the code that defines an object is constant you can practically
talk of that object having a "type" or belonging to a "class". It might
not be the "correct" description of the situation but it is terminology
that is understood as relating to a concept that is pertinent to the
code being described. The people who understand class-based languages
will grasp the concept and the people who understand JavaScript (ECMA)
script will know the discrepancy but they will also understand the
concept. And if you want to author objects that change behaviour as a
script executes you will have to find some different terminology to
explain the concept to other people.

This problem extends to other bits of terminology that are borrowed from
class-based languages such as "private" and "private static" members.
Neither exist in JavaScript, but that wonderful flexibility means that
JavaScript can emulate both (there doesn’t appear to be much that
JavaScript can't emulate, you just have to work out how). So once you
have written an object that implements an emulation of a "private"
instance member do you describe it as "a function local variable
preserved in a closure formed by assigning an inner function to a public
object member during the execution of the constructor" and be
technically correct in terms of the mechanism, or do you short-cut to
"private instance member" and get the concept across? I would let the
context decide that for me.

I am going to continue using terminology from class-based languages to
describe concepts implemented in JavaScript if I think that those terms
are applicable to the code that I am describing. If it is useful to
describe a particular code structure as a "class" then that is what I
will call it.

I am willing to listen to (and possibly adopt) suggestions for
alternative terminology but I don’t see "type" as sufficiently different
in concept from "class" to make it applicable to a larger (or different)
sub-set of JavaScript objects/structures.

Richard.