Re: Web IDL attributes and delegation

On 9/13/12 2:39 AM, Colin Snover wrote:
> First, there seems to be an assumption here that I want to permanently
> alter the original event object. Sometimes this is OK, but sometimes it
> is not.

Ah, yes.  Then you do need some sort of delegation mechanism, if you 
want to filter access to the event object but not modify the event 
object itself.

> Second, if I am reading the spec correctly, [Unforgeable] means
> defineProperty *won’t* work in some cases. This flag may not be set on
> Event properties

This flag is only set on properties that must not be changed because it 
would break legacy code that does security checks based on those 
properties.  It's basically only used on members of Window and Document, 
and even then on very few members.

> No, though it sounds like using defineProperty would break these
> implementations now. Do you know offhand who implements this way and if
> this does, indeed, break them?

Safari and Chrome, and no idea what they do with defineProperty on DOM 
objects.

>>    var elem = document.createElement("span");
>>    elem.innerHTML = "<i>Something</i>"
>>    var obj = Object.create(elem);
>>    Object.defineProperty(obj, "firstChild", { value: elem; });
>>    alert(obj.innerHTML);
>>
>> What should happen and why?
>
> Line 1 creates a new DOM object as elem and initialises it. Line 2
> causes elem to create an internal DOM structure representing the
> provided string. Line 3 creates a new object using elem as its
> prototype. Line 4 sets the firstChild property of the object obj to
> elem. Line 5 calls elem’s innerHTML getter and alerts the result, which
> should be the same value provided in line 2, because Line 4 just defined
> a new property on obj (and firstChild is readonly, but even if it
> wasn’t, the firstChild setter would not be called because [[Put]] was
> not used).

The question is how one is supposed to implement this.  Keep in mind 
that the innerHTML getter is being called with "obj" as this.  Then what?

>> Which particular platform object?  Note that the getters live on the
>> prototype, not on the platform object itself.
>
> In your previous example, the elem object.

Well, the getter and setter can't be bound to an instance object; they 
live on the prototype and are shared across instances.  So what are you 
actually proposing to happen here?

> I realise that this is
> probably ugly from an implementation perspective but the current
> proposal is almost certainly worse from an authoring perspective.

I would still like to understand the authoring constraints here.  You 
mentioned that proxies are not an option.  Why not?  Do you think that 
getting multiple browser vendors to wholesale change how they implement 
their DOM bindings will take less time than them fixing whatever 
problems you see with proxies?

>> Again, this can already be done with Object.defineProperty in UAs that
>> actually implement WebIDL.
>
> Well, it can’t, or else we wouldn’t be having this discussion. :) The
> editor’s draft currently says an error must be thrown if |this| is not a
> platform object, so it is possible to either redefine *on the platform
> object itself* (if it’s allowed by the interface), *or* it is possible
> to create a perfectly worthless delegate object where only accessing
> overridden properties works. It is not possible to create a delegate to
> a platform object and have things function in a somewhat sane manner.

I'm not sure I follow.  You can, for example, define your delegate such 
that it imports all the properties from the prototype, rebinding them to 
the thing you're delegating in the process.  It does make delegate setup 
slower, but allows everything else in the DOM to be faster.

Or you can use a proxy for filtering property access, since that's what 
they're designed for.

Or we can introduce this hack that makes getters behave differently from 
methods and setters as a workaround for the fact that proxies have 
problems, whatever those problems are.  But I'd much rather fix the 
proxy problems, honestly.

-Boris

Received on Thursday, 13 September 2012 01:53:42 UTC