Additional notes from last Thursday's meeting

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/

Received on Monday, 5 October 2009 07:46:49 UTC