[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding types to signatures in detail boxes
- To: Chris Marrin <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Adding types to signatures in detail boxes
- From: Kenneth Russell <email@example.com>
- Date: Tue, 27 Apr 2010 19:10:17 -0700
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272420619; bh=1KjlP126wuxfevzpUKOE3YuUs5I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ivVDWtR79ooYodfkFouZBWq7YNoU0ml+atCJ0ZnrPTuJzz1t0hh+BJMt+Kd9qwVk6 a/sz3Yfh0mVnZiSRQliXQ==
- Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=HHGDIeLJLhI1gq5X0SjvA5J6HBHXu7WKLL8T35DSwlLJkUFQd5+CwJBGhYe4zbFjZ e+tayIhYbT47apsLxLtxA==
- In-reply-to: <EA3DBC25-6855-4737-8F21-F129D0F10E2B@apple.com>
- References: <email@example.com> <BDE38C33-A27E-4A62-98B4-3BC4A00260B9@apple.com> <firstname.lastname@example.org> <EA3DBC25-6855-4737-8F21-F129D0F10E2B@apple.com>
- Sender: email@example.com
On Tue, Apr 27, 2010 at 12:10 PM, Chris Marrin <firstname.lastname@example.org> wrote:
> On Apr 26, 2010, at 6:18 PM, Kenneth Russell wrote:
>> On Fri, Mar 5, 2010 at 3:42 PM, Chris Marrin <email@example.com> wrote:
>>> On Mar 2, 2010, at 3:21 PM, Kenneth Russell wrote:
>>>> Currently the method signatures in the (green) detail boxes throughout
>>>> the spec omit the types which are in the IDL snippets in the gray
>>>> This seems to have been done to follow the pattern in the Canvas spec,
>>>> but I find it annoying. In particular, it makes it very difficult to
>>>> document overloaded methods.
>>>> I would like to make a pass through the spec and add the types (and
>>>> overloadings) from the gray boxes into the method signatures in the
>>>> green boxes. Are there any objections to my doing this?
>>> It annoys me, too. But yes it was done to match the Canvas spec (and many other W3C spec styles). If it can be done without adding too much noise, I would be all for adding types.
>> Apologies for the long delay; I've finally made this edit. It included
>> removing the "in" keyword for all function arguments, as it is
>> implicit in the Web IDL spec, and adding a new .idl-code CSS style to
>> handle indentation of the second and subsequent lines if the function
>> signature wraps. Layout should work properly for the overloaded method
>> What do you all think? In general I think this is an improvement.
>> There is a proliferation of uniform* and vertexAttrib* entry points,
>> but perhaps we could abbreviate those. For example:
>> void uniform1f(WebGLUniformLocation location, GLfloat x)
>> void uniform1i(WebGLUniformLocation location, GLint x)
>> void uniform2f(WebGLUniformLocation location, GLfloat x, GLfloat y)
>> void uniform2i(WebGLUniformLocation location, GLint x, GLint y)
>> void uniform3f(WebGLUniformLocation location, GLfloat x, GLfloat
>> y, GLfloat z)
>> void uniform3i(WebGLUniformLocation location, GLint x, GLint y, GLint z)
>> void uniform4f(WebGLUniformLocation location, GLfloat x, GLfloat
>> y, GLfloat z, GLfloat w)
>> void uniform4i(WebGLUniformLocation location, GLint x, GLint y,
>> GLint z, GLint w)
>> void uniformfv(WebGLUniformLocation location, WebGLFloatArray v)
>> void uniformfv(WebGLUniformLocation location, sequence<float> v)
>> void uniformiv(WebGLUniformLocation location, WebGLIntArray v)
>> void uniformiv(WebGLUniformLocation location, sequence<long> v)
> This is a big improvement. Thanks, Ken.
You're welcome. What do you think about using the above shorthand for
the uniform and other entry points?
> I notice there are still a few bad "OpenGL Man Page" links. I'll fix these later today.
> Also, I seem to remember that we talked about collapsing getString into getParameter. Did we decide to do that?
I don't remember whether this was decided in the working group, but we
didn't discuss it on the public list.
It would seem to make the API more consistent. Other thoughts?
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: