[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Should WebGLContextAttributes be a callback interface?
- To: Glenn Maynard <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Should WebGLContextAttributes be a callback interface?
- From: Kenneth Russell <email@example.com>
- Date: Mon, 2 Apr 2012 18:51:32 -0700
- Cc: Boris Zbarsky <firstname.lastname@example.org>, email@example.com, "firstname.lastname@example.org" <email@example.com>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=DFkeC7FR+n9327ycidisYjb/XcWTvfAG3x+0U3gQ2mA=; b=HNM3Ltucc//vscQGO0s2LDQozicCCR2B4RKIYSDIzmovrOEBXdStvASjTXriOv8nL0 Jn6OOd9dTr+XLmLGKDhnQx9JZNJr6KBP0uTOz0/bfRzYLDpfYP+t2E4qTsfYqdAgh1+S VHQ220Oyf39lLIwS7O3tf8GSvTC+WBRP/yrSmyaXO1Zmtqeldr7xXxyHeM8QvE7bpZHc /n3jiEF7rFZcPLyI6IQSf/OMVeyqfqnImJFsiiRgqVJkyEdoGADVkhzxyDTGkbiRzf7d TY8q1JYeZl7Zudgz1Z4UfEFj1kxHhz0vek5Hc2y9suD3WRskhg2RvpFfNVTJXM9dSSnq JxQQ==
- In-reply-to: <CABirCh9H2AN_PpcDqdoU+dNhJG7A98ryFxfRtUrYuXYak-eTKQ@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4F770EAC.firstname.lastname@example.org> <CABirCh-By8L0S_RmzDZEg-x5A0LWaN+8VJ0D-q94GyCC_qVqEQ@mail.gmail.com> <4F7717C6.email@example.com> <CABirCh9H2AN_PpcDqdoU+dNhJG7A98ryFxfRtUrYuXYak-eTKQ@mail.gmail.com>
- Sender: firstname.lastname@example.org
On Sat, Mar 31, 2012 at 8:10 AM, Glenn Maynard <email@example.com> wrote:
> I forgot, I talked with Cameron on IRC a while back about the dictionary vs.
> callback thing:
> The short of it is that if callback is used, all of the members need to be
> nullable, since they're all optional when passed to getContext; or else
> getContext will get a TypeError when reading them, I think? I'm not sure.
> On Sat, Mar 31, 2012 at 9:42 AM, Boris Zbarsky <firstname.lastname@example.org> wrote:
>>> The idea is that the object you pass to getContext *is* a
>>> WebGLContextAttributes, as if getContext's signature is WebGLContext
>>> getContext(DOMString contextId, WebGLContextAttributes attrs), so WebIDL
>>> takes care of type conversions for the members.
>> Hmm. I guess there's no way to actually express this as WebIDL because
>> the second argument would need to be of different callback types depending
>> on the string value of the first argument and callback types are not
>> But that also means that WebIDL cannot in fact really take care of the
>> type conversions, since WebIDL isn't actually being used to define this.
> I agree that it's currently underdefined. I recommended defining this
> ("Convert options to an IDL value of type WebGLContextAttributesInit...").
> I think that fell through the cracks (ping @ Kenneth).
Sorry about that. It looks like I did drop that set of changes on the
floor by accident. Let's resolve this issue now.
Has there been a decision on the best path forward here? The
requirements in the WebGL spec are relatively small; it must be
possible to pass a user object to getContext("webgl", /* attrs */) and
it must be possible to define the attributes and their types returned
from getContextAttributes. Aside from that the existence of the
WebGLContextAttributes interface is not important.
>> I wonder whether it would be worthwhile to extend overload resolution in
>> WebIDL to handle this case by introducing the ability to declare overloads
>> where an argument is a constant and treating all constants as
>> distinguishable. So then the IDL for getContext could look like this:
>> getContext(DOMString "webgl", WebGLContextAttributes attrs);
>> or something... The syntax could obviously use improving.
> Honestly, I'm not sure I'm a fan of the "single getContext method" approach
> in the first place. I think it would have been better to have context specs
> define their own getContext method (eg. getWebGLContext) supplementing
> HTMLCanvasElement, and for Context to just give a framework for that. Oh,
> I'm not sure if a syntax specifically for this would be a good idea, because
> I'm not sure people should be mimicing it and there's only one place it'd be
> used right now (2d canvas doesn't take any other parameters)...
>>> This could also be done by defining it as a WebIDL dictionary.
>> Another option would be to define the getContext() argument as a
>> dictionary but the return value of getContextAttributes as a non-callback
>> type. Assuming that's useful, of course. The behavior would obviously be
>> observably different (e.g. the properties would then live on the prototype),
>> but I'm not sure that gets us anything useful. So yeah, probably OK leaving
>> this as a callback.
> Right, the type would have to be defined twice, which would be a bit
> redundant, though it'll always be a simple type so it's not that big a deal.
> You *can* return a dictionary type from functions, so it could, in fact,
> just define a dictionary used by both getContext and getContextAttributes.
> It'd lose the interface, but I can't think of any use cases for an interface
> there anyway. But I guess there's otherwise no real difference between
> doing that and just making the attributes nullable.
> Glenn Maynard
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: