class prototype object vs class instance properties

Jeff Dyer jodyer at adobe.com
Mon Aug 20 10:21:26 PDT 2007


> > This "object literal"styleis not congruent to the prototype being a
> > special instance (as in ES3 and 4 built-ins, with Date.prototype
> > having value NaN, et c) . The above code style is clear and easy to
> > read. You have the constructor, then the prototype.
> >
> > It would be nice to have a prototype block, like:
> >
> > class A {
> >
> >   init  : void =  function init()
> >   prototype {
> >
> >   }
> 
> This is something proposed ages ago by Waldemar Horwat (then at
> Netscape) for ES4 -- any time you have
> 
>    prototype function m1(...) {...}
>    prototype function m2(...) {...}
>    prototype function m3(...) {...}
> 
> in some ES4 drafts waldemar wrote, you could instead say
> 
>    prototype {
>      function m1(...) {...}
>      function m2(...) {...}
>      function m3(...) {...}
>    }
> 
> Waldemar's proposal allowed this for any kind of "attribute"
> qualifying a definition, including a namespace IIRC.
> 

That's right.

> I'll bring this up at the next meeting, since you are quite right
> that the current builtins in the reference implementation are chatty.
> 

ActionScript will have something like this soon in its program
configuration feature. It is described here:

http://wiki.ecmascript.org/doku.php?id=proposals:program_configuration

The meaning is slightly different, but maybe not incompatible. In the
above proposal, a configuration expression turns on or off a block of
code, including any embedded definitions. If non-configuration
attributes where used on a block they could be applied to relevant
definitions. Perhaps it should be an error to put definitions in a block
whose attributes don't apply.

Jd



More information about the Es4-discuss mailing list