> On Feb 18, 2008 1:17 PM, liorean <[EMAIL PROTECTED]> wrote: > > Basically the idea was along the lines of investigating the effects of > > removing GetValue usage from those productions whose semantics just > > pass values through (such as all the shortcut evaluation operators, > > parenthesised expressions, plain assignment, function arguments, > > return statement etc.). The only semantics that would in effect be > > changed are those for function calls. Function calls would always > > "remember" the this-object of any member lookup since they are passed > > around as a Reference object, while still not making that object > > outside detectable. Of course if the function is referenced again > > using member lookup, then a new Reference object would be created with > > the new base object and the function object itself GetValue'd out of > > the old Reference object.
On 19/02/2008, Garrett Smith <[EMAIL PROTECTED]> wrote: > Is this like getValue with a hint for a thisArg? No, not really. And the way I described it is not quite what I want, either. I'd want something similar to but not exactly like the Reference type, such that a tuple with base and value is stored, not base and name-of-property as is the case for Reference. A Reference would allow replacing the value of the property between initialisation and use, while I'd want something that stores the actual value at the time of initialisation. Using a Reference also would require recursive GetValue, which can be eliminated at initialisation time if it stored the value instead of the name of the property. > > This change would eradicate a pet peeve of mine: > > var > > o={ > > f: > > function(){ > > return this; > > } > > }, > > f=o.f; > > o.f(); // => o > > f(); // => window > > (o.f)(); // =>o > > (f=o.f)(); // => window > > > > > (o.f)(); // =>o > > This should be window. No it shouldn't. The grouping syntax specifically doesn't call GetValue in order to make delete and typeof operators able to use function-call-like syntax. Which makes up for this asymmetry. > > With the change, all of those would return o. > > > > I never quite finished my analysis of the backwards compatibility and > > security implications of doing such a change though. > > For backwards compatibility the issues with doing such a change should > > be minor in live code. It would only affect code that both expects the > > this-object to be the global object and which extracts the function > > from an object using shortcut evaluation or assignment operation. > > > > Any event registry using load/onlunload would seem to have problems. > > MyWIndowListeners = { > onunload : function(){} > }; > > onunload = MyWIndowListeners.onunload; That's not a problem. It's a question of how the [[Call]] is made on the event handler. If the event implementation is specified to extract the function object, and calls fobj.[[Call]](EventTarget, arguments) when the event is triggered, then it's not a problem at all. The specs for DOM events do NOT specify how the this-object should be handled. Nor do any other relevant spec from what I can tell. At the moment, DOM0 and Saf/Op/Moz send the EventTarget as this-argument. Ie doesn't send it for attachEvent et al, nor do some other DOM2Events implementations (e.g. the one in Tasman). Since the function call is not part of ECMAScript, and this change affects the member lookups and storage both, any external call into ECMAScript that does a GetValue would get the old behaviour and any external call that sends a this-value of it's own would be unaffected. Only an external call that doesn't do a GetValue would get the remembered this-value. > Instance methods in ES4 are bound. One implication to that is that > theres a new function for each instance. It's not as cheap as having a > prototype method. Instance methods would ignore any this-value sent, no? So this really wouldn't change anything for them at all. -- David "liorean" Andersson _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss