Look Ma, no "this" (was: ECMAScript Harmony)

Michael Daumling mdaeumli at adobe.com
Tue Aug 19 18:04:19 PDT 2008


I sure did. Sorry for the noise.

Michael

-----Original Message-----
From: Mark S. Miller [mailto:erights at google.com] 
Sent: Tuesday, August 19, 2008 6:03 PM
To: Michael Daumling
Cc: Peter Michaux; brendan at mozilla.org; es4-discuss at mozilla.org; TC39;
es3.x-discuss at mozilla.org
Subject: Re: Look Ma, no "this" (was: ECMAScript Harmony)

On Tue, Aug 19, 2008 at 5:54 PM, Michael Daumling <mdaeumli at adobe.com>
wrote:
> Just a side note: The code below would create three Function objects
per
> Point instance. Some may argue that the days of having little memory
are
> long gone, but we still have small devices plus a garbage collector
that
> may need to iterate through live objects, including three Function
> objects per Point. Long live prototype objects.

Michael, I think you missed the note at the end of the message you're
quoting:


> [...] However, the
> above technique is impractical today because of the extra allocation
> cost -- one closure per method per instance. But as Dan Ingalls says
> "you can cheat if you don't get caught." The above desugaring shows
> how to define the *semantics* of the class construct. The actual
> behavior of the class construct must not be observably different from
> some such desugaring. But in a class-aware implementation, it should
> of course perform better than you'd expect from this desugaring.
>
> In the Caja project, we are exploring whether this optimization can
> even be provided as a source-to-source translation:
>
<http://google-caja.googlecode.com/svn/trunk/doc/html/cajitaOptimization
> /index.html>.
> It's not yet clear that the idea is practically implementable by this
> technique
>
<http://groups.google.com/group/google-caja-discuss/browse_thread/thread
> /df6c8ea9a1ca1aa3>.
> But none of these problems should impede a more directly implemented
> optimization.


More information about the Es-discuss mailing list