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

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 by the ToUint32 operator defined in section
  9.6 of [ECMA-262], is a non-negative integer that indicates the number
  of elements in the sequence.  Assigning to the length property 

…

  Such
  objects must return the element in the sequence at position n when
  their [[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.

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

Received on Saturday, 30 June 2007 10:39:07 UTC