On Sep 10, 2014, at 6:24 PM, Boris Zbarsky wrote: > On 9/10/14, 5:48 PM, Allen Wirfs-Brock wrote: >> Why not just us ES as the specification language for most things in the >> WebIDL world? Or if not full ES, a simplified form "Spec-ES". > > There are a few issues with using ES for specifying Web IDL. It's possible > that these can be overcome, of course.
To clarify, I wasn't necessarily talking about using ES to specify Web IDL. Rather I meant using ES as an alternative to pseudo code for specifying the semantics of APIs defined with Web IDL interfaces. To support that I assume that you would have to defined some WebIDL specific functions that would be callable from those ES-based specifications. > > First, ES doesn't actually have some of the data types involved. There is no > record type that would correspond to an IDL dictionary, for example. You > could use objects, or Maps to represent those, but would need to make it very > clear that those are not using the page-modifiable prototypes, while > continuing to operate in the page Realm in some sense. Yes, you can abstract any sort of data structure you need as spec. level functions and objects and restrict them in whatever way you need to. That was the sort of thing I was thinking about when I allude to a "Spec-ES". > > Second, and related to the first item, Web IDL needs to operate on property > descriptors, because it needs to define the behavior of some internal > operations like [[Get]] and [[GetOwnProperty]]. This comes back to not > having records; operations on descriptor objects are not the same thing, > again unless you assume clean prototypes somehow. > > Third, a number of the desired operations (ToUint32, ToInt32, ToNumber, > ToBoolean, ToString, ToObject, Type) are somewhere betwee "a pain" and > "starts to look like an obfuscated programming contest" when you try to do > them in ES proper. So whatever specification formalism we use needs to be > able to reference these directly. A Spec-ES could do that, of course. > > Fourth, any algorithm that uses lists would need to make it clear that the > lists use the magic clean Array.prototype while arrays in the same algorithm > might use the normal page-modifiable prototype. > > Fifth, Web IDL needs to be able to call [[DefineOwnProperty]] and the like. > This can be done via Object.defineProperty as long as you once again make it > very clear which operations are using a clean Object and which are not. > > So I guess my main issue here is the same one that self-hosted builtin > implementations have in V8 and SpiderMonkey: you have to be _really_ careful > to distinguish between your usage of clean built-in stuff and page-visible > stuff. The result can be fairly taxing to write, read, reason about, and > modify. It's doable, but I'm not sure whether the end result would be better > than what we have now. :( I think the main benefit is that you get closures, exception handling, for-of, etc. Getting those things correct (and ES implementable) at the pseudo-code level is challenging. > >> In the long run, we could probably also do this for many of the ES built-ins > > This would be a good exercise for dealing with some of the above sorts of > problems, yes.... > >> And I really hope that most APIs spec'ed using WebIDL are designed to be >> implementable using ES. > > Most APIs I've seen people adding recently really aren't, because they seem > to be about low-level hardware access and whatnot. For what it's worth. Sure hardware accesses need to be abstracted, isn't there typically a layer of post processing or data packaging wrapped around the direct hardware access. Higher level access to iterators, for-of , closures, exception would be very useful in those layers. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
