At 02:58 PM 11/4/99 -0700, you wrote:
>
>John, I agree that it is possible to come up with a mechanism to find all
>possible 3d drivers, then query them to determine which extensions they
>support. But it seems like a lot of work to me, and I don't see any reason
>to do it. What is your reasoning for wanting a NULL pointer to indicate
>that "no currently available driver supports this extension"?
Since we have apparently succumbed to the inexplicable desire for context
independent pointers, there is no obvious benefit to returning a NULL
pointer for an unsupported entry point. It indeed creates more work; each
driver must be prepared to return a list of all supported extensions for
all supported visuals, and the list may differ from one visual to the next
(e.g. color index vs rgb extensions). Given that this whole exercise is
designed to simplify programmer's lives and punish implementors, we _could_
take this additional step.
On the other hand Jon raises a valid point which was lost on me until I
studies his example more closely. If we always return a valid pointer, the
application could be query "foo" and "yo-mama" with no less success than
querying "glActiveTextureARB". The useful diagnostic here is whether or
not the app has correctly spelled the name of the entry point. If he has
not, and instead queries "glActiveTextureARV", are we doing him a favor by
returning a valid pointer? I would argue "no".
I believe the best compromise would be to always return a valid pointer for
any arbitrary string the app queries, but if a given implementation does
not support the entry point (even if other drivers on the system do), let
it crash in the dispatch (he says, in his typically callous manner). That
serves both purposes, and the app programmer will know right away that he
did something wrong.
