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

> liorean:
> > Even if you find ByteArray unsuitable for the bindings since ES3
> > engines don't have it as built-in, I'd like to see it specified in
> > such a way that ES4 engines are allowed to use the native ByteArray
> > instead of having either a less performant ES3 Array-based solution or
> > a second ByteArray-like DOM host object.

On 29/06/07, Cameron McCormack <cam@mcc.id.au> wrote:
> I was thinking that an ES4 language binding would be separate from the
> ES3 one being specified here.  I'm confident that the mapping for
> sequence<octet> in the ES3 binding can be written so as to allow an
> implementation to use a more efficient host object than an Array object.

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.


On 29/06/07, Cameron McCormack <cam@mcc.id.au> wrote:
> In fact, looking at what I've written for the sequence<T> mapping, I
> think it currently will allow that:
>
>   3.1.12. sequence<T>
>
>   Values passed to a host object that expects a sequence<T> must be
>   objects with a length property whose value is a non-negative integer
>   Number that indicates the number of elements in the sequence. 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.
>
>   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.

For sequence<octet>, given that octet is constrained to a uint8, this
seems compatible with ES4 ByteArray, yes.

>   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.
>
> WDYT?

This is not compatible with ByteArray on the other hand, and I don't
think it's entirely compatible with the ES3 object model either.
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. 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.)


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

Received on Friday, 29 June 2007 10:07:20 UTC