Making "super" work outside a literal?

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Jun 24 03:08:31 PDT 2011


On Jun 23, 2011, at 11:16 PM, Brendan Eich wrote:

> On Jun 23, 2011, at 2:00 PM, Sean Eagan wrote:
> 
>> Ok, sorry it took me so long, but I agree that the general idea of
>> Object.defineMethod is the best solution.  I think it can be improved
>> upon though, by adding the following:
>> 
>> Ability to use any property descriptor attributes when defining methods.
>> Ability to assign accessor getters and setters as well which use the
>> assigned to object as |super|.
>> Avoid having to add a "defineMethod" proxy trap.
> 
> Great point! That would be something to avoid.

I don't think that defineMethod implies the need for an additional proxy trap. defineMethod essentially first conditionally transforms its function parameter and then does a [[Put]] of that value.  From a proxy perspective can simply be view as a function that does a [[Put]].
> 
> 
>> Here are the two potential solutions I have in mind for this:
>> 
>> * Have Object.defineProperty create new functions with updated
>> [[Super]] when the "value", "get", or "set" attributes are functions
>> that use super.
> 
> This seems enough, you're right.

I agree that  the Object.defineProperty should apply defineMethod semantics when processing a "get" or "set" attributed as these are essentially method definition operations.

I don't think it should do so for "value".  It is possible that a data property is being used as a function valued data store rather than as a method binding on an object. For example, a property might be used to store a callback function.  Such a data-value function might reference |super|.  For example, it might be a function with a bound |this| that also uses |super|.  I don't thing we want the |super| binding changing in such situations.  (Looking at this another way, if such a transformation of done in Object.defineProperty and not in [[DefineOwnProperty]] then there would be a semantic difference between obj.prop=func and Object.defineProperty(obj,"prop",{value:func}) that we probably don't want to have.)

I introduced the concept of defineMethod to define a means to explicitly disambiguate  the attachment of a method and the setting of a data property value in situations where it makes a difference.  People will run into bugs where they used = or defineProperty with the value attribute when they really need to do a defineMethod but at least with defineMethod there is a way to fix this bug.


> 
> 
>> * Add an Object.defineSuperProperty which is the same as the existing
>> Object.defineProperty except that it creates new functions with
>> updated [[Super]] when the "value", "get", or "set" attributes are
>> functions that use super.  It could potentially throw if no super
>> functions are passed.  This one may still require a
>> "defineSuperProperty" proxy trap, not sure.
> 
> I'm not sure we need this one. Does it really avoid the proxy trap addition?

me neither
> 
> 
>> Also, I wonder if there is a need for a Function.prototype.isSuper
>> similar to Function.prototype.isGenerator?
> 
> A generator is a kind of function. 'super' evaluates to an object. So this seems misplaced, but first, what use-case does it serve? Can you show an example that motivates it?

I think both of these fall into the realm of reflection.  As such, I would want to keep them off the instances. If we need them I would make them:
  Function.isGenerator(func)
  Function.usesSuper(func)

however, WRT usesSuper, I isn't clear if it is anymore necessary than usesThis, hasNestedFunctions, hasIfStatements, and potentially hundreds of reflective queries that might be made about a function.

Allen


More information about the es-discuss mailing list