Re: DataCue questions

On Mon, Feb 17, 2014 at 4:12 AM, Brendan Long <self@brendanlong.com> wrote:
> On Sat, 2014-02-15 at 15:59 +1100, Silvia Pfeiffer wrote:
>
>> The other question is, is there a general rule where we take a copy of
>> objects in constructors? Otherwise we get weird behavior like this:
>>
>>> buf = new ArrayBuffer(4)
>> < ArrayBuffer
>>
>>> bufView = new Uint16Array(buf)
>> < [0, 0]
>>> bufView[0] = "hi".charCodeAt(0=)
>> < 104
>>> bufView[1] = "hi".charCodeAt(1)
>> < 105
>>
>>> cue = new DataCue(1, 2, buf)
>> < DataCue
>>
>>> cue.text
>> < "hi"
>
> The constructor is just a function. So, its parameters could be
> interpreted by the object either as an object to copy or as a storage
> location.
> E.g. Uint16Array provides both:
> https://developer.mozilla.org/en-US/docs/Web/API/Uint16Array
>
> In our case, I thought it was clear that a copy was taken and stored
> withing the DataCue object.
>
>>> bufView[0] = "no".charCodeAt(0)
>> < 110
>>> bufView[1] = "no".charCodeAt(1)
>> < 111
>>> cue.text
>> < "no"
>>
>> I'm not sure if I was implementing this wrong,
>
> Yes, I think that's wrong. That should not be possible.
>
>> or if we need to change the
>> spec to specify that .data is a copy of the ArrayBuffer we give it.
>
> Well, the spec for the constructor says "The data argument sets the
> raw data of the text track cue." Not sure if "set" implies copying.
>
> I wonder if we need to say that .data is a "structured clone" of the
> data parameter object (referring to "2.7.6 Safe passing of structured
> data")?
>
> I read "sets" as "=" and "someObject.data = someArrayBuffer" won't create a
> copy. I'll fix my implementation, and it's up to you if you think the spec
> should say something about that.

Probably better to change it.
I've registered: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24687

Cheers,
Silvia.

Received on Sunday, 16 February 2014 21:00:57 UTC