I'm not so sure the namespace definition needs to be so rigid. In a model
where extensions are available only through GetProcAddress, its not clear to
me that the API has a lock on these symbols in the way you suggest.
In fact, if as you suggest, people should use a symbol name _other_ than the
function name, its almost meaningless to define the function name, other
than as a string for GetProcAddress. As I see it, using the function name
directly is semantically correct, and GetProcAddress provides a means for
runtime linking instead of static linking. This allows the developer to
program to the specified API rather than some modified version of the API to
work around header file conflicts.
> -----Original Message-----
> From: Jon Leech [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 09, 2000 1:06 PM
> To: [EMAIL PROTECTED]
> Subject: [oglbase-discuss] Namespaces
>
>
> On Tue, May 09, 2000 at 12:09:48PM -0700, Michael I Gold wrote:
> > > From: Jon Leech [mailto:[EMAIL PROTECTED]]
> > > Because such code is inherently nonportable by claiming
> part of a
> > > reserved namespace, yes.
> >
> > The whole point of making static declarations and glext.h
> mutually exclusive
> > to to effectively redefine the namespace so that these
> symbols are not
> > reserved.
>
> The namespace is 'gl*'; it's not a property of whether
> the ABI is in
> use or not, but a property of the OpenGL API itself.
>
> If there are apps infringing on this namespace today that will be
> affected by the particular structure of glext.h, that's important to
> know so we can try to cope with it - but nonetheless those
> applications
> are intrinsically unportable and are incompatible with the API.
>
> Jon Leech
> SGI
>
