On Jun 24, 2011, at 3:08 AM, Allen Wirfs-Brock wrote: > 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]].
I hope it's more than a [[Put]]. Normal [[Put]] does not clone its argument. > 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. Can we do better? It seems this may be a "forgotten API", remembered only after painful debugging. > 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) We started out there but ended up on Function.prototype. See https://mail.mozilla.org/pipermail/es-discuss/2011-March/013104.html and the history at http://wiki.ecmascript.org/doku.php?do=revisions&id=strawman%3Agenerators leading to http://wiki.ecmascript.org/doku.php?id=harmony:generators See also https://bugzilla.mozilla.org/show_bug.cgi?id=648355 (esp. comment 3) https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function/isGenerator https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Function#Methods_2 The impetus for putting reflection APIs on Object is mainly because Object.prototype is verboten. Not so with Function.prototype, and calling f.isGenerator() is much sweeter than calling Function.isGenerator(f). The latter must also handle f for all values, whereas the method works via prototypal delegation, so can be trapped by proxies, handled by ad-hoc wrappers, etc. There is a serious issue when adding reflection APIs, of whether to support not only proxies via yet more traps (to be avoided), but also whether delegation via a method name found in an object or any value (possibly some we haven't thought of yet) is better than monkey-patching Function or Function.isGenerator. I do not think we should take the Object-based reflection pattern as something to apply for all predicates that could be called reflective. As an aside, Array.isArray is misplaced -- it should have gone on Object, to avoid the awkward and seemingly oxymoronic full name, and more important: because it can be used on any object. > Function.usesSuper(func) Ah, "uses super" I can understand. Sean's "isSuper" name did not make sense to me. > 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. Agreed in general. YAGNI, when in doubt, leave it out. But Sean was probably thinking that such a "uses super" predicate would be needed by any framework trying to reparent or borrow methods. Such frameworks exist today. Should they all be ported to use defineMethod, blindly? /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
