On Tue, Jun 21, 2011 at 10:48 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Jun 22, 2011 at 1:25 AM, David Levin <levin@chromium.org> wrote:
>
>> On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard <glenn@zewt.org> wrote:
>>
>>> What happens if an object is included in the second list that doesn't
>>> support transfer? Ian said that it would throw, but I'm not sure that's
>>> best.
>>>
>>
>> If it doesn't throw, doesn't that introduce the backwards compat issue
>> when something new is supported that wasn't before?
>>
>
> The backwards-compat issue that we've talked about before is when transfer
> happens without opting into it explicitly for each object or type. For
> example, transferEverythingPossible([A, B]) would cause this problem: if A
> supports transfer when you write the code and B does not, then B gaining
> support a year later might break your code.
>
> I can't think of backwards-compat issues with not throwing. Can you give
> an example?
>
You just gave it! :)
Let's say the call doesn't throw when given a type B that isn't
transferrable.
Let's also say some later changes the javascript code and uses B after the
postMessage call.
Everything work. No throw is done and B isn't "gutted" because it isn't
transferrable.
Now let's say Firefox supports transferring B, the site breaks because it
was never tested like this, so Firefox has to choose between compatibility
and a supporting transferring B. (Of course, this will be in some sample
that everyone copies :).)
dave