Re: [AD] object oriented AL_SYSTEM

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sun, 2006-08-27 at 20:36 +0100, Peter Hull wrote:
> What would the system object be used for? (from the Allegro user's
> point of view)
> 
> There will only be one instance of it (unless we can see a need for
> multiple independent Allegro systems running in the same app?) and it
> shouldn't be a global variable (for DLL/.so linking issues)
> 
> Then say we wanted the OS name, the user's code could be
> // Option 1
> const char* os = al_get_os_name();
> or
> // Option 2
> AL_SYSTEM* sys = al_get_system();
> const char* os = sys->os_name;
> 
> The former style has more flexibility* but more impact on the namespace.

Yes, I was thinking of option 1. And there would be an _al_get_system,
so internally it would be:

char const *al_get_os_name()
{
   AL_SYSTEM* sys = _al_get_system();
   return sys->os_name;
}

The second option also would work of course - it just would mean, we
allow direct struct accessed in the user API.

And once we do a precedence of not using an accessor function for
something, we can then do away with all the other useless accessor
functions as well :) We should decide generally if we want get/set
functions or struct access. E.g. either we do: al_bitmap_width(bmp) and
al_bitmap_color_depth(bmp), or we do: bmp->width and bmp->color_depth.
The current 4.2 way just is inconsistent.

Myself, I would vote for no struct accesses:
* We can then have asserts inside the set/get functions (accessing a
NULL bitmap crashes already in 4.2 without any assert.. but still).
* We make it very easy to use it all from other languages - basically
the .dll/.so can just be loaded and all functions can be used, no glue
code of any sorts is needed.
* By #including the allegro/internal/* headers and using _al_*
functions, addons/language bindings still get full access to all
structs, if they need it.

-- 
Elias Pschernig