- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Wed, 14 Jan 2015 22:51:40 -0500
- To: Ian Hickson <ian@hixie.ch>
- CC: "Mark S. Miller" <erights@google.com>, Travis Leithead <travis.leithead@microsoft.com>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
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