Greedy triple-quoted string literals

liorean liorean at
Wed Feb 20 10:48:52 PST 2008

> > > On Feb 18, 2008 1:17 PM, liorean <liorean at> 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 20/02/2008, Garrett Smith <dhtmlkitchen at> wrote:
> a.f = function(){
>    return this;
> }
> s.f = a.f
> print( f() ) // s

Well, you'd have to do f=s.f first, but you've got the principle right.

> a.f ;

Just mentioning it doesn't change anything. The reference is created
by mentioning it, but since you're not storing it anywhere it just
gets garbage collected. You'd have to do f=a.f, jsut like you had to
do f=s.f above.

> print( f() ) // a
> Is this right?

With the changes above, then yes. The idea is that member lookups for
functions create a Reference (or rather a base:value tuple instead of
a base:slotname tuple), which is stored. This would be an intermediary
internal type that is never actually detectable from the script itself
other than in the form of retained this-values when passing function
objects around.

> > On 19/02/2008, Garrett Smith <dhtmlkitchen at> wrote:
> > > Is this like getValue with a hint for a thisArg?

> On Feb 19, 2008 10:21 AM, liorean <liorean at> wrote:
> > 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.

> If I'm understanding you correctly, you want a Reference type on a
> function. Is this correct?

I want a base:value tuple returned from member lookups if the value of
the lookup is a function object. The Reference type is a base:slotname
tuple, meaning the actual value lookup would be delayed until use,
which is undesirable.

> And that Reference has a value pointing to the object which will be
> the this arg in Call. Right?


> > 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).
> I can't remember the last time I tried to use Mac IE. I remember that
> it supported neither attachEvent nor addEventListener.

There's newer versions of Tasman. Tasman 0.9 was used in the MSN/OSX
browser, which contained DOM support much closer to that of Gecko,
Presto and Webkit than to that of Tasman 0.1 or Trident. Tasman 1.0 is
also used in Entourage in Office:Mac.

> > Instance methods would ignore any this-value sent, no? So this really
> > wouldn't change anything for them at all.
> Can you explain more?

The way I understands the ES4 proposals, [[Call]] on instance methods
ignore the first argument (the this.value) and instead always set the
instance as the this-value. So whatever first argument is sent to
[[Call]], it will have exactly zero impact on the semantics of the
program. Or is this a misunderstanding?
David "liorean" Andersson

More information about the Es4-discuss mailing list