[AD] Namespace again (was Problems with gcc 3.1)

["a.mottola@xxxxxxxxxx"<a.mottola@xxxxxxxxxx>]

> > > Me praises for a day when Allegro will be prefixed and there 
won't be
> > > more
> > > tricky defines and more compatibility problems, just a uique and 
free
> > > of name crash API =)
> >
> > and then all the functions should be al_function(...
> >
> > what a waste writing lots of useful al_ when u could not
> 
> Personally I like to write 3 letters more for each function instead of
> having to use
> #defines every here and there, taking care of the headers order or 
having to
> use another header if i want to use the windows api as well.

Agreed. And I know that many people will not agree, but I'd REALLY like 
to push for these prefixes to be inserted *before* Allegro 4 gets 
released... Any modern API worth of its name has prefixed functions to 
avoid all the problems we've had; only Allegro is sticking with 
unprefixed names for compatibility sake. Now I'm not against backward 
compatibility, I indeed think it's a good thing, but a .0 release may 
have the right to break compatibility, in sight of the future. IMHO 
it's better to break it now than waiting for the 5.0 release (whenever 
it'll be) or - even worse - breaking the API in a WIP after the 4.0. 
What I want to say is that this is a thing that must be resolved *now*, 
expecially as the next WIP 3.9.40 is meant to be the last one before 
the point zero version.
Just think Allegro 4 will probably become much more widely accepted 
than any previous WIPs; it'll be a reference version as 3.11 has been 
for a long time, so it's better if we provide the (expecially the new) 
users with a better, prefixed API since the beginning.

The whole idea of providing #defines in a "allegro3.h" header for 
backward compatibility, defining prefixed functions as old ones is 
nice, but I have serious doubts it'll ever fully work. Actually I think 
it could just contribute the lib to be messier...

So I'm for a more drastic change, and add prefixes all over the library 
now, without messing up with defines or whatever dirty hacks to keep 
compatibility; some words about this could be clearly specified in the 
docs. This brings the following possible scenario:

- coders which have been following WIPs, and that are thus actively 
developing programs with Allegro, will have to update their code to 
make it to work with Allegro 4. This will require some work, in some 
cases a lot of work, but it'll be done once and for all also in sight 
of future WIPs that will never fully break the API again.

- coders which were still using Allegro 3.11 (are there a lot of 
these?) will be disappointed at first, but if they care about their 
programs and they want to bring them out of the DOS arena, will be 
forced to update their code, falling in the category above; otherwise 
they'll keep on using Allegro 3.11 to compile their programs, as the 
lib will never vanish anyway...

- old programs written for Allegro 3.11 and previous releases that will 
not be updated to the new API could also mean their coders don't care 
about them that much anymore, and that they prefer to keep them as 
executable versions only, as the code will not compile with newer 
Allegro versions anymore. I don't think we should worry too much about 
this category.

- newcomers will find since the beginning a clean and robust API, 
without any namespace conflicts, and they'll just love Allegro =)

A lot of people nowadays doesn't know about Allegro, or they think 
about it as an old DOS only library. When Allegro 4 gets released, it 
is supposed the word will be much more widely spread, and we'll get a 
lot more newcomers, at least IMO.

I don't like the idea of updating my programs to a new prefixed API, as 
many (all?) of you. But I think time has come to take the decision, 
before it's too late and Allegro 4 gets known worldwide for its 
confused API (ok, maybe I'm exagerating, but you got it).

Ok, I'm now wearing my fireproff suit preparing for flames... =)

Angelo

PS: an idea to help in the transition could be to ship with the lib a 
small script/program that gets source files as input and replaces 
public Allegro function calls using the old unprefixed names with new 
prefixed ones. This could be used to help coders in their move to the 
new API...