FAQ suggestion: Does JavaScript have classes and instances?

4 views
Skip to first unread message

Jonathan Fine

unread,
Jul 29, 2009, 5:36:43 PM7/29/09
to
Hi

I thought this might be a good question for the FAQ.
http://www.jibbering.com/faq/

--
Jonathan

Garrett Smith

unread,
Jul 29, 2009, 5:53:54 PM7/29/09
to
Jonathan Fine wrote:
> Hi
>
> I thought this might be a good question for the FAQ.


I think you want to propose a question about about objects instantiation.

<nitpick>
The message does not clearly indicate that, though the subject does.

http://www.jibbering.com/faq/#ask

| # Use the Subject: line to show the type of problem you have but
| include the question in the body as well.
</nitpick>

Did you see my reply to:
"Re: inheritance issue, seems to be sharing data incorrectly"

or did my response not answer that, or did you feel a new thread was
best or ?

Garrett

--
comp.lang.javascript FAQ: http://jibbering.com/faq/

Richard Cornford

unread,
Jul 29, 2009, 7:25:42 PM7/29/09
to
Jonathan Fine wrote:
> Hi
>
> I thought this might be a good question for the FAQ.
<snip>

Where is the question, or are you referring to the subject header of
your post?

What you are doing here appears to be asking someone else (presumably
anyone else) to devote their (free) time to writing a (more or less)
complete summery of a complex subject, sufficiently concisely for
inclusions in the FAQ. That is quite a lot to ask (and far too much to
demand) of someone else.

Existence is filled with things that one might wish were different to
the way they are. Of the things that can be changed, they are more
likely to be changed by positive action, as opposed to merely
complaining. In this context, the most positive action you could take
would be to propose a full draft text for the addition to the FAQ that
you would like to see.

Richard.

Jonathan Fine

unread,
Jul 30, 2009, 2:26:30 AM7/30/09
to
Richard Cornford wrote:
> Jonathan Fine wrote:
>> Hi
>>
>> I thought this might be a good question for the FAQ.
> <snip>
>
> Where is the question, or are you referring to the subject header of
> your post?

The subject.

> What you are doing here appears to be asking someone else (presumably
> anyone else) to devote their (free) time to writing a (more or less)
> complete summery of a complex subject, sufficiently concisely for
> inclusions in the FAQ. That is quite a lot to ask (and far too much to
> demand) of someone else.

It others agree that it's a good question for the FAQ, then it's
something I'm willing to contribute to.

> Existence is filled with things that one might wish were different to
> the way they are. Of the things that can be changed, they are more
> likely to be changed by positive action, as opposed to merely
> complaining. In this context, the most positive action you could take
> would be to propose a full draft text for the addition to the FAQ that
> you would like to see.

I was not complaining. I made a positive suggestion. Richard, do you
like the idea?

--
Jonathan

Jonathan Fine

unread,
Jul 30, 2009, 2:40:35 AM7/30/09
to
Garrett Smith wrote:
> Jonathan Fine wrote:

>> I thought this might be a good question for the FAQ.
>
> I think you want to propose a question about about objects instantiation.

[snip]

> Did you see my reply to:
> "Re: inheritance issue, seems to be sharing data incorrectly"
>
> or did my response not answer that, or did you feel a new thread was
> best or ?


Yes I did, Garrett. I'm not sure anyone else did, though. That's
probably why I started a new thread. Maybe I could have done better.

Sadly, Garrett, only one person responded to your message, and then not
to you FAQ suggestions (response below)
===
> Clone, and Crockford's beget(), have been well covered here and in
> various blogs (including Crockford's own). Clone may well be a
> suitable FAQ topic, even if the entry is just a summary with links to
> clone() and beget() threads.
>

Links seems better; explanation of the prototype chain, scope, and
inheritance techniques are too involved for the FAQ.

Maybe:

How can I clone an object?
* LRN clone method/ link to article [link]
* link to cloning using |for in| borrowing [link]

How does inheritance work?
javascript uses prototype inheritance, [link]
members can be hidden using Scope [link]

If those questions are sufficient, and the answer format is sufficient,
then pick best articles need to be picked and linked to by replacing
"[link]" with an actual link.
===

--
Jonathan

matt prokes

unread,
Jul 30, 2009, 3:57:34 AM7/30/09
to

Here is a simplified way of doing what java would describe as
packages.

object namespaces:
v={},v.r={},v.r.t=function(){alert('hi');};

You can now do this.
v.r.t();

Though this does not create an instance of the object, it just
executes the function.


Here is a simple example of working with javascript with a concept
similar to what java would describe as a class.

t = function(x){
this.call = function(){alert(x);}
}

If you know other programming languages, for the point of this
discussion, you can think of a top level function as a class (although
function also serves other purposes, as methods, functions, etc).

So now how would we create a instance of object t?

var hi = new t('Hi');
hi.call();
(you should get an alert)

Ok, lets create another instance.

var hii = new t('Hii');
hii.call();
(you should get a new and slightly different alert)

Keep in mind this is a very simplified view of things, for certain
development groups (particularly the c/c++/java people javascript can
be very confusing because it is a implicit language instead of an
explicit language. Thus it can take years to learn for all its
beauty.)

Classes and instances are NOT the only way to work with javascript
objects, and they are not always appropriate (just as a abstract class
or inheritance in java is not always appropriate). I would suggest you
research the other ways of working with objects, in specific closures,
object literals, and functional programming.

Richard Cornford

unread,
Jul 30, 2009, 4:20:09 AM7/30/09
to
Jonathan Fine wrote:
> Richard Cornford wrote:
>> Jonathan Fine wrote:
>>> Hi
>>>
>>> I thought this might be a good question for the FAQ.
>> <snip>
>>
>> Where is the question, or are you referring to the subject
>> header of your post?
>
> The subject.

Then don't do that; you are not supposed to assume that the subject
header will be available to someone reading the message body.

>> What you are doing here appears to be asking someone else
>> (presumably anyone else) to devote their (free) time to
>> writing a (more or less) complete summery of a complex
>> subject, sufficiently concisely for inclusions in the FAQ.
>> That is quite a lot to ask (and far too much to demand)
>> of someone else.
>
> It others agree that it's a good question for the FAQ, then
> it's something I'm willing to contribute to.

You expect agreement before anyone knows what they are supposed to be
agreeing to?

>> Existence is filled with things that one might wish were
>> different to the way they are. Of the things that can be
>> changed, they are more likely to be changed by positive
>> action, as opposed to merely complaining. In this context,
>> the most positive action you could take would be to propose
>> a full draft text for the addition to the FAQ that you would
>> like to see.
>
> I was not complaining. I made a positive suggestion.

You did no more than propose that something should be different from the
way it is.

> Richard, do you like the idea?

The purpose of such a question is to provide an opportunity to get some
point, that it is considered important to convey, across to people
interested in javascript (and/or the group). Without some idea of what
that point is supposed to be there is simply nothing to judge here.
After all, the accurate answers to the question as asked are both "yes"
and "no", and neither answers are worth hearing.

Richard.

Jonathan Fine

unread,
Jul 30, 2009, 4:36:36 AM7/30/09
to
Richard Cornford wrote:

[snip]

>> It others agree that it's a good question for the FAQ, then
>> it's something I'm willing to contribute to.
>
> You expect agreement before anyone knows what they are supposed to be
> agreeing to?

I'm asking: Do you think
Does JavaScript have classes and instances?
is a good question for the FAQ. That's all.

I'm NOT asking, do you think an answer that's not been written yet is a
good answer to this question.

Would you like to express an opinion on the question now, Richard?

--
Jonathan

Richard Cornford

unread,
Jul 30, 2009, 7:16:32 AM7/30/09
to
On Jul 30, 9:36 am, Jonathan Fine wrote:
> Richard Cornford wrote:
<snip>
>>> It others agree that it's a good question for the FAQ, then
>>> it's something I'm willing to contribute to.
>
>> You expect agreement before anyone knows what they are supposed
>> to be agreeing to?
>
> I'm asking: Do you think
> Does JavaScript have classes and instances?
> is a good question for the FAQ. That's all.

And I am not going to be railroaded into implicitly endorsing an
answer that I have not yet seen.

> I'm NOT asking, do you think an answer that's not been written yet
> is a good answer to this question.

You are not doing much else besides that.

> Would you like to express an opinion on the question now, Richard?

I have expressed an opinion about the question (you edited it out).
That opinion was that possible answers to the question range from "no"
to "yes" and don't necessarily include anything more useful in-
between. In that case pinning down what points the answer is should be
addressing is necessary before moving formward.

Richard.

Lasse Reichstein Nielsen

unread,
Jul 30, 2009, 1:35:38 PM7/30/09
to
Jonathan Fine <jf...@pytex.org> writes:

[Does JavaScript have classes and instances?]


> I thought this might be a good question for the FAQ.
> http://www.jibbering.com/faq/

That's an easy question: It depends on what you mean by "classes" and
"instances" :P

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

Thomas 'PointedEars' Lahn

unread,
Jul 30, 2009, 3:27:07 PM7/30/09
to
Lasse Reichstein Nielsen wrote:
> Jonathan Fine <jf...@pytex.org> writes:
> [Does JavaScript have classes and instances?]
>> I thought this might be a good question for the FAQ.
>> http://www.jibbering.com/faq/
>
> That's an easy question: It depends on what you mean by "classes" and
> "instances" :P

And "JavaScript" :)

Languages that implement ECMAScript up to Edition 3 (in the following: ES3)
do not have classes as that is (only) a prototype-based object-oriented
programming language. They do have instances, though: In the Specification,
the term "instance" is used for objects that are created with certain
constructors. For example, there are "Array instances" (section 15.4.5)
that are created, explicitly or implicitly, using the Array() constructor,
which are attributed certain non-inherited properties per that section.
AISB, if the Specification uses that term in that way, there is no good
reason that it should not be used in that way in discussions about
implementations of ECMAScript.

JavaScript™ is Netscape's/Mozilla.org's implementation of ECMAScript.
JavaScript up to version 1.8.1 (current) is only prototype-based and does
not have classes, but it has instances (as defined by the Specification).
JavaScript 2.0, which is based on an earlier Netscape proposal for
ECMAScript Edition 4 (in the following: ES4), has classes (in the sense of
class-based OOP), and it has instances both in the prototype-based and in
the class-based sense (i.e. instances of classes). JavaScript™ can be used
client-side in Netscape and Mozilla.org applications (those using Gecko),
and server-side e.g. with Netscape Enterprise Server-compatible Web servers.
No production-quality JavaScript™ version that supports classes has been
observed to date; there is only the Epimetheus test implementation of
JavaScript 2.0 (apparently development has been suspended after the AOL
takeover of Netscape).

Opera Software ASA has also created an (prototype-based) implementation of
ECMAScript Edition 3 for their browsers that they call "JavaScript" which
differs from the aforementioned JavaScript™ in several respects (most
notably, it does not support JavaScript™'s latest proprietary extensions; it
has therefore been referred to as "Opera ECMAScript" elsewhere). The same
applies to the implementation from KHTML (Konqueror HTML), KJS (Konqueror
JavaScript), and that in Apple WebKit, JavaScriptCore, which can be used in
Apple Safari and other WebKit-based products.

JScript is Microsoft's implementation of ECMAScript. JScript up to version
5.8.x (current) is only prototype-based and does not have classes; it can be
used client-side e.g. in the MSHTML component that is used e.g. in Microsoft
Internet Explorer, and server-side in the ASP framework. JScript 7.0 and
later (.NET) are implementations of ES4, and therefore support class-based
inheritance as well; they can be used server-side in the ASP .NET framework.

ActionScript is Macromedia/Adobe's implementation of ECMAScript, to be used
in Macromedia/Adobe Flash "movies". ActionScript up to version 2.0 is an
implementation of ECMAScript up to Edition 3, thus only prototype-based.
ActionScript 3.0 is an implementation of ES4 and supports class-based
inheritance as well.

There are other implementations of ES3 (e.g. Adobe PDF JavaScript, or the
recently mentioned BlackBerry's implementation), and there may be other
implementations of ES4 that support class-based inheritance. However, no
implementation that supports class-based inheritance has been observed to
be supported in Web browsers to date.

The ECMAScript Support Matrix (short: ES Matrix, or just Matrix in paying
homage to the "Matrix" trilogy)¹ is an ongoing effort to catalog all
reasonably well distributed ECMAScript implementations and their features,
in order to provide an overview about which language features can be
considered safe as they are interoperable among the more common versions of
the cataloged implementations; and about which features are special to one
or more, but not all, implementations or versions, so that they need to be
used with care. Your contribution is appreciated.


Regards,

PointedEars
___________
¹ <http://PointedEars.de/es-matrix>
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

kangax

unread,
Jul 30, 2009, 3:55:52 PM7/30/09
to
Thomas 'PointedEars' Lahn wrote:
> Lasse Reichstein Nielsen wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>> [Does JavaScript have classes and instances?]
>>> I thought this might be a good question for the FAQ.
>>> http://www.jibbering.com/faq/
>> That's an easy question: It depends on what you mean by "classes" and
>> "instances" :P
>
> And "JavaScript" :)
[...]

> Opera Software ASA has also created an (prototype-based) implementation of
> ECMAScript Edition 3 for their browsers that they call "JavaScript" which
> differs from the aforementioned JavaScript™ in several respects (most
> notably, it does not support JavaScript™'s latest proprietary extensions; it
> has therefore been referred to as "Opera ECMAScript" elsewhere). The same

Opera itself usually refers to it as their ECMAScript implementation
too. Opera also explicitly states that their ECMAScript implementation
approximately aligns with JavaScript 1.3/1.5 Core
<http://www.opera.com/docs/specs/presto22/#ecmascript>, although one can
see that their latest version (Opera 10) already goes slightly beyond
and adds some (?) of the JavaScript 1.6 features
<http://www.opera.com/docs/specs/presto22/ecmascript/index.dml>, such as
Array's extensions.

[...]

> There are other implementations of ES3 (e.g. Adobe PDF JavaScript, or the
> recently mentioned BlackBerry's implementation), and there may be other

I was thinking of running sputniktests
<http://code.google.com/p/sputniktests/> - an ECMA-262 conformance test
suite, recently released by Google - to determine the coverage of ES3
support by Blackberry implementation. I just need to first extract those
somehow to be able to run them online (since automation tools that come
with the suite
<http://code.google.com/p/sputniktests/wiki/RunningSputnik> are not
quite applicable for something like a mobile device).

> implementations of ES4 that support class-based inheritance. However, no
> implementation that supports class-based inheritance has been observed to
> be supported in Web browsers to date.

Excellent overview. Thank you.

[...]

--
kangax

Thomas 'PointedEars' Lahn

unread,
Jul 30, 2009, 4:10:31 PM7/30/09
to
kangax wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Lasse Reichstein Nielsen wrote:
>>> Jonathan Fine <jf...@pytex.org> writes:
>>> [Does JavaScript have classes and instances?]
>>>> I thought this might be a good question for the FAQ.
>>>> http://www.jibbering.com/faq/
>>> That's an easy question: It depends on what you mean by "classes" and
>>> "instances" :P
>> And "JavaScript" :)
> [...]
>> Opera Software ASA has also created an (prototype-based) implementation of
>> ECMAScript Edition 3 for their browsers that they call "JavaScript" which
>> differs from the aforementioned JavaScript™ in several respects (most
>> notably, it does not support JavaScript™'s latest proprietary extensions; it
>> has therefore been referred to as "Opera ECMAScript" elsewhere). The same
>
> Opera itself usually refers to it as their ECMAScript implementation
> too. Opera also explicitly states that their ECMAScript implementation
> approximately aligns with JavaScript 1.3/1.5 Core
> <http://www.opera.com/docs/specs/presto22/#ecmascript>, although one can
> see that their latest version (Opera 10) already goes slightly beyond
> and adds some (?) of the JavaScript 1.6 features
> <http://www.opera.com/docs/specs/presto22/ecmascript/index.dml>, such as
> Array's extensions.

Yes, the implementation of the Standard includes the possibility of
additional features. The Matrix has you :)

> [...]
>
>> There are other implementations of ES3 (e.g. Adobe PDF JavaScript, or the
>> recently mentioned BlackBerry's implementation), and there may be other
>
> I was thinking of running sputniktests
> <http://code.google.com/p/sputniktests/> - an ECMA-262 conformance test
> suite, recently released by Google - to determine the coverage of ES3
> support by Blackberry implementation. I just need to first extract those
> somehow to be able to run them online (since automation tools that come
> with the suite
> <http://code.google.com/p/sputniktests/wiki/RunningSputnik> are not
> quite applicable for something like a mobile device).

Somehow I doubt that Google developers have the necessary background to
write such a piece of software. Just look at the junk that they wrote
before and dared to call it source code.

BTW, the next release of the ES Matrix will include feature tests. I am
using them already in the local version to fill in the missing parts more
efficiently.

>> implementations of ES4 that support class-based inheritance. However, no
>> implementation that supports class-based inheritance has been observed to
>> be supported in Web browsers to date.
>
> Excellent overview. Thank you.

You are welcome.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Jonathan Fine

unread,
Jul 30, 2009, 5:51:52 PM7/30/09
to
Hi

Here's my first attempt to answer my self-imposed question:


Does JavaScript have classes and instances?


<answer>
In many languages, each object belongs to and inherits properties from a
class. Each class, in turn can inherit properties from one (or in some
languages multiple) other classes. JavaScript provides something like
this, but does it differently.

In JavaScript the objects (except the null object) form a tree, whose
root is Object.prototype. Each object inherits properties from its
ancestors, all the way up to the root of the tree.
</answer>

((At this point I am a bit stuck. I'd like to say that 'new' adds
objects to the tree, and the use of the 'instanceof' operator. But
they're a bit complex to explain. Neither are mentioned in the current FAQ.

But 'new' is not as bad as all that, provided we don't try to explain
everything, and instanceof can be left until later.))

<answer>
If Fn is a function that returns undefined and Fn.prototype is a
non-null object 'x' then
y = new Fn(...);
creates an object 'y' whose parent is 'x'. In this way we can add to
the tree of objects.

If we wish to, we can think of 'Fn' as a class and 'y' as an instance of
this class, just as we can think of a pair [2, 3] (or triple [2, 3, 4])
as a point.
</answer>

((We've now ready to answer the question. We've told the reader about
the inheritance tree and the new operator.)

<answer>
JavaScript does not have a built-in concept of class. It has an
inheritance tree and the 'new' operator, which adds nodes to the tree.
</answer>

((At this point, providing class behaviours in JavaScript could be
discussed.))

And now I'm out of time.

--
Jonathan

Dr J R Stockton

unread,
Jul 30, 2009, 2:46:39 PM7/30/09
to
In comp.lang.javascript message <l9mdnUVqvdfnR-3XnZ2dnUVZ8s-
dn...@giganews.com>, Thu, 30 Jul 2009 00:25:42, Richard Cornford
<Ric...@litotes.demon.co.uk> posted:

>Jonathan Fine wrote:
>> Hi
>>
>> I thought this might be a good question for the FAQ.
><snip>
>
>Where is the question, or are you referring to the subject header of
>your post?
>
>What you are doing here appears to be asking someone else (presumably
>anyone else) to devote their (free) time to writing a (more or less)
>complete summery of a complex subject, sufficiently concisely for
>inclusions in the FAQ. That is quite a lot to ask (and far too much to
>demand) of someone else.

You are being grossly unreasonable.

>Existence is filled with things that one might wish were different to
>the way they are. Of the things that can be changed, they are more
>likely to be changed by positive action, as opposed to merely
>complaining.

I see no complaint there; the OP gave a straightforward question.

> In this context, the most positive action you could take would be to
>propose a full draft text for the addition to the FAQ that you would
>like to see.

Those who are most likely to perceive a possible or apparent need for a
FAQ section are, or certainly rightly include, those who are least
likely to be able to provide a helpful draft.


However, ISTM that such a section would only he helpful to the
unenterprising or ill-prepared. The FAQ cites the language standards,
freely available in PDF; and searching those for substrings "class" and
"instance" quickly indicates the answer in each case.


A better Subject might be "Does JavaScript have anything like classes
and instances?" though it would be necessary in the answer to indicate
what was to be taken as definitive for class & instance.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Plaintext, quoting : see <URL:http://www.usenet.org.uk/ukpost.html>
Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)

RobG

unread,
Jul 30, 2009, 8:17:04 PM7/30/09
to
On Jul 31, 7:51 am, Jonathan Fine <jf...@pytex.org> wrote:
> Hi
>
> Here's my first attempt to answer my self-imposed question:
>       Does JavaScript have classes and instances?

I think Thomas has answered that fairly thoroughly already.


> <answer>
> In many languages, each object belongs to and inherits properties from a
> class.  Each class, in turn can inherit properties from one (or in some
> languages multiple) other classes.

I don't think it is necessary to summarise class inheritance,
particularly when javascript (in general) doesn't have classes. I
think the question you are trying to answer is: how does javascript
implement inhertiance?

That *is* a topic worth of the FAQ, though questions are more likely
to focus on "what is a prototype" or "how do I use Foo.prototype" or
similar.

> JavaScript provides something like
> this, but does it differently.
>
> In JavaScript the objects (except the null object) form a tree, whose
> root is Object.prototype.  Each object inherits properties from its
> ancestors, all the way up to the root of the tree.

Objects inherit from their constructor's public prototype, not from
their "ancestors".

<FAQENTRY>
The article on closures could be split into two: one relating to
"dentifier Resolution, Execution Contexts and Scope Chains", and the
other on closures. Or an extra entry could be provided in the index
to the early sections, I find that part of the closures article stands
on its own as a great introduction to some important javascript
fundamentals.

A section on prototype inheritance would compliment that article (or
artciles if split into two).
</FAQENTRY>


--
Rob

Malcolm Dew-Jones

unread,
Jul 30, 2009, 8:24:33 PM7/30/09
to
Jonathan Fine (jf...@pytex.org) wrote:
: Hi

: Here's my first attempt to answer my self-imposed question:
: Does JavaScript have classes and instances?

The term "class" is not a language element, but it is an important unit of
analysis of a system at runtime.

In Javascript, for any set of "behaviours" being considered, the set of
objects that currently have those behaviours are in the same class. Each
of those objects can be considered an instance of the class.

The most rigid interpretation is when the "behaviours" must be all the
behaviours of the object, but it is more useful to only require that an
object has _at least_ the "behaviours" in question.

"Behaviours" is not meant to be well defined, it does not have to be
methods, or property names. Those would most commonly be the basis of how
you wish to compare the "class-ish-ness" of objects, but anything relevant
to your analysis of the runtime system could be considered a "behavior"
that would be the basis of interpreting some objects as being in the same
class.

To sum up, Javascript has a dynamic, non-formal but useful interpretation
of "class".

$0.01

kangax

unread,
Jul 30, 2009, 11:43:54 PM7/30/09
to
RobG wrote:
> On Jul 31, 7:51 am, Jonathan Fine <jf...@pytex.org> wrote:
[...]

>> In JavaScript the objects (except the null object) form a tree, whose
>> root is Object.prototype. Each object inherits properties from its
>> ancestors, all the way up to the root of the tree.
>
> Objects inherit from their constructor's public prototype, not from
> their "ancestors".

Wouldn't it be more precise to say that objects "inherit" dynamically
from whatever their internal prototype property (aka [[Prototype]])
references? constructor's public prototype just happens to act as a
starting point for that internal property when object is instantiated.

This "difference" can be easily observed when object keeps its original
inheritance relationship after reassignment of constructor's public
prototype property:

function F(){};
F.prototype.x = 1;

var obj = new F();

// reassign `prototype`
obj.constructor.prototype = { x: 2 };

obj.x; // 1

[...]

--
kangax

Lasse Reichstein Nielsen

unread,
Jul 31, 2009, 1:13:34 AM7/31/09
to
Jonathan Fine <jf...@pytex.org> writes:

> Here's my first attempt to answer my self-imposed question:
> Does JavaScript have classes and instances?
>
>
> <answer>
> In many languages, each object belongs to and inherits properties from
> a class. Each class, in turn can inherit properties from one (or in
> some languages multiple) other classes. JavaScript provides something
> like this, but does it differently.

Very vague. "Many languages", "something like this", "differently".
It doesn't define what a class is, except that "objects" inherit
"properties" from it, and "classes" also inherit properties from
other classes, so you can't easily tell what the difference between
an object and a class is.

Rather than reinventing the wheel, refer to some external definition
of "class based language", "class based OO" or "class based
inheritance", e.g., http://en.wikipedia.org/wiki/Class-based_programming
and try to get a good grasp of the concepts before writing about them.

Or just refer to one (or preferably more) of the existing pages that
discuss the topice, e.g.
https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Class-Based_vs._Prototype-Based_Languages

> In JavaScript the objects (except the null object)

Except "null" is not an object (even though "typeof null == 'object'").

> form a tree, whose
> root is Object.prototype. Each object inherits properties from its
> ancestors, all the way up to the root of the tree.

This is technically correct, but doesn't say anything about classes
or instances. It's about inheritance instead.

> </answer>
>
> ((At this point I am a bit stuck. I'd like to say that 'new' adds
> objects to the tree, and the use of the 'instanceof' operator. But
> they're a bit complex to explain. Neither are mentioned in the
> current FAQ.

"new" creats objects. You already said that all objects are in the
tree, so no need to say that the created objects are added.

You can't explain "instanceof" without describing the relation between
"new" and a function's "prototype" property. At this point you are
describing a significant part of the Javascript language as background
for giving an answer that is most likely just going to be "so no,
Javascript doesn't have classes".


> But 'new' is not as bad as all that, provided we don't try to explain
> everything, and instanceof can be left until later.))
>
> <answer>
> If Fn is a function that returns undefined

Doesn't have to return "undefined". As long as it doesn't return another
object than "this", it will work as a constructor.

> and Fn.prototype is a
> non-null object 'x' then
> y = new Fn(...);
> creates an object 'y' whose parent is 'x'.

"whose internal prototype is"

> In this way we can add to
> the tree of objects.

The "tree of objects" concept is overkill for this explanation.
It adds another concept, on top of what we already have, that just confuzes
the explanation.

> If we wish to, we can think of 'Fn' as a class and 'y' as an instance
> of this class, just as we can think of a pair [2, 3] (or triple [2, 3,
> 4]) as a point.

"can think of" is not the same as "is". The conclusion from all this
would be that "no, javascript doesn't have classes".

The point example just confuses things by adding more concepts again.
We can think of, or imagine, anything. That's not an argument for
anything, except that it really isn't what we choose to think of it
as.

> </answer>
>
> ((We've now ready to answer the question. We've told the reader about
> the inheritance tree and the new operator.)
>
> <answer>
> JavaScript does not have a built-in concept of class. It has an
> inheritance tree and the 'new' operator, which adds nodes to the tree.

Drop the "tree" concept.
When writing for the web, start with the conclusion and then elaborate,
instead of starting with a lot of built-up before getting to the point
(I know how hard that is - building up is my preferred way of
explaining too).


A much shorter version:

"Javascript does not have a built-in concept of class. When a new object
is created, it inherits properties directly from another object (it's
"prototype").

New objects are created by the syntax "new func(args)". This creates a
new object which inherits from the object "func.prototype", and
initializes it by calling "func(args)" with "this" referring to the
new object.

The internal prototype link of an object is exposed in some
implementations as a property called "__proto__". This is not required
by the specification.

RobG

unread,
Jul 31, 2009, 1:52:27 AM7/31/09
to
On Jul 31, 1:43 pm, kangax <kan...@gmail.com> wrote:
> RobG wrote:
> > On Jul 31, 7:51 am, Jonathan Fine <jf...@pytex.org> wrote:
> [...]
> >> In JavaScript the objects (except the null object) form a tree, whose
> >> root is Object.prototype.  Each object inherits properties from its
> >> ancestors, all the way up to the root of the tree.
>
> > Objects inherit from their constructor's public prototype, not from
> > their "ancestors".
>
> Wouldn't it be more precise to say that objects "inherit" dynamically
> from whatever their internal prototype property (aka [[Prototype]])
> references? constructor's public prototype just happens to act as a
> starting point for that internal property when object is instantiated.

Yes, of course, there's a lot more missing. A full and detailed
description is required, we are only nibbling at the edges here. I
wrote an article some time ago to describe prototype inheritance, it
was much longer than I expected it to be and didn't cover all aspects.

I may review it and perhaps post a link, it will take a few days to
get around to that. Perhaps you have written something on your blog? I
can't tell as I can't access it from the site I'm currently at, it's
blocked due to be being categorised as "Social Networking and Personal
Sites".


--
Rob


Jonathan Fine

unread,
Jul 31, 2009, 3:51:25 AM7/31/09
to
RobG wrote:
> On Jul 31, 7:51 am, Jonathan Fine <jf...@pytex.org> wrote:
>> Hi
>>
>> Here's my first attempt to answer my self-imposed question:
>> Does JavaScript have classes and instances?
>
> I think Thomas has answered that fairly thoroughly already.
>
>
>> <answer>
>> In many languages, each object belongs to and inherits properties from a
>> class. Each class, in turn can inherit properties from one (or in some
>> languages multiple) other classes.
>
> I don't think it is necessary to summarise class inheritance,
> particularly when javascript (in general) doesn't have classes. I
> think the question you are trying to answer is: how does javascript
> implement inhertiance?

I agree that it is not necessary, but it may be helpful. I was
intending finish the Answer by referring to 'implementations of Classes'
in JavaScript.

> That *is* a topic worth of the FAQ, though questions are more likely
> to focus on "what is a prototype" or "how do I use Foo.prototype" or
> similar.

I'm glad we agree here. I think "How do I use Foo.prototype" could be a
good question, but to lead up I think we need "Does JavaScript have
classes and instances">

>> JavaScript provides something like


>> this, but does it differently.
>>
>> In JavaScript the objects (except the null object) form a tree, whose
>> root is Object.prototype. Each object inherits properties from its
>> ancestors, all the way up to the root of the tree.
>
> Objects inherit from their constructor's public prototype, not from
> their "ancestors".

I read statements like this many times, when I was learning JavaScript.
They were, for me, unhelpful. I wanted a simple, exact and true
statement that I could hold on to. This statement is insufficiently
exact to be true.

It does not tell me what happens when I replace Fn.prototype by another
object, or when Fn itself ceases to exist. Without that, I cannot
understand the construction variously called begat, clone and create.

> <FAQENTRY>
> The article on closures could be split into two: one relating to
> "dentifier Resolution, Execution Contexts and Scope Chains", and the
> other on closures. Or an extra entry could be provided in the index
> to the early sections, I find that part of the closures article stands
> on its own as a great introduction to some important javascript
> fundamentals.
>
> A section on prototype inheritance would compliment that article (or
> artciles if split into two).
> </FAQENTRY>

I think this might best be discussed in another thread.

--
Jonathan

Jonathan Fine

unread,
Jul 31, 2009, 3:56:40 AM7/31/09
to
Malcolm Dew-Jones wrote:
> Jonathan Fine (jf...@pytex.org) wrote:
> : Hi
>
> : Here's my first attempt to answer my self-imposed question:
> : Does JavaScript have classes and instances?
>
> The term "class" is not a language element, but it is an important unit of
> analysis of a system at runtime.

I like this sentence a great deal. Perhaps better is "..., but may help
when understanding JavaScript code."

This, by itself, answers the question: "Does JavaScript have classes?"


> In Javascript, for any set of "behaviours" being considered, the set of
> objects that currently have those behaviours are in the same class. Each
> of those objects can be considered an instance of the class.
>
> The most rigid interpretation is when the "behaviours" must be all the
> behaviours of the object, but it is more useful to only require that an
> object has _at least_ the "behaviours" in question.
>
> "Behaviours" is not meant to be well defined, it does not have to be
> methods, or property names. Those would most commonly be the basis of how
> you wish to compare the "class-ish-ness" of objects, but anything relevant
> to your analysis of the runtime system could be considered a "behavior"
> that would be the basis of interpreting some objects as being in the same
> class.

I think a discussion of prototype inheritance is required here.


> To sum up, Javascript has a dynamic, non-formal but useful interpretation
> of "class".

I really like this sentence also.

>
> $0.01

Thank you for this, Malcolm. I like what you've written.

--
Jonathan

Jonathan Fine

unread,
Jul 31, 2009, 3:58:40 AM7/31/09
to

Wonderfully put. Thank you, kangax. This is why I prefer to start with
the inheritance tree, and then explain 'new' in terms of the tree.

--
Jonathan

Jonathan Fine

unread,
Jul 31, 2009, 4:07:12 AM7/31/09
to
Lasse Reichstein Nielsen wrote:

<snip>


> A much shorter version:
>
> "Javascript does not have a built-in concept of class. When a new object
> is created, it inherits properties directly from another object (it's
> "prototype").
>
> New objects are created by the syntax "new func(args)". This creates a
> new object which inherits from the object "func.prototype", and
> initializes it by calling "func(args)" with "this" referring to the
> new object.
>
> The internal prototype link of an object is exposed in some
> implementations as a property called "__proto__". This is not required
> by the specification.


There's a lot I like about this. However, perhaps it's necessary to say
what inheritance is.

--
Jonathan


Jonathan Fine

unread,
Jul 31, 2009, 4:25:48 AM7/31/09
to
Lasse Reichstein Nielsen wrote:
> Jonathan Fine <jf...@pytex.org> writes:

[snip]

>> In JavaScript the objects (except the null object)
>
> Except "null" is not an object (even though "typeof null == 'object'").

I think there's a problem with the FAQ. It contianss 'undefined' twice
and 'null' once, and then only in passing. I think we need a question:
What's the difference between undefined and null?


>> form a tree, whose
>> root is Object.prototype. Each object inherits properties from its
>> ancestors, all the way up to the root of the tree.
>
> This is technically correct, but doesn't say anything about classes
> or instances. It's about inheritance instead.

In some other languages, classes and instances are the way to provide
inheritance. That's why I think it's relevant.


>> </answer>
>>
>> ((At this point I am a bit stuck. I'd like to say that 'new' adds
>> objects to the tree, and the use of the 'instanceof' operator. But
>> they're a bit complex to explain. Neither are mentioned in the
>> current FAQ.
>
> "new" creats objects. You already said that all objects are in the
> tree, so no need to say that the created objects are added.
>
> You can't explain "instanceof" without describing the relation between
> "new" and a function's "prototype" property. At this point you are
> describing a significant part of the Javascript language as background
> for giving an answer that is most likely just going to be "so no,
> Javascript doesn't have classes".

I'm inclined to agree. I don't think 'instanceof' is core to the FAQ.

>> But 'new' is not as bad as all that, provided we don't try to explain
>> everything, and instanceof can be left until later.))
>>
>> <answer>
>> If Fn is a function that returns undefined
>
> Doesn't have to return "undefined". As long as it doesn't return another
> object than "this", it will work as a constructor.

Yes, I knew that when I wrote it. But I did not want to complicate
matters. I rarely see a function used as a constructor returning other
than undefined.

And what about this (not tested):

var store = {}
var Fn = function(locn){
store.push(this);
return store;
};

new Fn(); new Fn(); new Fn();

This (admittedly obscure) use of new is not covered by the text you propose.


>> and Fn.prototype is a non-null object 'x' then
>> y = new Fn(...);
>> creates an object 'y' whose parent is 'x'.
>
> "whose internal prototype is"

That's fine, provided we have the concept of 'internal prototype'.

>> In this way we can add to the tree of objects.
>
> The "tree of objects" concept is overkill for this explanation.
> It adds another concept, on top of what we already have, that just confuzes
> the explanation.

Most JavaScript programmers are already aware of the DOM tree. The tree
of objects is the concept that has allowed me to understand JavaScript
inheritance.

[snip]

> Drop the "tree" concept.
> When writing for the web, start with the conclusion and then elaborate,
> instead of starting with a lot of built-up before getting to the point
> (I know how hard that is - building up is my preferred way of
> explaining too).

I think the tree concept is the main area where we don't agree.


> A much shorter version:

[snip]

I've put my comments on this in another post.

Thank you, Lasse, for your contribution.

--
Jonathan

Jonathan Fine

unread,
Jul 31, 2009, 7:27:57 AM7/31/09
to
Dr J R Stockton wrote:

[snip]

>> In this context, the most positive action you could take would be to
>> propose a full draft text for the addition to the FAQ that you would
>> like to see.
>
> Those who are most likely to perceive a possible or apparent need for a
> FAQ section are, or certainly rightly include, those who are least
> likely to be able to provide a helpful draft.

This is a very good point.

> However, ISTM that such a section would only he helpful to the
> unenterprising or ill-prepared. The FAQ cites the language standards,
> freely available in PDF; and searching those for substrings "class" and
> "instance" quickly indicates the answer in each case.

I've just taken a look at 4.2.1 Objects. It does not tell us that we
can write:
var Fn = function(){ ... }
var x = new Fn();

Moreover, I've not found in it helpful regarding 'instance'.

So I'd say a link to the FAQ is not sufficiently helpful.

> A better Subject might be "Does JavaScript have anything like classes
> and instances?" though it would be necessary in the answer to indicate
> what was to be taken as definitive for class & instance.

I don't see that adding "anything like" helps, unless we've already said
that JS does not have classes and instances.

--
Jonathan

kangax

unread,
Jul 31, 2009, 11:19:31 AM7/31/09
to
RobG wrote:
> On Jul 31, 1:43 pm, kangax <kan...@gmail.com> wrote:
>> RobG wrote:
>>> On Jul 31, 7:51 am, Jonathan Fine <jf...@pytex.org> wrote:
>> [...]
>>>> In JavaScript the objects (except the null object) form a tree, whose
>>>> root is Object.prototype. Each object inherits properties from its
>>>> ancestors, all the way up to the root of the tree.
>>> Objects inherit from their constructor's public prototype, not from
>>> their "ancestors".
>> Wouldn't it be more precise to say that objects "inherit" dynamically
>> from whatever their internal prototype property (aka [[Prototype]])
>> references? constructor's public prototype just happens to act as a
>> starting point for that internal property when object is instantiated.
>
> Yes, of course, there's a lot more missing. A full and detailed
> description is required, we are only nibbling at the edges here. I
> wrote an article some time ago to describe prototype inheritance, it
> was much longer than I expected it to be and didn't cover all aspects.
>
> I may review it and perhaps post a link, it will take a few days to
> get around to that. Perhaps you have written something on your blog? I

I haven't, but there is an article by Joost
<http://joost.zeekat.nl/constructors-considered-mildly-confusing.html>.
I remember reading it a couple of years ago, when I was just starting
with Javascript and tried to understand its inheritance.

I think I was still confused after reading that piece though and it was
Richard's and Lasse's posts in the archives (and my own constant
experiments) that made things more or less clear.

> can't tell as I can't access it from the site I'm currently at, it's
> blocked due to be being categorised as "Social Networking and Personal
> Sites".

I wonder what that categorization is based on.

--
kangax

John G Harris

unread,
Jul 31, 2009, 11:44:48 AM7/31/09
to
On Wed, 29 Jul 2009 at 22:36:43, in comp.lang.javascript, Jonathan Fine
wrote:
>Hi
>
>I thought this might be a good question for the FAQ.
> http://www.jibbering.com/faq/

Question:

Does JavaScript have classes and instances?


Answer:

Yes it does, Jim, but not as we in C++/Java know it.

In more detail and using posh words :

C++, Java, etc have declarative class definitions, whereas javascript
has imperative class definitions.

That is, in C++, Java, etc you tell the compiler what data fields you
want in each object and what functions (methods) you want the object to
have access to. The compiler has the job of writing the code that
allocates space in storage for the data fields, with padding as
necessary to ensure integers start on 4 byte boundaries, etc. It also
has the job of writing the code that enables the object's functions to
access the right object's data.

But in javascript all the compiler/translator does is to give you a raw
object. You write the code that provides data fields and access to
functions, and you write the code that enables the object's functions to
access the right object's data (with a little help from the language).

Even worse, javascript provides several different ways of doing this.
For each way there is someone ready to jump up and down and scream that
this way is the only right way.

Some people claim that 'class' is restricted to declarative class
definitions, but this is muddled thinking. A class of Date objects is
just as much a class of objects in javascript as it is in Java. That
said, it is important to remember that there are significant differences
between javascript and the other kind of languages.

John
--
John Harris

Jonathan Fine

unread,
Jul 31, 2009, 12:29:32 PM7/31/09
to
kangax wrote:

[snip]

> [...] there is an article by Joost

> <http://joost.zeekat.nl/constructors-considered-mildly-confusing.html>.
> I remember reading it a couple of years ago, when I was just starting
> with Javascript and tried to understand its inheritance.
>
> I think I was still confused after reading that piece though and it was
> Richard's and Lasse's posts in the archives (and my own constant
> experiments) that made things more or less clear.

I've read that article, and recommend it to all who have contributed to
this thread.

Like kanjax, I only learnt what was really going on by writing code,
observing its behaviour and understanding what I saw. I think some
experiments of this sort should appear in, or be linked to, the FAQ.

--
Jonathan

Jonathan Fine

unread,
Jul 31, 2009, 12:42:14 PM7/31/09
to
John G Harris wrote:
> On Wed, 29 Jul 2009 at 22:36:43, in comp.lang.javascript, Jonathan Fine
> wrote:
>> Hi
>>
>> I thought this might be a good question for the FAQ.
>> http://www.jibbering.com/faq/
>
> Question:
>
> Does JavaScript have classes and instances?
>
>
> Answer:
>
> Yes it does, Jim, but not as we in C++/Java know it.
>
> In more detail and using posh words :
>
> C++, Java, etc have declarative class definitions, whereas javascript
> has imperative class definitions.

I have to think about what this means. The way I'd like to read it is
that for C++/Java there is a primitive concept of class, accessed
through a class declaration statement, whereas in JavaScript you get to
make your own concept of class. I'm not the FAQ reader would have the
time and patience to rise to such a level of abstraction.

> That is, in C++, Java, etc you tell the compiler what data fields you
> want in each object and what functions (methods) you want the object to
> have access to. The compiler has the job of writing the code that
> allocates space in storage for the data fields, with padding as
> necessary to ensure integers start on 4 byte boundaries, etc. It also
> has the job of writing the code that enables the object's functions to
> access the right object's data.

I use Python, and unless you optimize by using __slots__ the compiler
does not allocate storage space for data fields. All the same, I'd
group Python with C++ and Java here.
http://docs.python.org/reference/datamodel.html#slots

> But in javascript all the compiler/translator does is to give you a raw
> object. You write the code that provides data fields and access to
> functions, and you write the code that enables the object's functions to
> access the right object's data (with a little help from the language).

And again in Python you write the code that gives you the data fields.
I think, John, you've identified an important difference between
C++/Java vs. JavaScript. But not, I think, the basic difference
regarding classes.

JavaScript has no built-in concept of class. It does have inheritance
between objects, and this allows you to build your own concept of class.

> Even worse, javascript provides several different ways of doing this.
> For each way there is someone ready to jump up and down and scream that
> this way is the only right way.

Well, this may be true. But I don't think it can be said in this way in
the FAQ (smile).

> Some people claim that 'class' is restricted to declarative class
> definitions, but this is muddled thinking. A class of Date objects is
> just as much a class of objects in javascript as it is in Java. That
> said, it is important to remember that there are significant differences
> between javascript and the other kind of languages.

I agree. Thank you, John, for your contributions.

--
Jonathan


Dr J R Stockton

unread,
Jul 31, 2009, 5:46:25 PM7/31/09
to
In comp.lang.javascript message <--2dnX_2AOGgSO_XnZ2dnUVZ8rudnZ2d@bright
view.co.uk>, Fri, 31 Jul 2009 12:27:57, Jonathan Fine <jf...@pytex.org>
posted:


A member of the intended class of readership may have, from experience
with a single language, a very definite idea of exactly what classes and
instances are. That idea may not exactly match the accepted generic
meanings of those terms. Therefore a simple answer, which is all that
the original Subject asks for, may be misleading or unhelpful.

The extended Subject accommodates that, and also encourages a more
positive answer as in the first sentence of 16262 4.2.1.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.


Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.

Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

Jonathan Fine

unread,
Jul 31, 2009, 7:06:18 PM7/31/09
to
Dr J R Stockton wrote:
> In comp.lang.javascript message <--2dnX_2AOGgSO_XnZ2dnUVZ8rudnZ2d@bright
> view.co.uk>, Fri, 31 Jul 2009 12:27:57, Jonathan Fine <jf...@pytex.org>
> posted:
>> Dr J R Stockton wrote:
>
>>> A better Subject might be "Does JavaScript have anything like classes
>>> and instances?" though it would be necessary in the answer to indicate
>>> what was to be taken as definitive for class & instance.
>> I don't see that adding "anything like" helps, unless we've already
>> said that JS does not have classes and instances.
>
>
> A member of the intended class of readership may have, from experience
> with a single language, a very definite idea of exactly what classes and
> instances are. That idea may not exactly match the accepted generic
> meanings of those terms.

Yes, I agree. This is possible. They'll be quite a few people like that.

> Therefore a simple answer, which is all that
> the original Subject asks for, may be misleading or unhelpful.

For me, the most important thing in what you say here is that the reader
may have clear and strongly held views about what classes and instances
are.

The answer will be more effective if it tells the user that these views
don't hold for JavaScript, and if appropriate encourages the user to
learn and understand what really happens in JavaScript.

> The extended Subject accommodates that, and also encourages a more
> positive answer as in the first sentence of 16262 4.2.1.

As I recall from yesterday, I thought that first sentence was fairly
good. It's a real shame that the ECMA standard is not available as
HTML. Then we'd be able to link to it.

--
Jonathan

Jorge

unread,
Jul 31, 2009, 7:26:24 PM7/31/09
to
On Jul 30, 11:51 pm, Jonathan Fine <jf...@pytex.org> wrote:
> (...)
> In JavaScript the objects form a tree, whose

> root is Object.prototype.  Each object inherits properties from its
> ancestors, all the way up to the root of the tree.
> (...)

This pictures it *perfectly*. I like it.

Just find a way to explain too that the internal [[prototype]]
attribute is what connects the leaves, that it's invisible, and that
once set it's inmutable : a subtle but important thing to note, imo.

--
Jorge.

Malcolm Dew-Jones

unread,
Jul 31, 2009, 9:50:01 PM7/31/09
to
Jonathan Fine (jf...@pytex.org) wrote:
: Hi

: I thought this might be a good question for the FAQ.
: http://www.jibbering.com/faq/

Replacing my own $0.01's worth, and certainly not intended as a complete
answer...


Javascript is very much an object oriented language, but neither the
language nor the interpreter have any feature called a "class". To people
familiar with languages like Java or C++ that might seem contradictory.
However, as in any OOP language, the concepts of class, and instances
within a class, are still very important, and Javascript applications
certainly do use classes of objects, and the individual objects are
instances of the class(es) to which they belong.

The difference is that Javascript is a very dynamic language - its objects
simply do not require any formal predefined "thing" that you might call a
class. Instead, Javascript objects, within the runtime environment of the
Javascript interpreter, interact with each other in a well defined manner
that implements the class behaviours expected of any object oriented
language.

Jonathan Fine

unread,
Aug 1, 2009, 1:33:52 AM8/1/09
to
Was: FAQ suggestion: Does JavaScript have classes and instances?

Jonathan Fine wrote:
> I thought this might be a good question for the FAQ.
> http://www.jibbering.com/faq/

There's been a lot of really good and thoughtful response to this, and
almost every one contains something positive and useful. I think it's
time now to move to summarizing and writing up.

I think we need both, to get the best result. Summarizing is a matter
of gathering everything useful and putting it in one (or a just a few)
posts. Everyone who participated should agree with the summary, because
it's a matter of reporting: Malcolm say .... etc. The summary should
also contain the text of the drafts that have been put forward.

Writing up is much harder, and will produce text that could usefully be
added to the FAQ. A massive knowledge of JavaScript is not required,
although a proper understanding of classes and inheritance is. What is
required are writing skills and an absence of bias, being open to all
the good things that have been said.

I'm going to be very busy for the next 10 days, and so won't have time
until after then. I'd be really grateful if some volunteers took this
forward over the next week. Don't be shy - it's a really great way to
learn.

Anyone who's got the right skills and attitude could do this, even if
they've not yet contributed to this thread.

--
Jonathan


Thomas 'PointedEars' Lahn

unread,
Aug 1, 2009, 6:36:44 AM8/1/09
to
Malcolm Dew-Jones wrote:
> Jonathan Fine (jf...@pytex.org) wrote:
> : I thought this might be a good question for the FAQ. :
> http://www.jibbering.com/faq/
>
> Replacing my own $0.01's worth, and certainly not intended as a complete
> answer...

Please don't. There are enough misinformation and misconceptions out of
(mis)interpretation of terms already.

> Javascript is very much an object oriented language, but neither the
> language nor the interpreter have any feature called a "class".

As for the interpreter, it remains to be seen a) what is meant by this and
b) if it has a feature called a class.

> To people familiar with languages like Java or C++ that might seem
> contradictory. However, as in any OOP language, the concepts of class,
> and instances within a class, are still very important, and Javascript
> applications certainly do use classes of objects, and the individual
> objects are instances of the class(es) to which they belong.

Rubbish.

> The difference is that Javascript is a very dynamic language - its
> objects simply do not require any formal predefined "thing" that you
> might call a class. Instead, Javascript objects, within the runtime
> environment of the Javascript interpreter, interact with each other in a
> well defined manner that implements the class behaviours expected of any
> object oriented language.

Rubbish. You have never set up a custom prototype chain or heard of
Function.prototype.call(), have you?


PointedEars

Jonathan Fine

unread,
Aug 1, 2009, 6:40:53 AM8/1/09
to
Thomas 'PointedEars' Lahn wrote:

> Please don't. There are enough misinformation and misconceptions out of
> (mis)interpretation of terms already.

> As for the interpreter, it remains to be seen a) what is meant by this and


> b) if it has a feature called a class.

> Rubbish.

> Rubbish. You have never set up a custom prototype chain or heard of
> Function.prototype.call(), have you?

Please suggest something better.

--
Jonathan

Lasse Reichstein Nielsen

unread,
Aug 1, 2009, 7:13:59 AM8/1/09
to
Jonathan Fine <jf...@pytex.org> writes:

[Does JavaScript have classes and instances?]


> I thought this might be a good question for the FAQ.
> http://www.jibbering.com/faq/

Is it frequently asked? :)

How about just:

A: No, Javascript has no language support for traditional class based
programming. A programmer can, and often do, create objects and treat
them as being from the same "class", but this only works as long as
everybody stays with the abstraction. There is no language support to
enforce the class relations.

Thomas 'PointedEars' Lahn

unread,
Aug 1, 2009, 7:16:39 AM8/1/09
to
Lasse Reichstein Nielsen wrote:
> Jonathan Fine <jf...@pytex.org> writes:
> [Does JavaScript have classes and instances?]
>> I thought this might be a good question for the FAQ.
>> http://www.jibbering.com/faq/
>
> Is it frequently asked? :)
>
> How about just:
>
> A: No, Javascript has no language support for traditional class based
> programming. A programmer can, and often do, create objects and treat
> them as being from the same "class", but this only works as long as
> everybody stays with the abstraction. There is no language support to
> enforce the class relations.

AISB, that is wrong (if "Javascript" is understood, as you do, as a
collection of ECMAScript implementations that include JScript).


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

Jonathan Fine

unread,
Aug 1, 2009, 7:29:26 AM8/1/09
to
Thomas 'PointedEars' Lahn wrote:
> Lasse Reichstein Nielsen wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>> [Does JavaScript have classes and instances?]
>>> I thought this might be a good question for the FAQ.
>>> http://www.jibbering.com/faq/
>> Is it frequently asked? :)
>>
>> How about just:
>>
>> A: No, Javascript has no language support for traditional class based
>> programming. A programmer can, and often do, create objects and treat
>> them as being from the same "class", but this only works as long as
>> everybody stays with the abstraction. There is no language support to
>> enforce the class relations.
>
> AISB, that is wrong (if "Javascript" is understood, as you do, as a
> collection of ECMAScript implementations that include JScript).

I'm not sure I knew that already. Thank you, Thomas. Here's a URL.
http://msdn.microsoft.com/en-us/library/7y3sea6h(VS.80).aspx

In the FAQ I read:
===
2.2 What is JScript?

JScript is Microsoft's implementation of ECMAScript.

Questions that are specific to Microsoft's JScript may also be
appropriately asked at: microsoft.public.scripting.jscript.
===

Perhaps something could be added to 2.2 that allows us to ignore the
JScript extensions in the rest of the FAQ.

--
Jonathan

Thomas 'PointedEars' Lahn

unread,
Aug 1, 2009, 8:01:42 AM8/1/09
to
Jonathan Fine wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Lasse Reichstein Nielsen wrote:
>>> Jonathan Fine <jf...@pytex.org> writes:
>>> [Does JavaScript have classes and instances?]
>>>> I thought this might be a good question for the FAQ.
>>>> http://www.jibbering.com/faq/
>>> Is it frequently asked? :)
>>>
>>> How about just:
>>>
>>> A: No, Javascript has no language support for traditional class based
>>> programming. A programmer can, and often do, create objects and treat
>>> them as being from the same "class", but this only works as long as
>>> everybody stays with the abstraction. There is no language support to
>>> enforce the class relations.
>> AISB, that is wrong (if "Javascript" is understood, as you do, as a
>> collection of ECMAScript implementations that include JScript).
>
> I'm not sure I knew that already.

How surprising. I told you several times before.

> Thank you, Thomas. Here's a URL.

You must be very proud of yourself now.

> [...]


> In the FAQ I read:
> ===
> 2.2 What is JScript?
>
> JScript is Microsoft's implementation of ECMAScript.
>
> Questions that are specific to Microsoft's JScript may also be
> appropriately asked at: microsoft.public.scripting.jscript.
> ===
>
> Perhaps something could be added to 2.2 that allows us to ignore the
> JScript extensions in the rest of the FAQ.

Sounds much like security by obscurity, a concept no documentation and
certainly no FAQ should be based upon. JScript .NET exists and has
practical applications. It is complete utter nonsense to attempt
to conceal its existence or ignore it in the FAQ.

Jonathan Fine

unread,
Aug 1, 2009, 8:27:58 AM8/1/09
to
Thomas 'PointedEars' Lahn wrote:
> Jonathan Fine wrote:

[snip]

>> In the FAQ I read:
>> ===
>> 2.2 What is JScript?
>>
>> JScript is Microsoft's implementation of ECMAScript.
>>
>> Questions that are specific to Microsoft's JScript may also be
>> appropriately asked at: microsoft.public.scripting.jscript.
>> ===
>>
>> Perhaps something could be added to 2.2 that allows us to ignore the
>> JScript extensions in the rest of the FAQ.
>
> Sounds much like security by obscurity, a concept no documentation and
> certainly no FAQ should be based upon. JScript .NET exists and has
> practical applications.

JScript has a 'class' extension, which is a language built-in (linked to
the 'class' reserved word that JavaScript has but does not use). It has
other extensions also.

I think it better not to describe these extensions in the FAQ (although
I'm not opposed to a JScript appendix, if useful).

I'm suggesting adding a statement such as:
===
JScript has features not in the ECMA standard. Some of the statements
in the FAQ require qualification when applied to JScript.
===

> It is complete utter nonsense to attempt
> to conceal its existence or ignore it in the FAQ.

I agree (although I'd use different words). Fortunately, no-one on this
thread is suggesting that.

--
Jonathan

Thomas 'PointedEars' Lahn

unread,
Aug 1, 2009, 11:23:16 AM8/1/09
to
Jonathan Fine wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Jonathan Fine wrote:
>>> In the FAQ I read:
>>> ===
>>> 2.2 What is JScript?
>>>
>>> JScript is Microsoft's implementation of ECMAScript.
>>>
>>> Questions that are specific to Microsoft's JScript may also be
>>> appropriately asked at: microsoft.public.scripting.jscript.
>>> ===
>>>
>>> Perhaps something could be added to 2.2 that allows us to ignore the
>>> JScript extensions in the rest of the FAQ.
>> Sounds much like security by obscurity, a concept no documentation and
>> certainly no FAQ should be based upon. JScript .NET exists and has
>> practical applications.
>
> JScript has a 'class' extension, which is a language built-in (linked to
> the 'class' reserved word that JavaScript has but does not use). It has
> other extensions also.

It does not have a "'class' extension". AISB: JScript (up to 5.8,
currently) and JScript .NET (7.0+) and different versions of the same
language; the former is an implementation of ECMAScript Edition 3. The
latter is an implementation of a Netscape proposal for ECMAScript Edition 4,
based on work of Waldemar Horwat (now at Google) for Netscape JavaScript 2.0
(which was never released except for the Epimetheus test implementation); as
such, it supports class-based inheritance with the `class' keyword, strict
typing and other features, which the former does not.

> I think it better not to describe these extensions in the FAQ (although
> I'm not opposed to a JScript appendix, if useful).

You have yet to provide a valid reason for why not. That said, given the
rate of misconceptions per hour that you continue to demonstrate despite
considerable, readily available documentation and thorough explanations to
the contrary, it is not likely that anyone would take any of your
suggestions for modifying the FAQ seriously.

> I'm suggesting adding a statement such as:
> ===
> JScript has features not in the ECMA standard. Some of the statements
> in the FAQ require qualification when applied to JScript.
> ===

Considered and rejected. The same could be said about any other ECMAScript
implementation, most notably JavaScript. Please do not talk about things
that you do not (yet) understand. There is enough noise from wannabes about
the topic already, and this newsgroup really does not need another VK.
Thanks in advance.

Thomas 'PointedEars' Lahn

unread,
Aug 1, 2009, 11:50:10 AM8/1/09
to
Jonathan Fine wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Please don't. There are enough misinformation and misconceptions out of
>> (mis)interpretation of terms already.
>>
>> As for the interpreter, it remains to be seen a) what is meant by this and
>> b) if it has a feature called a class.
>>
>> Rubbish.
>>
>> Rubbish. You have never set up a custom prototype chain or heard o
>> Function.prototype.call(), have you?
>
> Please suggest something better.

BTDT. Please learn to read or go away.

Jonathan Fine

unread,
Aug 1, 2009, 12:10:58 PM8/1/09
to
Thomas 'PointedEars' Lahn wrote:

[snip]

>> I'm suggesting adding a statement such as:
>> ===
>> JScript has features not in the ECMA standard. Some of the statements
>> in the FAQ require qualification when applied to JScript.
>> ===
>
> Considered and rejected.

I think what you mean here is that you're against it.

> The same could be said about any other ECMAScript
> implementation, most notably JavaScript.

That's a good point. I've got the impression that JavaScript is much
closer to the ECMA standard than JScript. What do you think, Thomas?

BTW, "2.1 What is ECMAScript?" in the FAQ tells us that JavaScript and
JScript may differ in host objects (such as 'document'). But I didn't
find anything here that tells me that there are major changes in the
language itself (such as the behaviour associated with reserved words
such as 'class').

> Please do not talk about things that you do not (yet) understand.

I find that by talking about things I don't understand, particularly
with those who know more and enjoy sharing their knowledge, is a very
good way to learn and understand.

So I'm sorry, Thomas, but I won't follow your advice here.

[snip]

--
Jonathan

Jorge

unread,
Aug 1, 2009, 12:15:41 PM8/1/09
to
On Aug 1, 5:23 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>
> Considered and rejected.

That's Lahn arrogating himself the powers.

> (...) Please do not talk about things


> that you do not (yet) understand.

There's no evidence of that in what he's said so far.

And how do you dare to say so when you don't refrain from screwing it
up with closures at each and every occasion ?
("despite the fact that you do not (yet !) understand them ?")

> There is enough noise from wannabes about
> the topic already, and this newsgroup really does not need another VK.

Your chronic insufferable rudeness is (not really) amusing.
--
Jorge

Jonathan Fine

unread,
Aug 1, 2009, 12:36:31 PM8/1/09
to
Was Re: FAQ suggestion: Does JavaScript have classes and instances?

Jorge wrote (of Thomas):


> On Aug 1, 5:23 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>

> Your chronic insufferable rudeness is (not really) amusing.

The FAQ says (http://www.jibbering.com/faq/#posting):

Avoid being unnecessarily rude,
but do not complain about other rude posts.


Generally, I ignore off-topic content in posts to this newsgroup.
Similarly, I usually ignore content I consider to be rude.

If a post contains a mixture rude and on-topic content, I try to ignore
the material I find to be rude, and respond positively to the on-topic
content (even if I don't agree with it).


I think (or at least hope) that following the advice in the FAQ about
rudeness will be good for this group.

--
Jonathan

Thomas 'PointedEars' Lahn

unread,
Aug 1, 2009, 12:48:04 PM8/1/09
to
Jonathan Fine wrote:
> Thomas 'PointedEars' Lahn wrote:
>>> I'm suggesting adding a statement such as:
>>> ===
>>> JScript has features not in the ECMA standard. Some of the statements
>>> in the FAQ require qualification when applied to JScript.
>>> ===
>> Considered and rejected.
>
> I think what you mean here is that you're against it.

Exactly.

>> The same could be said about any other ECMAScript
>> implementation, most notably JavaScript.
>
> That's a good point. I've got the impression that JavaScript is much
> closer to the ECMA standard than JScript. What do you think, Thomas?

I think you are relying too much on your impressions and intuition and too
little on readily available facts.

> BTW, "2.1 What is ECMAScript?" in the FAQ tells us that JavaScript and
> JScript may differ in host objects (such as 'document').

Then that needs to be corrected as `document' is a DOM feature, not a
language feature.

> So I'm sorry, Thomas, but I won't follow your advice here.

You are free to continue making a fool of yourself here, of course. Just
don't assume anyone will continue to take the time to notice it and correct
you where you are wrong if you continue to post in this manner.

There is a difference between not knowing everything and politely asking
about the parts that one does not understand, and that which you display:
presumptuously stating something as as fact just for the purpose of stating
it and waiting for others to correct you.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

Jonathan Fine

unread,
Aug 1, 2009, 1:07:01 PM8/1/09
to
Thomas 'PointedEars' Lahn wrote:
> Jonathan Fine wrote:

[snip]

> Then that needs to be corrected as `document' is a DOM feature, not a
> language feature.
>
>> So I'm sorry, Thomas, but I won't follow your advice here.
>
> You are free to continue making a fool of yourself here, of course. Just
> don't assume anyone will continue to take the time to notice it and correct
> you where you are wrong if you continue to post in this manner.

Thomas, I think you've snipped too much from the post you are replying
to. You've removed your advice, and the reason I gave for not following
your advice.

I am grateful to those who point out mistakes in what I post, and hope
that any future errors on my part on this list will be corrected.

I do, of course, prefer to be corrected with kindness and good humour.

--
Jonathan

Jorge

unread,
Aug 1, 2009, 2:09:15 PM8/1/09
to

You think right, it would be good. But you're not alone here. And he's
well known for being systematically unable/unwilling to "Avoid being
unnecessarily rude", despite it being in the same point of the same
URL of the same FAQ he repeatedly advises others to read and follow. I
suspect that you're going to get nothing similar in return for your
good manners -I wouldn't overestimate him so much-, nevertheless, I
wish you good luck.
--
Jorge

Jonathan Fine

unread,
Aug 1, 2009, 2:54:49 PM8/1/09
to

Thomas knows a lot about JavaScript. It's a pity that other things get
in the way of he and I discussing it together.

--
Jonathan

matt prokes

unread,
Aug 1, 2009, 3:23:19 PM8/1/09
to
Mmmmm actually pointed ears is right, you can simulate traditional OOP
concepts in javascript but at the end of the day javascript is a
functional language and attempting to graft OOP concepts on a
functional language is exactly that.. A graft..

Here is an example that would invalidate the classical OOP example
that I had described earlier.

var t = function(x){
this.call=function(){alert(x);};
this.change=function(r){x=r;};
}

Now by all appearances this appears to be a top level class with two
methods inside it.

var e = new t('test');
e.call();
alert: test

Its NOT though, this is a programming paradigm that has been created
to simulate OOP programming, that doesn't mean though that it is
invalid, wrong, or syntactically incorrect. Infact many programming
paradigms have been erected out of Javascript, and thats JUST FINE
(see YUI vs. JQuery)!

Here is an example that invalidated traditional OOP.

var x = new e.change("rrrrrrr");
e.call();
alert: rrrrrrr

Whoa! did we just create a closure out of a method? YES WE DID.
Javascript is a functional language, not OOP. The new keyword
basically means new closure! Any function can create a new closure,
with its own prototype, etc.

Yet our method didn't go anywhere, in-fact if you wanted to you could
do this.

e.change('hi');
e.call();
alert: hi

In the end its all about functional programming and expressing the
language as clear as possible. Everyone has their own way of getting
the job done. Really this shouldn't be an argument about who has the
more knowledge about javascript, its not about street cred, its about
helping people.

The Natural Philosopher

unread,
Aug 1, 2009, 3:54:11 PM8/1/09
to
matt prokes wrote:
> Infact many programming
> paradigms have been erected out of Javascript, and thats JUST FINE
> (see YUI vs. JQuery)!
>
some say the whole language is like a giant erection...

>
> In the end its all about functional programming and expressing the
> language as clear as possible. Everyone has their own way of getting
> the job done. Really this shouldn't be an argument about who has the
> more knowledge about javascript, its not about street cred, its about
> helping people.

Huh? had me fooled..;-)

Jonathan Fine

unread,
Aug 1, 2009, 4:44:35 PM8/1/09
to
matt prokes wrote:
> Mmmmm actually pointed ears is right, you can simulate traditional OOP
> concepts in javascript but at the end of the day javascript is a
> functional language and attempting to graft OOP concepts on a
> functional language is exactly that.. A graft..

Most people on the thread have said that JavaScript doesn't have
built-in classes, but that you can build code that provides class-like
behaviour. I think there's a consensus here.

I also agree that any 'class-building' in JavaScript must be aware of
the practical implications of relevant JavaScript fundamentals.


> Here is an example that would invalidate the classical OOP example
> that I had described earlier.
>
> var t = function(x){
> this.call=function(){alert(x);};
> this.change=function(r){x=r;};
> }
>
> Now by all appearances this appears to be a top level class with two
> methods inside it.
>
> var e = new t('test');
> e.call();
> alert: test

I'd have found your example clearer if you'd used the names 'get' and
'set'. My standard example of closures is:

function make_get_set(init){
return [
function(){return init;},
function(value){init = value}
];
}

I'd them write your example as
var T = function(init){
var tmp = make_get_set(init);
this.get = tmp[0];
this.set = tmp[1];
tmp = undefined; // Sort of optional.
}

What would make T a class would be adding methods to the prototype
object for T. Without that, T is little more than a record (which can
be useful).

> Its NOT though, this is a programming paradigm that has been created
> to simulate OOP programming, that doesn't mean though that it is
> invalid, wrong, or syntactically incorrect.

I don't find your example to be helpful. To me, it neither illustrates
a language feature nor arises from a real-world situation.


> Infact many programming
> paradigms have been erected out of Javascript, and thats JUST FINE
> (see YUI vs. JQuery)!
>
> Here is an example that invalidated traditional OOP.
>
> var x = new e.change("rrrrrrr");
> e.call();
> alert: rrrrrrr
>
> Whoa! did we just create a closure out of a method? YES WE DID.
> Javascript is a functional language, not OOP.

According to Wikipedia, JavaScript is NOT a functional language:
http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Functional_languages
http://en.wikipedia.org/wiki/Functional_programming

BTW, Crockford in his book (p4) implies that JavaScript is a functional
programming language.

BTW, XSLT and TeX's macro expansion language are functional programming
languages.

But in JavaScript you can do assignment, and that's a real no-no in
functional programming.


> The new keyword
> basically means new closure! Any function can create a new closure,
> with its own prototype, etc.

Well, I prefer to think of it as a complex way of adding an object to
the prototype/inheritance tree, whose parent is the
Constructor.prototype. And in addition to adding the object supplying
an initialisation.

There are other ways to make a closure. It's really easy to make a
closure in a function
// Top level.
var stack = [];
var push = function(obj){
stack.push(obj);
};

Now do
push(0);
and there's a closure going on (although not a sensible or useful one).

>
> Yet our method didn't go anywhere, in-fact if you wanted to you could
> do this.
>
> e.change('hi');
> e.call();
> alert: hi

> In the end its all about functional programming and expressing the
> language as clear as possible. Everyone has their own way of getting
> the job done. Really this shouldn't be an argument about who has the
> more knowledge about javascript, its not about street cred, its about
> helping people.

I agree that to go far in JavaScript programming you have to understand
closures. But you also have to understand the prototype/inheritance
tree and the behaviour of new (or create). And quite a few other things
besides.

I'd include in this list an ability to program classes and inheritance.

--
Jonathan

Dr J R Stockton

unread,
Aug 1, 2009, 3:05:22 PM8/1/09
to
In comp.lang.javascript message <UJSdnW0XZJV15e7XnZ2dnUVZ8lBi4p2d@bright
view.co.uk>, Sat, 1 Aug 2009 00:06:18, Jonathan Fine <jf...@pytex.org>
posted:

>
>As I recall from yesterday, I thought that first sentence was fairly
>good. It's a real shame that the ECMA standard is not available as
>HTML. Then we'd be able to link to it.

It is available (unless recently withdrawn) as PDF, which can be linked
to, and also downloaded.

The FAQ has links to it. My site has links to it. The first result of
a Google search for ecma-262 HTML finds "ECMAScript Language
Specification (HTML version)". Cuil likewise. The Wikipedia page
"ECMAScript" has links to it.

The ISO/IEC version is as readily available, too.

It's a good idea to read the newsgroup c.l.j and its FAQ. See below.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF3 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Dr J R Stockton

unread,
Aug 1, 2009, 3:19:26 PM8/1/09
to
In comp.lang.javascript message <XZydnYWvDrvf6-nXnZ2dnUVZ8gqdnZ2d@bright
view.co.uk>, Sat, 1 Aug 2009 18:07:01, Jonathan Fine <jf...@pytex.org>
posted:

>I am grateful to those who point out mistakes in what I post, and hope
>that any future errors on my part on this list will be corrected.
>
>I do, of course, prefer to be corrected with kindness and good humour.

Then you need to kill-file Thomas and perhaps David.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 7.


Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.

I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/> unsupported.

Dr J R Stockton

unread,
Aug 1, 2009, 3:17:45 PM8/1/09
to
In comp.lang.javascript message <4A745DE4...@PointedEars.de>, Sat,
1 Aug 2009 17:23:16, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:
>
>Considered and rejected.

Fortunately, you do not have the authority to determine that.

--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.


Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.

Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

Dr J R Stockton

unread,
Aug 1, 2009, 3:16:01 PM8/1/09
to
In comp.lang.javascript message <4A74241...@PointedEars.de>, Sat, 1
Aug 2009 13:16:39, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:

>Lasse Reichstein Nielsen wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>> [Does JavaScript have classes and instances?]
>>> I thought this might be a good question for the FAQ.
>>> http://www.jibbering.com/faq/
>>
>> Is it frequently asked? :)
>>
>> How about just:
>>
>> A: No, Javascript has no language support for traditional class based
>> programming. A programmer can, and often do, create objects and treat
>> them as being from the same "class", but this only works as long as
>> everybody stays with the abstraction. There is no language support to
>> enforce the class relations.
>
>AISB, that is wrong (if "Javascript" is understood, as you do, as a
>collection of ECMAScript implementations that include JScript).

The FAQ should primarily deal with "common javascript". JScript
extensions only work for a dwindling two-thirds of web users.
References to JScript extensions should clearly indicate their status.
In fact, those extensions are not JavaScript.

--
(c) John Stockton, Surrey, UK. ?@