- From: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>
- Date: Sun, 27 Sep 2009 00:20:48 +0000
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Yehuda Katz <wycats@gmail.com>, Brendan Eich <brendan@mozilla.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Doug Schepers <schepers@w3.org>, HTML WG <public-html@w3.org>, es-discuss <es-discuss@mozilla.org>
>-----Original Message----- >From: Maciej Stachowiak [mailto:mjs@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 > - 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. >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]] >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 > >Tentatively, I think all other semantics of Web IDL interfaces can be >implemented in pure ES5. > >Regards, >Maciej >
Received on Sunday, 27 September 2009 00:21:42 UTC