Re: [AD] font vtable patch

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> A wrapper around ``blessed'' internals?
>
>     void *allegro_get_internal(AL_CONST char *key);

I like the idea of some sort of a wrapper. With such a scheme, we could
export only the regular API symbols plus this single one. The question is
then which kind of dynamic linking we would use to implement it ?

Either run-time linking as you are suggesting: the program must query
Allegro for each internal symbol it wants to use and work around the
problem or terminate if the symbol is missing.

Or load-time linking: we build up in the sources a table of all internals
that we want to be exported and export only this table. Therefore we still
have only the regular API symbols plus one, this latter being a variable
rather than a function.
An add-on calls a specific internal with the help of a macro:
   if (AL_INTERNAL(_textmode) < 0)
      /* render as transparent */
   else
      /* render as opaque */

with somewhere in allegro.h:
   #ifdef STATICLINK
      #define AL_INTERNAL(symbol)  symbol
   #else
      #define AL_INTERNAL(symbol)  *(internals_table.##symbol)

This solution seems to be lighter than the previous one, but of course less
safe.

> A condition of using this function is that internals might become
> unavailable in future.  Use it now, get burnt later.

That's the rule of the game with internals. And the wrapper mechanism is
there to make it clear that internals are not just like other symbols.

> A better idea may be just to move said ``blessed'' internals into a
> separate header file (ainternbutnotreally.h).

But then they would still be exported with the same status as API symbols.
Does the wrapper mechanism not ensure total binary compatibility for user
programs using only API calls, even if we add or remove some internals ? I'm
not sure this is the case with this solution under Windows.

> But that still leaves the question of which ones to bless.

Quite right. And I'm more and more thinking that the safest way is to bless
every platform-independant global internal: if Shawn chose to make it
global, this is because some other parts of the library, that could
eventually be enhanced by an add-on, use it.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx