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

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

At 16:13 25/10/01 +0200, a.mottola@xxxxxxxxxx wrote:
>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... 

I think that would be a good idea, although if we keep backward
compatibility (see below), then a stable 4.1 release would IMHO do just as
well.

>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...

I disagree here: only old features that were in 3.11 need to be included
here, which means a lot of things don't have to be #defined (unless some
compatibility with the WIP versions is desired).
What messyness there is will be confined to the allegro3 header.
Although requiring old programs to #include allegro3.h instead of allegro.h
would also break existing code, this would not be too bad, as it is very
easily fixed.

>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. 

Allegro already does some pretty ugly things to make it platform
independant or easy to use. The _mangled_main and END_OF_FUNCTION() macro's
come to mind.

[snip]
>- 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.

I disagree. I have a lot of code sitting on my HD and it would be a pain to
rewrite it all. Frankly, I think I'd just stick with the last backward
compatible WIP. If I need to update my computer just to be able to run the
newest version of a piece of software, I'll just go on running the old
version because transfering everything to a new system is so much trouble.

[snip]

>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).

Frankly, I never found the Allegro API confusing in anyway. On the
conterary, I always found API's where you had to use weird prefixed names
more confusing. Then again, I probably learned programming in an evil time
period or in an evil language where it wasn't common practice to do that
sort of thing. ;-)

>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...

This would be a good idea. but what about variable names?
Alternatively, what would be the effect of creating a header that has
backward compatible #defines in it, and then asking the compiler to output
the data from the preprocessor? Wouldn't this do about the same?

Evert