>-----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 > - 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 >
