On Nov 10, 2011, at 7:59 AM, Mark S. Miller wrote:

> My previous proposal for class-like sugar for traits composition was not 
> popular. Whereas, in the absence of problem #5, I suspect the traitsjs 
> library would be. As previously observed on this list, traitsjs is more 
> JavaScripty. Ideal would be for JSVMs to magically make traitsjs efficient 
> without requiring any language changes. If this is infeasible, perhaps we 
> should instead be looking for the minimal language change that would enable a 
> revision of traitsjs to run efficiently on ES-nest-next JSVMs.

The http://brendaneich.com/2011/01/harmony-of-my-dreams/#sharp_functions 
proposal, while out of date now, did try to support concise joined/frozen 
functions, joined up to the nearest relevant closure. If that is the 
constructor, you still have a sharp function per method per instance, but if 
the methods use only |this| and their parameters.

How HoBD sharp functions handle |this| was not totally clear. We talked at the 
January meeting about supporting only lexical |this|, only caller |this|, and 
(perhaps in March) "soft binding" where lexical |this| is the default but it 
can be overridden by caller |this|.


> I say ES-next-next because it is too late to consider any such language 
> change for ES-next. However, implementation experiments need not wait.

To revive the HoBD sharp-function idea at this point, I would want to get 
tenative agreement on |this|-binding. Your thoughts welcome.

/be


> 
> 
> On Thu, Nov 10, 2011 at 7:19 AM, Andreas Rossberg <rossb...@google.com> wrote:
> [...]
> No, that's how it works right now. The alternative is to lexically
> close all methods over self at construction time:
> 
>  function Point(x, y) {
>    var self = this
>    self.x = x
>    self.y = y
>    self.move = function(dx, dy) { self.x += dx; self.dy += dy }
>  }
> 
>  function ColorPoint(x, y, color) {
>    var self = this
>    Point.call(self, x, y)
>    self.color = color
>    self.recolor = function(c) { self.color = c }
>  }
> 
> As said, this doesn't play well with prototype inheritance. You have
> to put all methods that refer to self on the object itself. But "inner
> constructors" are straighforward and safe.
> -- 
>     Cheers,
>     --MarkM

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to