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

[Javier González <xaviergonz@xxxxxxxxxx>]

I must agree 100% with this mail =)


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