Re: [AD] official beta (Re namespace again)

[Martijn Versteegh <m.versteegh@xxxxxxxxxx>]

On Tue, Oct 30, 2001 at 06:56:53PM +0100, Sven Sandberg wrote:
>Michael Bukin wrote:
>> One more idea (don't laugh, please).
>> 
>> Add unprefixed variables to the prefixed library and synchronize them
>> in timer function or in functions that change state of certain
>> allegro variables.  This must be optional and can be turned on in
>> unprefixed allegro_init, for example.
>> 
>> OK, now you may laugh.
>
>Hehe :-)
>
>This is definitely undoable. For one thing, it is not even clear which
>variable the interrupt should treat as the correct one if e.g.
>font!=al_font.
>
I think Michael Bukin was joking here ;-)

IMHO Peter's original suggestion was by far the best. I don't know how much
experience you all have with compatability headers which try to #define Rome
into Paris, but my experience is that you never get it right completely, so
having a compatability header which keeps floating around forever in
each new version will be a pain and a burden.

So I'd say keeping a feature-frozen version 4.0 around for compatability
will be less work than keeping such a header up-to-date. The 4.0 lib has to be
minimally maintained to keep working, but as no new projects will be written
using it (because 5.0+ will have all the exiting new stuff ;-) )
chances are new problems will not arise much.

Furthermore such a header will encourage people in using the old api they're
used to, maybe even for new projects. Which is obviously a Bad Thing.

IMHO the split in an unprefixed 4.0 and a prefixed 5.0 without any compatability
baggage is by far the cleanest thing to do. This will also allow us to change
things like the 8-bit palette & the order of dest&src in draw_sprite etc, which would
need very complicated macro-magic/#define-crockery to reverse in a compatability header.

I don't think we need to worry about maintaining 4.0 'for ever' too much either.
In one or two years all projects which are still maintained will probably have
migrated to 5.0 , and projects which haven't made the switch to 5.0 are unmaintained
and probably have rotted more than allegro 4.0 itself, being prevented from working
by other causes anyway. If someone *really* needs allegro 4.0 at that stage: well
then you have a volunteer to do the maintaining ;-).


So I vote for the original proposal:

4.0 -> unprefixed
5.0 -> prefixed, identical functionality to make switching from 4.0 to 5.0 without side
effects as easy as possible.
5.2 -> truly new stuff added

While I don't believe in a 100% working translation tool, a 99% working version of
such a tool would ease the migration from 4.0 to 5.0 a lot, but for this
to be foolproof it is essential that 4.0 and 5.0 have the same functionality (IMHO).


Ok, I think I made my point now and I will try not to write any more followups
on this thread ;-)


-- 

Martijn Versteegh