On Thu, Aug 14, 2008 at 12:49 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Aug 13, 2008, at 11:52 PM, Peter Michaux wrote:
[snip]
>> I use OOP frequently in JavaScript but it isn't usually the style in
>> ES3 or class-based like proposed ES4. It's the style I think is
>> appropriate to the situation. That may draw a slight performance
>> penalty but the code is certainly more robust than the ES3 style.
>
> Sorry, curious again: what do you mean by ES3 style?
The direct use of the constructor/prototype system
function MyClass() {}
MyClass.prototype.foo = function(){};
-----
Most of the time, I'm using "hashes of closures" as Paul Graham calls
them or "durable objects" as Douglas Crockford calls them. One very
useful part of this system is the function-valued properties of the
returned object can be moved to another object or otherwise passed
around. "this" doesn't matter or need to be fixed if one of these
properties is used as a callback because there is no use of "this" and
it is not a message passing OOP system.
Another option is returning a single function from a constructor where
the returned function is a dispatch and takes message strings. This
manually built message passing system can give getters, setters,
catch-alls, multiple inheritance, mixins, private, public, etc without
needing the language to support any of them. If JavaScript didn't have
prototype-based inheritance it could be built this way.
A multi-method system could be built quite easily.
There are so many ways to do OOP and so many opinions on how it should
be done, it is great the language allows people to build the system
appropriate to their situation.
I can understand the desire to have some form of OOP support built
into the language and that already exists with prototypes. It seems
that now the idea for Harmony is adding sugar with Object.freeze on
top to give the appearance of classes partly so that type checking is
possible. I suppose people can use this built-in sugar when it
appropriate and continue to build their own OOP systems as needed
(perhaps less frequently. Getting agreement on what the class sugar
should provide, if that is going to be the approach. But could this
goal delay Harmony too long and cause another Oslo a year from now? By
that time, if types/classes are out of Harmony, it may be possible to
have some of the valuable "programming in the small" features
scheduled to be included in IE9. Actually seeing any Harmony features
in IE9 will be a sign of major success, I think.
Peter
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
