RE: [AL] whatever has been done to clear breaks STL

[Shawn H. <sha...@cl...>]

>  The simplest way,IMHO,would be for the programmer to specify the
>  Allegro version for which he coded his program,so the casual user
>  will use that version to build it.This way Allegro 4+ could get a
>  shiny new interface without the compatibility problems...

That strikes me as a bit of a cop-out: "keep both versions and let
people choose" is easy for developers in the short term, but can
cause a lot of confusion among users, and creates a huge 
maintenance nightmare a few years down the road as all these 
alternative implementations start to overlap.

Just look at the difference between D3D (which changes the API each
version, keeping old ones around as alternatives) vs. OpenGL (which
basically got it right the first time around, and then just puts up
with a few minor not-quite-right things in the interests of keeping
compatibility).

> > I've had to use a few "moving target" API's in the past,and 
> always hated them...
>  AFAIK any API change is for the better,so people that want to take
>  advantage of it won't complain about having to change their code.

I complained bitterly when this has happened to me in the past! The 
newer versions had more features, some of which I needed, but that 
didn't mean I was happy about having to update lots of other 
already-working code to account for the changes.

I think breaking an API is usually just laziness and poor design on 
the part of developers, and not a fair thing to do to users. There 
are almost always better solutions, and if not, it's worth living with 
a not quite optimal design. Breaking a major public API should be seen 
as a once-in-a-lifetime option that you can only use when the old design
is absolutely fundamentally broken, the new one is perfectly and
indisputably a massive and elegant improvement, and everyone involved
is 100% unanimously in agreement that the changes are worthwhile.

It is very hard to get a fair assesment of this kind of thing because
all the people who read mailing lists are the ones who follow library
developments regularly, are interested in the details of all new
features, etc, and are generally going to be quite ok about changes.
Just remember that for everyone you talk to who thinks this is a good
idea, there are thousands who aren't subscribed to any lists, don't
talk much to other library developers, but still use Allegro as a
crucial part of their work and would like it to just go on working
without requiring them to think about it too much...

>  P.S.
> >You may notice that a lot of the code in Allegro spells 'palette' as
> >'pallete'.This is because the headers from my old Mark Williams
> >compiler on the Atari spelt it with two l's,so that is what I'm used
> >to.Allegro will happily accept either spelling,due to some #defines
> >in allegro.h.
>  
>  Pallete (set_pallete()) is only used *once* in exquat.c ...

It's used once in the Allegro example programs, also a few million times
in all the Allegro games written by people all over the world. _Those_
are the ones who get annoyed if their program suddenly stops working
for some reason!


	Shawn.