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

Re: [Public WebGL] Please review WebGL multiple render target extension proposal

 The next reason to stick to the suffixes is because people already used to C, are used to them

Just for the record, I don't really think this reason holds up IMHO because WebGL itself drops the "gl" prefix from function names that was present in C (and numerous other languages). This decision really surprised me when I started learning to use WebGL and I think it demonstrated a willingness to diverge from established conventions where the conventions themselves have lost their purpose (namespacing). Just my opinion.

Personally, I agree with Florian that the suffixes are mostly superfluous, most especially the _WEBGL suffix because from a human perspective, we already know it's in reference to WebGL.

On Wed, Nov 7, 2012 at 5:50 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Nov 7, 2012 at 2:36 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 16, 16, 0, GL_RGBA, GL_HALF_FLOAT_OES, nullptr);

WebGL with vendor decorations:
var ext = gl.getExtension("OES_texture_half_float");
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 16, 16, 0, gl.RGBA, ext.HALF_FLOAT_OES, null);

WebGL without vendor decorations:
var ext = gl.getExtension("texture_half_float");
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 16, 16, 0, gl.RGBA, ext.HALF_FLOAT, null);

Given the documentation we already do for WebGL extensions, I don't think the second case has any benefit over the third.
It was about the suffixes, not the extension prefixes.

The original reason for suffixes was that symbols/constants needed to co-exist within the same flat namespace in C. This reason does no longer exist in WebGL. The next reason to stick to the suffixes is because people already used to C, are used to them and it represents a 1:1 mirror to the existing extensions. This reason really only applies to any suffix but _WEBGL. The last reason to stick to the _WEBGL suffix would be such as not to confuse people who've got some auto-wrapper code that derives the suffix from the prefix, and we wouldn't want them to have to write something like if(extname.match(/.*?_WEBGL$/)){ suffix = ''; } else { suffix = extname.match(/([^_])+$/)[1]; }.

I'm not in favor over abolishing prefixes on extension names, mainly, because this turned out to be impossible in a process of painful discovery of heated opinion.
I am 100% in favor of not supplying the WEBGL *suffix*, but some would probably not agree.
I would be absolutely ok skipping any *suffix* because, they're really superfluous. but more would probably not agree.