Thanks Keryx,
Some interesting information. Nice point on the arrays actually being
objects. At one point you did mention _javascript_ is object-based, then
in another, prototype-based. So that confuses me a little. If your
point is that it is object-based and uses prototype to inherit objects,
I think I understand your point.
Still confuses me though - if someone is object-orientated but is in
essence prototype-based (with regards to object, inheritance, etc), why
is it incorrect to say _javascript_ is prototype-based?
Cheers,
Anthony.
Keryx Web wrote:
Brett
Patterson skrev:
> I am in the middle of a conversation with this guy who says that
_javascript_ is an object-oriented language. Is he correct? Could you
please site some references?
I have read the whole thread up until now, but will answer your
starting message, since I am not addressing a single specific
respondent.
I am in charge of developing DOM Scripting courses for the Curriculum
Framework of the WaSP Education Task Force[1]
I have therefore tried to read every single resource about _javascript_,
ECMAScript and the DOM that has been written from a computer science
perspective. There are not that many, which might be a reason behind
the confusion.
Anyway: _javascript_ (a term owned by Sun, licensed to Mozilla, and used
by all browser vendors but Microsoft) is in all essence, as Liorean has
stated, a superset of ECMAScript 3.0. That is also the sentiment of
Brendan Eich - and should therefore be taken as a final word. (Anthony
was indeed wrong about this.) JScript as implemented in Internet
Explorer is roughly equivalent, but deviates in some small ways.
_javascript_ is a mix of Self, Scheme and C (according to the ECMAScript
3.1 draft, the "love child between Scheme and C" according to Brendan
Eich).
_javascript_ is indeed Object Oriented, but even though every script is
run within a host object - usually the window object of a browser - a
procedural style is possible to use. 90's DHTML scripts were usually
procedural and used document.write (which is not ECMAScript but part of
the DOM) in a way that reminds me of *standard streams*, which could be
provided by the host object, but usually aren't.
Public, private and protected methods and properties are not easily
implemented. Object Oriented design patterns (singletons, factories,
registry, adaptors...) can usually be emulated. Sometimes this is only
done through considerable wizardry using concepts like lambda and
closures.
ECMAScript 4.0 aka _javascript_ 2.0 was supposed to get a limited class
based inheritance mechanism to *complement* the prototype based one we
use today. Those plans have been halted. ECMAScript "Harmony" will most
probably *not* get any class based inheritance.
(At least two _javascript_ engines (V8 and Squirrelfish Extreme) emulate
class based object creation as part of their just in time compilation,
but that really is a compiler issue.)
ECMASCript 3.1 will get a few new methods to facilitate easier
inheritance patterns. E.g. Object.freeze(). Many popular libraries also
have methods that facilitate OO-patterns.
As old school cut' n' paste coding is getting superseded by libraries
procedural code is becoming less seen and OO-style coding is getting
more used.
Indeed, using object chaining in JQuery et al, the programming is even
well on its way to become *declarative*.
Summary:
1. _javascript_ *is* OO.
2. _javascript_ uses a prototypal - class-less - inheritance mechanism.
3. Anyone writing a script can use procedural style, OO-style or even
make forays into a declarative style.
Nit picking on some stuff in the thread:
_javascript_ has no pure hash-tables, aka associative arrays. Object
properties can be used to emulate associative arrays, though. A PHP
programmer will feel very limited, though.
A _javascript_ object *is* not an array (once again Anthony got it
wrong). It can have methods as well as properties. <aside>Arrays
are however objects, and confusingly
typeof [ 1, 2 ]
evalutes to "object", not "array". A major design flaw.
The best known way to test for an array is:
Object.prototype.toString.apply(value) === '[object Array]'
Discovered by Mark Miller of Google.</aside>
>From a very strict computer science point of view averything in
_javascript_ is *not* an object. (No matter how much Alex "Dojo" Russel
et al. reiterates that mantra.) In practice everything is. _javascript_
has got a few "primitives" (numbers, strings, booleans, undefined).
Whenever a primitive is referenced with an OO-syntax it is converted
into its corresponding wrapper object. This was modeled after Java
according to Brendan, and he has stated that it probably was a bad
idea. (Search the ES4 mailing list for a reference.)
Lars Gunther
Sources:
MDC, including https://developer.mozilla.org/En/About_JavaScript
ES 3.0 spec
ES 3.1 spec draft
"_javascript_, The Definitive Guide" (latest edition)
ES3.1 mailing list
ES 4/Harmony mailing list
Doug Crockfords site and book ("_javascript_, the good parts")
Numerous other _javascript_ books
1.
http://www.webstandards.org/2008/07/31/announcing-the-wasp-curriculum-framework/
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
|
