[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
I agree. It's what I had in mind.
But when incrementally improving the API, we(*) should look at the work
that was done in defining A5; no point in adding a new function which is
just a slightly less broken version of its A3 counterpart.
(*) Whoever gets to do the work.
> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of Elias Pschernig
> Sent: Thursday, July 22, 2004 3:15 PM
> To: alleg-developers
> Subject: RE: [AD] Prefixing
>
> On Thu, 2004-07-22 at 13:23 -0700, Robert Ohannessian wrote:
> > Perhaps we(*) should move towards A5 instead?
> > http://alleg.sourceforge.net/future/keyboard.txt
> >
> > At least some of it can be implemented on top of the current A4.
> >
> > For example,
> >
> > bool al_key_down(AL_KBDSTATE *state, int keycode)
> >
> > This would be just like the al_key() you proposed, except we leave
the
> > first parameter (state) reversed for future use - must be NULL in
A4.
> >
> >
>
> Yes, I was already browsing through http://alleg.sf.net/future/
before,
> and a lot of things could go in. Angelo already offered to put in his
> config system. Actually, even things like your GFX API could for the
> most part be done with the A4 drivers, so we at least would have that
> API. I also discovered there a completely prefixed A4 API by Grzegorz,
> something which I'd apply at once. I'm getting confused of A4/A5 now
> though..
>
> (*) <- That's the main problem. Who is "we"? Someone needs to do
better
> than the allegro_new module or Peter and you with your A5 core
> implementations. So I'm afraid looking towards A5 is simply out of the
> questions, by lack of someone to do it.
>
> Which brings us back to A4. Where we have Peter's vicious circle.
Which
> we can only break out of (with the current developer situation) in two
> ways, both of which have something good and something bad:
>
> 1. Don't improve API, but stay backwards compatible.
> 2. Improve API, but don't stay backwards compatible.
>
> Or, well, Peter formulated it like this:
>
> > Improve the API incrementally. Maintain compatibility wherever
> > reasonable.
>
> Which is very wisely formulated, and very open to interpretation :)
>
> I'd interpret it as, improve the API, just like e.g. myself want to
do,
> with all the ideas of improvement so far, including prefixing - but
keep
> a compatibility header (and maybe even a compatibility .c) around, so
> 4.0.0 apps will keep working. Ben or maybe someone else before
suggested
> to make "include <allegro.h>" include the compatibility stuff, and
make
> "include <alleg42.h>" not include it, which would solve the problem of
> the compatibility being default or not.
>
> --
> Elias Pschernig
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers