My general concern about strict mode is that it seems to be the result of a smoke-filled-room compromise. I'd like to see the perspective of JavaScript practitioners consulted about the strict mode definition (especially if it's going to form the basis for ES Harmony). -- Yehuda
On Thu, Sep 24, 2009 at 5:04 PM, Breton Slivka <[email protected]> wrote: > On Fri, Sep 25, 2009 at 9:26 AM, Brendan Eich <[email protected]> wrote: > > On Sep 24, 2009, at 4:06 PM, Charles Jolley wrote: > > > >> I'm curious, why not just give anonymous functions a default name like > >> "callee". Or perhaps have "callee" defined in a function scope to > represent > >> the function? That seems to be exactly the same as the above; it just > makes > >> it easier for developers. Is there a perf issue here? > > > > No, there's simply a backward compatibility problem. Anonymous functions > do > > not inject any such name on the scope chain (in any object, new or > expected, > > on the scope chain). Changing the language to inject callee (even in an > ES5 > > declarative envirnment frame) is not backward compatible and probably > will > > break some content out there that uses callee in an outer scope to mean > > something else. > > > > /be > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > > this discussion reminds me a little bit of the aspect oriented pattern > that has been used in javascript on occasion. The idea there is that > it's possible to replace a function with a wrapped version of the > function that has the original function in the outer scope. > > So for instance: > > var myarray = [3,4,5]; > myarray.toString = (function () { > var ofunc = myarray.toString; > return function () { > return "Extended toString: "+ofunc.apply(this,arguments); > } > })() > > myarray.toString(); //returns "Extended toString: 3,4,5" > > This pattern can be generalised: > > function extendFunc (object, methodname, func) { > var ofunc = object[methodname]; > object[methodname]=function () { > return func.apply(object,[ofunc].concat(arguments)); > } > > } > > you can see that in that version, the new function recieves the old > function as its first parameter. > > Now, my specific implementation has almost certainly got some flaws in > it (not a lot of error checking or robustness), I'm sure- and people > will argue about the details. It's the basic idea of aspect > orientation that I'm trying to get at here. > > The reason I'm bringing this up though is that this is a simple highly > general building block that can be used to build the super > abstraction, I believe (among many other useful abstractions). It's > also implementable in current ecmascript, and it's something that > could become canonized as a native function in a future version of > ecmascript- similar to the array extras that were first in the > prototype library, but are now in ecmascript 5. > > There might be even more clever ways to build it so that it doesn't > require an extra parameter (using "with" perhaps?) that could be used > now, but built in native code and optimised in future editions. > Anyway, I just thought I would put that out there for discussion. > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
