[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Typed WebGLArray sequence parameter types
Thanks for the comments. I've raised a request for the addition of a signed 8-bit integer type to Web IDL:
On Thu, Jan 7, 2010 at 11:31 AM, Vladimir Vukicevic <email@example.com>
That works for me, given that we have 'byte'. I can make the change.
On 1/6/2010 5:55 PM, Kenneth Russell wrote:
On Wed, Jan 6, 2010 at 1:07 AM, Shiki Okasaka<firstname.lastname@example.org> wrote:
I've uploaded a validated WebGL IDL file at,
Thanks, this looks great. It's fantastic that you've verified the IDL.
This is written in the current Web IDL editor's draft  format with one
extended keyword 'byte' for 8-bit integers.
Does this look reasonable? Maybe the getter and setter types should be
changed as well?
I think we should switch over the spec's IDL to this version.
Given what we now understand about the WebIDL conversion rules, I
think we should switch the getters and setters for the WebGLArray
types to be precisely what the underlying array is supposed to hold.
On Wed, Dec 23, 2009 at 2:28 AM, Kenneth Russell<email@example.com> wrote:
On Mon, Dec 21, 2009 at 10:35 PM, Vladimir Vukicevic
On 12/21/2009 8:38 PM, Shiki Okasaka wrote:
Sounds like a good workaround.
Is this possible to modify typed WebGLArray sequence parameter types
Yep, that's the main reason why long/unsigned long are used instead of
in the IDL definitions as below?
sequence<long> -> sequence<octet>
sequence<unsigned long> -> sequence<octet>
sequence<long> -> sequence<short>
sequence<unsigned long> -> sequence<unsigned short>
This change would make the generated interfaces for statically typed
languages (e.g. Java) more useful.
Note currently Web IDL does not have a primitive type for 8-bit signed
integer values. If it is useful for WebGL, maybe we can propose an
addition of it to Web IDL as Geolocation WG requested to add 'double'
in addition to 'float' .
-- if octet was used, then it becomes impossible to actually specify
8-bit integers. For short, we decided to follow the same convention.
However, maybe a workaround would be to add a typedef somewhere for our
signed_octet type, by default typedef'd to unsigned long, but with a
statement in the spec saying that this should be a signed 8 bit type if
language supports it?
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: