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

Re: [Public WebGL] Extension interfaces should be [NoInterfaceObject]

I've not yet have had a reason to use the interface object. I'll presume it would be for things like adding stuff to its prototype, which you only really do if you need to write a shim. I can't conceive of a need to write an extension shim. So I don't think not having the interface objects on the global object matters. I would also certainly not object to any kind of naming scheme on the interface object. I would suggest however to stuff them somewhere in their own namespace on top or as alternative to a clearly webgl associated naming scheme. Either way, it doesn't matter for me. So no objections here.

On Thu, Oct 11, 2012 at 8:57 PM, Benoit Jacob <bjacob@mozilla.com> wrote:

Currently, the IDL for extensions speficies interfaces names in a way that forces compliant implementations to expose them on the global object. For instance:

interface WEBGL_compressed_texture_atc 

There is a concern about polluting the global object with arbitrarily many names that may not even be easy to trace back to WebGL for someone not versed in WebGL, for example OES_standard_derivatives.

WebIDL has a provision for that: the [NoInterfaceObject] attribute. It is documented there:

Do you agree that we should use it here? So we could add arbitrary extensions without having to worry about their names polluting the global namespace?

If we agree on this, we should email public-script-coord@w3.org as asked for in the above link. That would make WebGL extensions "supplemental interfaces". In my limited understanding, the concern here is that [NoInterfaceObject] is a ECMAScript-specific feature. I may be missing something else though.

The alternative, I guess, is to rename WebGL extension interfaces to something more cleanly namespaced, e.g.:

OES_standard_derivatives  ->  WebGLExtensionStandardDerivatives
EXT_texture_filter_anisotropic  ->  WebGLExtensionTextureFilterAnisotropic

which is FWIW what we do in Mozilla's C++ implementation.