Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

On 1/14/15 10:14 PM, Ian Hickson wrote:
> You are dismissing what I'm describing as being a misunderstanding of how
> things should be considered to work,

No, I'm dismissing it as introducing magic that doesn't need to be 
introduced and hence making the platform more complicate than it needs 
to be, for no benefit I can perceive.

I do understand what you're describing, believe me.  I just have no 
plans to implement it or ask anyone else to implement it.

> Or maybe both our
> points of view are valid, and we should figure out which is easiest to
> describe, or easiest to implement, or simplest to explain to authors, or
> most compatible with the Web, or least likely to involve contortions
> around unnecessary invariants, or whatever other priorities we want to
> apply to this decision.

Yes, that's what I've been saying all along.

I will claim that my description is easier to describe rigorously, 
easier to implement, probably just as nasty to explain to authors, can 
completely replicate the observable behavior of your description if 
needed (e.g. by just directly forwarding all internal methods to the 
Window, at the cost of violating the invariants this thread is about), 
so can be just as compatible with the web, and gives at least a chance 
of preserving invariants people care about if that's what people want to do.

Whereas your description basically forecloses all discussion on how 
things should behave, because it locks them in to behaving in the single 
way you like; doing any other behavior requires going to a different model.

>> ES also allows other "exotic objects" that define some other behavior
>> for those internal methods, but requires that the invariants be
>> preserved.
>
> So one option would be to just say that WindowProxy is not an ES object.

You were talking about explaining something to authors or making it 
implementable, yes?

> Except on WindowProxy, because WindowProxy forwards all operations to the
> underlying Window.

There is no "operation" to forward here.  === is literally just bitwise 
memory comparison equality in implementations.

> If the opaqueCode() function just does:
>
>     function opaqueCode() {
>       c = b;
>       d = b;

It doesn't have c and d in its scope, so can't do that.

And yes, you're going to say that the browser has everything "in scope", 
but the point is that your model involves some sort of non-local 
complicated heap-walking effect whereas changing the target of a proxy 
... not that.

> The point is that the invariants apply to the actual objects originally
> assigned to a and b, they don't apply to the variables.

"variables" don't even exist as a useful concept by the time you're 
running the code.  You've got values on the heap, on the stack, in 
registers, etc, etc.  Just saying.

>> No, because in the code above if I do |var d = c;| then the d won't
>> change in part 3.
>
> If in the code above you do var d = c, then add d = b to part 3 to
> simulate what the browser does.

Yes, I know that's your mental model.  My point is that no sane 
implementation would possibly want to actually implement it that way, 
whereas implementing it in terms of internal methods is what at least 
some implementations actually do.

> I'm not actually proposing updating all the references. That's just a
> convenient way to think about it

Except it's not a convenient way to think about it!

> What is specced is just that you have a placeholder
> pseudo-object

Why is it a pseudo-object when an object would do?

> I have asked before, but would like to reiterate:
>
> If there is any behaviour that is underdefined by the HTML spec's current
> prose, please tell me, so that I can spec it.

Care to ask the UA implementors who are clearly not doing anything even 
resembling your spec?  Because it might turn out they might have reasons 
for it...

> Well it predates all the ES6 stuff we're talking about here by several
> years

All the "stuff" involved was in ES5.  It's not new in ES6.  I've also 
pointed this out to you several times now.

> it doesn't leave anything undefined.

Implementations seem to disagree by their actions, sadly.

> I also disagree that what the spec says doesn't match implementations.

Uh... Have you _tried_ testing this stuff in Safari?  I have; please see 
archives for the results.  They look nothing like your spec.

-Boris

Received on Thursday, 15 January 2015 03:52:12 UTC