> 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
