Re: [AD] Proposal for new Allegro interface

[Sven Sandberg <svsa1977@xxxxxxxxxx>]

Laurence Withers wrote:
>  - increases complexity slightly, both when maintaining code and
>    when adding new stuff (because you need to think of two function
>    names :-P ).

There's hardly any reason to add non-prefixed versions of new
identifiers, so I don't think this is a problem.

I agree that if something should be done, then what you suggest is very
close to it. I even think that making palettes be 8 bit will work
smoothly: As long as all old-style functions continue to assume 6-bit
palettes, there's no harm done if the prefixed functions use 8-bit
palettes. There are four `extern PALETTE' variables, but those don't
seem to be any problem either (black_palette isn't even different in 8
bits, desktop_palette and default_palette are not read by the library
anyway, and I don't think fli_palette is either).

I have a couple of additions to the "Minus" section though:

 - What about variables? I think the only way to create aliases for
these is with #defines. And this will be a problem for C++ programs
which have member variables called e.g. `screen', `key' or `font', if
one file that uses the class #includes <allegro.h> and another doesn't.
This happens e.g. if the class is defined in some library. IMHO `key'
and `font' are some of the worst namespace polluters so it would be a
pity not to get rid of them.

A possible solution would be to make `key' be the actual name of the
variable and `al_key' the macro (because `al_key' is a lot less likely
to appear in people's code). OTOH, this only solves the cosmetic problem
that only 99% of the identifiers would be available in prefixed form. It
still doesn't allow you to define your own variable named `key'. It also
makes this limitation a great deal more subtle.

 - Another problem is that some compilers (at least watcom) don't remove
unused static functions, so that each object file will contain tons of
such. Moreover, each such static function will contain a dependency to
some part of Allegro (and conversely: each and every function in Allegro
will be used in one of those functions), so that literally _all_ of
Allegro will be linked in on those platforms. And it will require you to
link with Allegro, which wasn't strictly needed before if you only used
e.g. inline math functions.

Luckily gcc and msvc are smart enough to remove unused static functions
and maybe we don't need backwards compatibility (i.e. aliases) for other
platforms? AFAICS except for watcom they have only existed in fairly
recent wips, and who uses watcom anyway? :-) No, I don't think this is a
good solution.

> Please send your thoughts. If generally positive, and nobody raises
> any unsolvable technical issues, I'll write a patch and submit it for
> examination.

To the person who implements this, if it ever happens: it can be done
fairly automatically by modifying the AL_FUNC() & co macros, e.g.:

   #define AL_PREFIX_FUNC(return_type, func, args, call_args) \
      return_type al_##func args; \
      static INLINE return_type func args \
      { \
         al_##func call_args; \
      }
[...]
   AL_PREFIX_FUNC(void, floodfill, (BITMAP *bmp, int x, int y, int c),
                  (bmp, x, y, c));

This ought to cut down the work a lot (though of course we don't want
`al_allegro_init()' so not all functions can be handled this way).

But I would personally vote "no" unless someone comes up with good
solutions to the problems I mentioned.

Sven