Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

On Fri, Sep 25, 2009 at 4:54 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Sep 25, 2009, at 7:26 AM, Mark S. Miller wrote:
> I think there are two possible perspectives on what constitutes
> "magnify[ing] tthe problem" or "widening the gap"
>
> A) Any new kind of requirement for implementations of object interfaces that
> can't be implemented in pure ECMAScript expands the scope of the problem.
> B) Any new interface that isn't implementable in ECMAScript widens the gap,
> even if it is for a reason that also applies to legacy
>
> My view is A. That's why I pointed to legacy interfaces - if the construct
> can't go away from APIs in general, but we wish to implement all APIs in
> ECMAScript, then ultimately it is ECMAScript that must change, so using the
> same construct again doesn't create a new problem. Avoiding it in new APIs
> would provide a small amount of temporary relief for the brave person who
> seeks to implement the whole Web platform in pure ECMAScript, but in the
> long run would make no difference to the feasibility of the overall goal.

A good distinction. I agree that the #A problem is worse. I also do
not know of cases of #A.

Regarding #B, I also think these are best avoided. Various existing
systems that try to emulate DOM object behavior using JavaScript code
may fail to emulate some of these, creating leaky abstractions that
their users live with. Each additional case adds another headache.
However, your split below of Array-like vs catchalls is nice, and your
enumeration of the reasons to avoid APIs that need general catchalls
is great.


> Now, there may be pragmatic reasons for avoiding catchall getters and
> setters:
>
> 1) Difficulty of efficient implementation (this is less true for index-only
> catchall getters).
> 2) Potential confusingness to authors (probably also less true for index
> access).
> 3) Namespace collisions between the magical attributes and the object's
> built-in attributes and methods - this makes it harder to specify and
> explain the interface and creates hazards for use (does not apply to the
> index access pattern afaict).


Yes. As an obvious example of #3, what happens when a Storage
<http://dev.w3.org/html5/webstorage/> key is "toString"?

I note that WebIDL already distinguishes between requiring catchalls
for any property name, as in getItem(), vs requiring only index
access, as in key() below.

interface Storage {
  readonly attribute unsigned long length;
  getter any key(in unsigned long index);
  getter any getItem(in DOMString key);
  setter creator void setItem(in DOMString key, in any data);
  deleter void removeItem(in DOMString key);
  void clear();
};


> I think these are reasonable arguments (though I wouldn't rule out a priori
> that there may be situations where the API convenience of catchalls
> outweighs these concerns).

Of course nothing should be ruled out a priori. But your issue #3 is
quite serious. Do you know of any cases where the API convenience
justifies creating yet another such namespace confusion? IMO, Storage
does not and the getter/setter/deleter annotations on it, being a
non-legacy API, should be removed from all but key(). The
inconvenience of tracking down the resulting bugs outweigh the
convenience of saving a few characters in source.

OTOH, if our resolution of the need for array-like generic indexes is
to allow overloading of [], then perhaps the resolution for new APIs
is to annotate them somehow, to distinguish them from the
legacy-namespace-confused-APIs-we-can't-fix, so that, for example,

    storage['toString'] is equivalent to storage.getItem('toString'),
and neither is considered a property access (other than access to the
getItem property).
    storage.toString accesses storage's toString property, and is not
affected by the alternate getter annotation we'd use instead of the
above.


> But I think these are totally separate from the "implementability in pure
> ECMAScript" concern. And in particular, I think index access to array-like
> objects is a good pattern that we should not stop using in APIs just because
> it's not implementable in pure ECMAScript today. Past interfaces use this
> pattern, and future interfaces should clearly use it once ECMAScript
> supports it. A temporary moratorium on using it would not be a wise
> tradeoff.

These are good distinctions. I do not disagree.

Regarding named properties, I think such a moratorium is justified.

-- 
    Cheers,
    --MarkM

Received on Saturday, 26 September 2009 03:28:20 UTC