As promised, here are some very brief notes from last Thursday’s
meeting.
* There was a strong desire to allow the DOM to be implemented in pure
script. There was strong disagreement with allowing catchall
properties (which are impied by the use of name getters).
* Nobody liked ‘caller’ operations, and some wanted to remove it from
from normative requirements altogether. The IE team would like to
remove support for callable collection objects at some point in the
future, and the worry is that codifying this as required behaviour
would make that much harder.
One suggestion was to mention this in a non-normative section like
ES5’s Appendix B.
* Work is needed to improve the handling of multiple inheritance in
the ES bindings. Mark has a “traits” proposal that was mentioned,
although it is not in the ES strawman wiki yet. Mark indicated that
he would write it up at some point.
* There was a desire to reduce the number of numeric types in Web IDL
so that there isn’t such a difference between them and those used by
ES scripts and the ES spec. One proposal was to just have three
numeric types: a 32 bit signed integer, a 32 bit unsigned integer
and a double precision IEEE 754 floating point number. The names
int32, uint32 and Number were floated as strawman suggestions.
Another possibility was just long, unsigned long and double.
* Or, if float and double were being kept, then perhaps they should be
defined to allow not losing precision when assigning to a float (in
case an implementation is using doubles internally). Or, floats and
doubles could be made synonymous (and just mean double). Or, floats
could be defined as ≥ 32 bit floating point numbers and doubles as
≥ 64 bit.
* The current long long type was seen as problematic, since not all
long long values can be represented in an ES Number. One suggestion
was to replace it with a 54 bit integer type. File API was brought
up as an example of a spec that would use long long.
* It was thought that there needs to be a notion of “acceptability”
for interface types at the IDL level. This would handle things like
user script not being able to implement a Node, when calling
appendNode() for example. This was motivated partly by not wanting
to prevent a pure script implementation of a DOM (e.g. by a script
library) being non-conforming. Acceptibility would be defined such
that in a DOM implementation, all objects implementing Node that can
be reached in this or other frames would be mutually acceptable.
Interface objects could have a method on them, e.g.:
n = Node.coerce(n);
where that function would throw if ‘n’ is not acceptable as an
object of type Node to the “implementation” that this Node interface
object is a part of. Otherwise, it would just return the object.
This coerce() function could be extended in the future, if ES gains
some more typing.
Mark said something like:
A set of constructors are in an equivalence class when they
represent the same type. The coerce methods of all constructors
in such a set will not throw when passed any objects that are
instanceof one any of those constructors. HTML5 would then say
that the boundaries of those equivalence classes are origins.
* It was suggested that it would be good to have a Java person be
active in the discussions (maybe Michael Glavassevich).
* Although I (personally) don’t like [Supplemental] as it’s currently
being used (and it isn’t currently in the spec) others in the room
weren’t against it.
Apologies for any incoherence, and corrections welcome.
--
Cameron McCormack ≝ http://mcc.id.au/