Making "super" work outside a literal?

Sean Eagan seaneagan1 at
Wed Jun 22 06:51:37 PDT 2011

On Wed, Jun 22, 2011 at 4:28 AM, Allen Wirfs-Brock
<allen at> wrote:
> On Jun 21, 2011, at 9:55 PM, Brendan Eich wrote:
>> One thing I'm not sure about: whether Object.defineMethod should mutate's internal property, or make a new function object with a different 'super' binding.
> I'm still thinking about this but I'm leaning towards specifying that defineMethod creates a new function and leave it up to implementations to optimize trivial cases where that is unnecessary like:
>   Object.defineMethod(obj, "foo", function () {});

Creating extra function objects is a cost that would be avoided by a
dynamic super approach.  Why would it not be necessary in that
"trivial case"?  Do you mean to say that |Object.defineMethod(o,
"method", method).method !== method| ?  That would be quite surprising
to a user, especially if it is conditionally true depending on whether
|method| is an optimizable "trivial case".

As I mentioned earlier Object.defineMethod is non-orthogonal in that
it doesn't allow you to specify any property descriptor attributes for
methods, you would be stuck with whatever the default values would be
for methods.

Also, you haven't addressed the |Object.defineMethod(proxy, "method",
method)| case.

> Also, Object.defineProperty used to define a accessor property get or set function probably should also have this semantics.  Because 'super' is new that seems like an upwards compatible extension.

This is inconsistent.  You are are not re-binding super for
|Object.defineProperty(o, "method", {value: methodThatUsesSuper})| but
you are for |Object.defineProperty(o, "property", {get:
getterThatUsesSuper, set: setterThatUsesSuper})|.

This also doesn't address |Object.defineProperty(o, "method", {get:

> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Sean Eagan

More information about the es-discuss mailing list