Re: [WebIDL] Feedback on the August 30 Editor's draft

On Thu, Sep 3, 2009 at 8:12 AM, Travis Leithead<travil@microsoft.com> wrote:
>>> 2- property inheritance (regarding 4.4.3 [interface prototype objects])
>
>>Is this for the accessor (getter/setter) introduced in ECMAScript 5?
>
> Yes and no. Before ES5, browser venders still have ways of getting the getter/setter pair (__defineGetter__/ __lookupGetter__), so the scenario is still relevant. The meta-point is that it's more about being able to improve the utility of extending or replacing the behavior of these properties.

If Web IDL is going to mention the accessor property in ECMAScript, I
agree it would be very practical to have accessor properties on the
corresponding interface prototype objects.

Is there any plan to specify ES5 (or maybe existing ES getter/setter
implementation) binding in Web IDL?

Best,

 - Shiki

>
> -Travis
>
> -----Original Message-----
> From: Shiki Okasaka [mailto:shiki@google.com]
> Sent: Wednesday, September 02, 2009 7:10 AM
> To: Travis Leithead
> Cc: public-webapps@w3.org; Cameron McCormack; Tony Ross; Adrian Bateman
> Subject: Re: [WebIDL] Feedback on the August 30 Editor's draft
>
> Hi Travis,
>
>> 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other
>> places in the spec)
>
> This looks to be a reasonable solution for the problem Andrew and
> Cameron discussed about to me.
>
>> 2- property inheritance (regarding 4.4.3 [interface prototype objects])
>
> Is this for the accessor (getter/setter) introduced in ECMAScript 5?
>
> Regards,
>
>  - Shiki Okasaka
>
>
> On Tue, Sep 1, 2009 at 2:07 PM, Travis Leithead<travil@microsoft.com> wrote:
>> Cameron et al.,
>>
>>
>>
>> I have a couple pieces of feedback on this draft.
>>
>>
>>
>> Let me start by saying that this is a wonderful spec—much needed by the
>> working group, and much appreciated by the IE team in relation to the
>> additional clarity it provides for interpretation of other specs.
>>
>>
>>
>> Before I launch into the specific feedback, let me explain the principle
>> behind my thinking: make the DOM binding for JavaScript as extensible as
>> possible. I’d like to ensure that within reason, there is sufficient
>> language binding to make the DOM as extensible and customizable as possible
>> for web developers. For example, web developers that want to customize DOM
>> behavior via one of its APIs should only have to do so at most once (or
>> several times if the API is a mixin). Most of the design decisions for IE8’s
>> DOM prototypes follow this principle.
>>
>>
>>
>> 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other
>> places in the spec)
>>
>>
>>
>> My first comment here is that this is overly complicated. I don’t quite
>> follow why the mixin prototype object is defined to exist one level up from
>> the object instance. This pretty much ensures that it’s impossible to
>> override the behavior of a mixin property (operation) on any scope larger
>> than instance-level. For example, a developer would like to customize the
>> behavior of addEventListener by replacing the native property with his/her
>> own behavior, which ultimately invokes the native addEventListener API via
>> apply. To do this and comprehensively cover every case where a webpage could
>> use addEventListener, the web developer must override every instance in the
>> DOM. This is unmanageable for any practical application. Rather, if the
>> mixin properties were defined to exist higher-up in the prototype chain,
>> then much more “coverage” can be obtained by one replacement. Since the
>> mixin may appear on other interfaces, the scenario is not a single-point of
>> replacement, but in all likelihood, a manageable number.
>>
>>
>>
>> I propose simplifying the mixin design substantially. I would like to see
>> TargetInterface implements MixinInterface; be interpreted as merging each
>> property/operation that is defined on the MixinInterface interface with the
>> properties/operations on the TargetInterface. Treat mixins as literally
>> “mixing in” to their associated interface. This likely implies that no
>> interface object nor associated  interface prototype object need be created
>> in the ECMAScript binding. Where the MixinInterface interface is implemented
>> by AnotherInterface, it’s properties/operations are merged to that interface
>> as well (creating a copy of the property/operations on  AnotherInterface).
>>
>>
>>
>> I believe that design is simpler for web developers to understand, and also
>> increases the utility of extending the functionality of typical mixins (like
>> EventTarget). Today, no browser implementation that I’m aware of handles
>> this consistently, and thus the risk to change the spec is very low.
>>
>>
>>
>> 2- property inheritance (regarding 4.4.3 [interface prototype objects])
>>
>>
>>
>> Again, from the extensibility point of view, it’s concerning to me that
>> properties as defined on an interface are not actually represented as
>> properties on the corresponding interface prototype object! Rather, the spec
>> as it is currently written, flattens all properties to the object instance
>> (which appears to coincide with Safari’s behavior for properties). With the
>> current approach, properties (i.e., those defined with ‘attribute’ in the
>> WebIDL) cannot be overridden (or replaced) on anything other than object
>> instances themselves. A key scenario for IE8 was the ability to customize or
>> replace the functionality of innerHTML globally for all elements. Thus, we
>> provided a property for innerHTML on the most general element type we had
>> (Element—yes I know it’s not the correct prototype hierarchy—we’re working
>> on that J). Web developers can customize and extend that property in one
>> place for far-reaching impact with little effort. Naturally, properties on
>> prototypes are meaningless when invoked directly (they need an instance
>> object ‘this’ reference), which is why IE8 and Firefox require the use of
>> call/apply to be used when direct-invoking these. Opera does not appear to
>> define properties at any level in their prototype chain, yet respects the
>> web author’s intent to override them (again, at any point in the hierarchy).
>> I favor IE, FF, and Opera’s extensibility over Safari’s simplicity on this
>> point.
>>
>>
>>
>> I propose defining properties (not just operations) on interface prototype
>> objects. This proposal allows properties to be overridden/extended as easily
>> as operations currently are. It also results in nice symmetry between the
>> properties and operations defined on a WebIDL interface and the resulting
>> interface prototype object. Finally, it more closely approximates the
>> behavior available in three of the four major browser venders.
>>
>>
>>
>> I’m eager to discuss these issues with the working group.
>>
>>
>>
>> Again, thanks for this great specification and your time as an invited
>> expert.
>>
>>
>>
>> -Travis
>>
>>
>
>

Received on Thursday, 3 September 2009 04:36:32 UTC