[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] zeroing length on transfer



On Fri, Dec 16, 2011 at 10:21 PM, Kenneth Russell <kbr@google.com> wrote:
> It boils down to a matter of taste. I personally like the current
> semantic that the payload of the ArrayBuffer is removed during a
> transfer operation, and that after a transfer, it and all views behave
> as though they never had any storage backing them. In your proposal,
> the only way to detect that an ArrayBuffer has been transferred would
> be to try indexing its views and watching for exceptions. The current
> behavior allows applications to test the length of the buffer or views
> to see if they have gone to zero.

What I like about it is:

- The behavior is concise and self-contained.  To throw an exception,
you'd have to carefully spec everything that operates on ArrayBuffer,
including its methods and methods on other APIs (many specified by
other parties) that take the object as a parameter, and ensure that
they all throw the exception in the right places.  This behavior is
all in one place: the object changes a bit of state that it already
has, and everything else just behaves accordingly.
- It doesn't increase the number of basic states of the object.  You
don't have "valid" and "invalid" objects (as with, for example, WebGL
resource objects).  That means that if you're writing a library that
takes an ArrayBuffer objects, you just don't have to worry about
it--you don't have to document what happens if an invalidated object
is supplied, and you never have to worry about dealing with the
exception.

It does change one big thing: the length of an ArrayBuffer is no
longer immutable.  That's something I think people would like changed,
anyway, since being able to extend and shorten an ArrayBuffer seems
obviously useful--in other words, realloc().  (You can reduce the size
with slice(), but then you're probably going to end up making a copy,
and you can't extend with it.)

-- 
Glenn Maynard

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------