Re: ECMAScript octet representation (was: Re: Bindings spec ready for FPWD?)

[Sorry, sent that before it was ready…]

liorean:
> The problem is that ES3 and ES4 implementations in the real world
> would have to be entirely compatible. Otherwise ES4 implementaitons
> would have to use the ES3 bindings anyway, unless all browsers move to
> ES4 at the same time as they implement the DOM interfaces that we're
> talking about, leaving no ES3 backwards compatibility to take into
> consideration. Which I find an unrealistic scenario.

Presumably ES4 will be backwards compatible with ES3, too.

Cameron McCormack:
> >  Sequences are passed by reference. If a reference to a sequence passed
> >  to a host object is kept (whether internally or as the value of an
> >  attribute), and the passed sequence is not an ECMAScript Array object,
> >  the kept reference must be a newly created ECMAScript Array object
> >  whose contents is the elements of the sequence.

> This is not compatible with ByteArray on the other hand,

True.

> and I don't think it's entirely compatible with the ES3 object model
> either.

As long as it’s able to be defined in ES terms, it’s compatible really.

> Whether it's compatible or not, it's certainly a contraint that can
> only be seen in primitive types such as strings and not in compound
> types such as Array or ByteArray.

Yeah I guess so.

> Sounds like what you actually want is copy-on-write semantics on the
> setters.
>
> Another incompatibility is that you specify it to actually be an ES3
> Array after copying and not allowing implementations to use ByteArray
> for the copy. (ByteArray does not from what I understand inherit from
> Array. It's also final, so you can't do a derivate class (say
> DOMByteArray) that has the copy-on-write semantics.)

OK, so I think I should remove those mentions of Array.  (My intention
was something to do with not surprising the author with objects that
seemed like Arrays but didn’t have the Array methods, but what I’ve
written is asymmetric anyway.)

> Another thing I'm sceptic of is whether the array methods are
> appropriate on sequence<octet> even in ES3 implementations.

Oh, why’s that?

Anyway, it would be simpler without mention of Array.  How about the
following:

  Values passed to a host object that expects a sequence<T> must be
  objects with a length property whose value, after being converted
  to an ECMAScript Number value by the ToUint32 operator, is a
  non-negative integer Number (that is also equal to calling ToNumber
  on the original value) that indicates the number of elements in the
  sequence.  Assigning to the length property a non-negative integer
  Number must change the length of the sequence to be the given number.
  If the sequence is lengthened, new elements must be given the value
  that the undefined value is converted to when handling it according
  to the rules in this section for the type T.  If the sequence is
  shortened, the values beyond the length of the sequence are lost.
  The object representing the sequence must return the element in the
  sequence at position n when its [[Get]] internal method is invoked
  with n as its argument.  (An ECMAScript Array is an object that
  matches this description.)
  
  When the host object gets an element of the sequence using the
  [[Get]] method, the returned value will first be handled according to
  the rules in this section for the type T.

  If a host object expecting a sequence<T> is passed a value which is
  not an object with a non-negative integer Number length property, a
  TypeError exception must be thrown.

No mention of converting to an Array, and the behaviour should be a
subset of both ES3’s Array and ES4’s ByteArray (assuming
sequence<octet>).

(Wording probably could be better; just wrote it quickly after realising
I mis-sent the previous mail. :))

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Saturday, 30 June 2007 10:53:35 UTC