- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 26 Sep 2009 18:08:36 -0700
- To: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.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>
On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote: > > >> -----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 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
Received on Sunday, 27 September 2009 01:09:18 UTC