On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote:
-----Original Message-----
From: Maciej Stachowiak [mailto:m...@apple.com]
I expect there are relatiively few such capabilities, and little
interest in depending on new ones, and therefore we do not really
have
a general ongoing problem of language design.
We have an ongoing problem of language design in that all new language
features must integrate with existing features. Combinatory feature
interactions is one of the larger challenges of language design.
From a quick scan of WebIDL, I see the following:
1) Catchall getters, putters, deleters, definer.
- Variants that can make the catchall check happen either before
or after normal property lookup.
- General string-based name access and index-only versions.
No comment, I need to come up to speed on the detailed semantic
requirements
They are pretty similar to the way Array overrides
[[DefineOwnProperty]] or the way String defines
- Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.
Seems like a strong reason to change to the proposed API to
eliminate the need for
a new ES language extension.
I previously argued for removing the need for catchall deleters from
the Web Storage API (since nothing else requires , but other browser
vendors (including Mozilla) were happy with it, and I think now
everyone (including I believe Microsoft) has implemented the spec
behavior. See prior discussion thread here: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html
>. At this point, since we have multiple deployed implementations of
Web Storage, we'd have to investigate whether it's safe to remove this
behavior without breaking content.
2) Ability to support being called (via [[Call]]) without being a
Function.
Not an issue with the core ES5 semantics. Most ES3/5 section 15
functions have this
characteristic. As long as such WebIDL objects are defined similarly
to the "built-in"
function they too can have this characteristic. It may well be
useful to introduce a
mechanism defining such "pure" functions in the language but it
probably isn't necessary
to proceed with the WebIDL binding. The important thing to try to
avoid is specify
a custom [[Call]]
I tend to agree that this behavior (and the next 3) are not
philosophically problematic, even though they cannot today be
implemented in pure ECMAScript.
3) Ability to support being invoked a constructor (via [[Construct]])
without being a Function.
Essentially same as 2 although the standard [[Construct]] requires a
[[Call]] so this
may need some more thought.
4) Ability to support instanceof checking (via [[HasInstance]])
without being a constructor (so myElement instanceof HTMLElement
works).
Possibly the specification of the instanceof operator needs to be
made extensible
5) Ability to have [[Construct]] do something different than [[Call]]
instead of treating it as a [[Call]] with a freshly allocated Object
passed as "this".
Similar to 4 regarding extensibility. At least one recent "harmony"
strawman proposal is
moving in a direction that may be relevent to 4 and 5.
See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors
Interesting. This may provide a way to implement some of these
behaviors in pure ECMAScript. The current proposal does allow
[[Construct]] without [[Call]], but not [[Call]] and [[Construct]]
that both exist but with different behavior.
Regards,
Maciej
