Re: Making "super" work outside a literal?

On Jun 19, 2011, at 9:13 PM, Axel Rauschmayer wrote: > It wouldn’t be about stealing, but about setting up an object differently: > > var obj = { >foo: function (x) { >super.foo(x); >} > }; > > === VERSUS === > > var obj = {}; > obj.foo = function (x) { >super.foo(x); > }; >

Re: Prototypes as the new class declaration

On Jun 19, 2011, at 9:23 AM, Axel Rauschmayer wrote: >>> Where would the prototype of the new instance come from? Would >>> SkinnedMesh.constructor.prototype point to SkinnedMesh? >> >> Of course -- Allen's proposal just "rotates" the (constructor, prototype) >> pair so the named or "outer" obj

Re: Making "super" work outside a literal?

>>> If you really want to change what super means in a function expressed in an >>> object initialiser, I'd like to see the exact use-case. >> >> The only use case would be assigning a function that uses "super" to a >> property. > > Such an assignment might need the meaning of super to remain

Re: Making "super" work outside a literal?

On Jun 19, 2011, at 7:32 PM, Axel Rauschmayer wrote: >>> I don’t know how problematic this would be, but if "super" is an internal >>> property of a function, then it could be updated whenever such a function >>> is set as the value of a property. >> >> No, that doesn't work. Both for cases whe

Re: Making "super" work outside a literal?

>> I don’t know how problematic this would be, but if "super" is an internal >> property of a function, then it could be updated whenever such a function is >> set as the value of a property. > > No, that doesn't work. Both for cases where the function author really did > mean the proto-object

Re: Proposal: paren-free function calls and definitions

On Jun 19, 2011, at 4:04 PM, Brendan Eich wrote: > On Jun 19, 2011, at 3:17 PM, Claus Reinke wrote: > >> https://github.com/clausreinke/jstr/tree/master/es-discuss >> >> You can find there the proposal text, with motivation, grammar changes, >> semantics (entirely via desugaring to existing syn

Re: Proposal: paren-free function calls and definitions

On Jun 19, 2011, at 3:17 PM, Claus Reinke wrote: > https://github.com/clausreinke/jstr/tree/master/es-discuss > > You can find there the proposal text, with motivation, grammar changes, > semantics (entirely via desugaring to existing syntax), and related issues, > as well as a prototype implem

Proposal: paren-free function calls and definitions

Dear all, following the recent suggestion here that github might be a more suitable forum for kick-starting proposals than this list, I've put together a proposal draft on simple paren-free function calls and definitions: https://github.com/clausreinke/jstr/tree/master/es-discuss You can find t

Re: Making "super" work outside a literal?

On Jun 19, 2011, at 12:54 PM, Axel Rauschmayer wrote: > Makes sense. > > I don’t know how problematic this would be, but if "super" is an internal > property of a function, then it could be updated whenever such a function is > set as the value of a property. No, that doesn't work. Both for ca

Re: Making "super" work outside a literal?

Makes sense. I don’t know how problematic this would be, but if "super" is an internal property of a function, then it could be updated whenever such a function is set as the value of a property. I’m increasingly decomposing object literals into assignments to properties, especially if a liter

Re: Making "super" work outside a literal?

On Jun 19, 2011, at 10:20 AM, Axel Rauschmayer wrote: > It would be nice if "super" could work in any method and not just those > methods that are defined inside an object literal. Then, a method would have > to know what object it resides in, e.g. via an implicit parameter. We wish to avoid an

Re: Making "super" work outside a literal?

Note that "this" always points to where the search for a method starts (the “receiver” of the method call), there (current) beginning of the prototype chain. "here" points to where a method has been found. This is a static aspect, except that turning it into a property of a function would make i

Re: Making "super" work outside a literal?

On Sun, Jun 19, 2011 at 10:56 AM, Axel Rauschmayer wrote: > Exactly! > > One way to do this is to give methods an implicit parameter "here" (the > object in which a method was found during dispatch), in addition to "this". In some variant, "here" might make it possible to do what I was describin

Re: Making "super" work outside a literal?

Exactly! One way to do this is to give methods an implicit parameter "here" (the object in which a method was found during dispatch), in addition to "this". Then super.foo(x, y) would desugar to Object.getPrototypeOf(here).foo.call(this, x, y) With call() and apply(), you would

Re: Making "super" work outside a literal?

On Sun, Jun 19, 2011 at 10:20 AM, Axel Rauschmayer wrote: > It would be nice if "super" could work in any method and not just those > methods that are defined inside an object literal. Then, a method would have > to know what object it resides in, e.g. via an implicit parameter. So you want "su

Making "super" work outside a literal?

It would be nice if "super" could work in any method and not just those methods that are defined inside an object literal. Then, a method would have to know what object it resides in, e.g. via an implicit parameter. -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.

Re: [Harmony Proxies] Proposal: Property fixing

Le 19/06/2011 17:43, Tom Van Cutsem a écrit : > 2011/6/17 David Bruant > > > Symetrically to the forwarding of defineProperty, maybe that > getOwnPropertyDescriptor could be forwarded too (requires to call > the getOwnPropertyDescriptor trap for non-config

Prototypes as the new class declaration

>> - Object.getPrototypeOf(obj).constructor: should it always point to the >> constructor? Or is it a reference to a class construct (either old-style or >> new-style)? Most of the code will probably only use it as the operand of the >> "new" operator. > > I'm not sure what you mean here. The

Re: [Harmony Proxies] Proposal: Property fixing

On Sun, Jun 19, 2011 at 4:36 AM, David Bruant wrote: > ** > Le 17/06/2011 23:21, Mark S. Miller a écrit : > > On Fri, Jun 17, 2011 at 1:50 PM, David Bruant wrote: > >> Le 17/06/2011 21:41, David Bruant a écrit : >> >> >> To summurize fixed propeties property-specific trap behaviors, one could >>

Re: [Harmony Proxies] Proposal: Property fixing

On Sat, Jun 18, 2011 at 4:44 PM, David Bruant wrote: > Le 19/06/2011 00:30, Mark S. Miller a écrit : > > Hi David, yes, that code is just a stale illustrative example. This > > abstraction itself is not being used, and the code predates many > > changes to the proxy API that render it invalid. An

Re: Prototypes as the new class declaration

>> Where would the prototype of the new instance come from? Would >> SkinnedMesh.constructor.prototype point to SkinnedMesh? > > Of course -- Allen's proposal just "rotates" the (constructor, prototype) > pair so the named or "outer" object is the prototype. The only thing I don’t understand i

Re: May the defineProperty method of a proxy handler throw a TypeError?

On Sun, Jun 19, 2011 at 8:22 AM, Tom Van Cutsem wrote: > 2011/6/18 David Bruant > >> Le 18/06/2011 00:47, David Flanagan a écrit : >> > Given that the fixed properties proposal is adding a return value to >> > defineProperty, perhaps returning false would be a suitable way to >> > reject a prope

Re: Possible Loophole (was: Proposal: Property fixing)

Le 19/06/2011 16:53, Tom Van Cutsem a écrit : > 2011/6/17 David Bruant > > > Le 17/06/2011 22:20, Mark S. Miller a écrit : >> Hmmm. This suggests a loophole that might help out on some of the >> proxy cases we're concerned about. I know of no universal >>

Re: [Harmony Proxies] Proposal: Property fixing

2011/6/19 David Bruant > Le 19/06/2011 00:30, Mark S. Miller a écrit : > > Hi David, yes, that code is just a stale illustrative example. This > > abstraction itself is not being used, and the code predates many > > changes to the proxy API that render it invalid. And even then, it was > > sloppy

Re: [Harmony Proxies] Proposal: Property fixing

2011/6/17 David Bruant > ** > Symetrically to the forwarding of defineProperty, maybe that > getOwnPropertyDescriptor could be forwarded too (requires to call the > getOwnPropertyDescriptor trap for non-configurable properties) and the > return value could be used to redefine writable on the prox

Re: Proxy forwarding handlers and accessor properties

Le 19/06/2011 15:53, Tom Van Cutsem a écrit : > I agree with all of David's points. I wonder though: would it make > more sense if we'd spec. the "get" trap of Proxy.Handler as: > > get: function(name, proxy) { > let val = this.target[name]; > return typeof val === "function" ? val.bind(t

Re: May the defineProperty method of a proxy handler throw a TypeError?

2011/6/18 David Bruant > Le 18/06/2011 00:47, David Flanagan a écrit : > > Given that the fixed properties proposal is adding a return value to > > defineProperty, perhaps returning false would be a suitable way to > > reject a property definition. > Yes, I think such an API could work. > I wo

Re: Possible Loophole (was: Proposal: Property fixing)

2011/6/17 David Bruant > ** > Le 17/06/2011 22:20, Mark S. Miller a écrit : > > Hmmm. This suggests a loophole that might help out on some of the proxy > cases we're concerned about. I know of no universal constraint that a > proxy's handler could violate if it could 1) trap attempts to change th

Re: Proxy forwarding handlers and accessor properties

I agree with all of David's points. I wonder though: would it make more sense if we'd spec. the "get" trap of Proxy.Handler as: get: function(name, proxy) { let val = this.target[name]; return typeof val === "function" ? val.bind(this.target) : val; } Then both method & accessor invoc

Re: [Harmony Proxies] Proposal: Property fixing

Le 17/06/2011 23:21, Mark S. Miller a écrit : > On Fri, Jun 17, 2011 at 1:50 PM, David Bruant > wrote: > > Le 17/06/2011 21:41, David Bruant a écrit : >> >> To summurize fixed propeties property-specific trap behaviors, >> one could say that: >> - defi