petermichaux at gmail.com
Wed Aug 13 22:20:56 PDT 2008
On Wed, Aug 13, 2008 at 8:26 PM, Kris Zyp <kris at sitepen.com> wrote:
>>> We talked about desugaring classes in some detail in Oslo. During
>>> these exchanges, we discussed several separable issues, including
>>> classes, inheritance, like patterns, and type annotations. I'll avoid
>>> writing more here,
>> Is there more to read elsewhere? I'd like to know concretely what
>> "desugaring classes" means.
> I would too, I assume this is based on Mark's proposal for Classes as Sugar
Thanks for the link.
Mark's proposal looks like something that could perhaps be handled
with macros. What I've thought would be a great way to add classes to
ECMAScript is to give ECMAScript macros and then let folks build their
own class macro libraries. That is essentially what has happened now
but the wrapping of the prototype-based system and the lack of macros
has lead to "ugly" code. Folks are going to continue with their own
wrapping of the built-in prototype system anyway even if there is one
sugar wrapping included in the language. Different situations require
different OOP features. Some situations more complex than others. For
example, if the built-in sugar doesn't have mixins and someone needs
mixins then they will need to wrap exactly the same prototype system
that Mark's proposal wraps.
This brings up an interesting post from what is getting close to a year ago.
On Nov 12, 2007 Brendan Eich wrote:
> On Nov 12, 2007 YR Chen wrote:
> > Macros have been proposed and discussed before - they're somewhere
> > on the wiki. AFAIK, they've been deferred to a future ES5.
> Researchers on the list may be willing to speak to macros with more
> authority than I have. I'll just say that apart from the fun with C-
> like syntax (which can be handled; we're close to specifying standard
> ASTs for ES4), sound hygiene theory is still a research topic. I
> expect good results from academia in a year or so, and hope that TG1
> will take advantage of them.
> In the mean time, I think it would be very wrong to defer syntactic
> conveniences until after macros are done. With macros, conveniences
> that de-sugar in ES4 could be re-specified (and implemented at the
> same time) cheaply, for sure -- but users deserve convenient syntax
> sooner than "after macros".
Given the time lines, will hygienic macros now be ready before or in
time for ES4?
Perhaps classes don't need a hygienic macro system and hygienic macros
can come later.
More information about the Es-discuss