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

[Michael Bukin <M.A.Bukin@xxxxxxxxxx>]

Discussion topic: just how crazy is that crazy idea?

Martijn Versteegh <m.versteegh@xxxxxxxxxx> writes:

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

External code will use unprefixed symbols (existing programs with
Allegro ~3.12 API), Allegro code will use prefixed symbols.
Interrupts are discussed below.

There are Allegro functions that change state of variables and
functions that only read state of variables.

Unprefixed version of prefixed function which changes state of some
prefixed variable should update corresponding unprefixed variable
after calling prefixed function.  Likewise, unprefixed version of
function which reads state of some variable, should synchronize it
with unprefixed variable before calling prefixed function.  When
variable is used inside interrupt, we may add callbacks or hooks to
synchronize variable state before it is used.  Program's should not
use the mixture of prefixed and unprefixed APIs (only one at a time).

I don't think this approach will impose noticable slowdown (for most
functions).  But implementing it will be a lot of pain (who is going
to determine which variables are used in each function?).

BTW, I also think that unprefixed version should be released as 4.0
and should be maintained (fixing bugs, no new features).  Ideas
discussed above are for 5.0 and later versions (if anyone is going to
make unprefixed API on top of prefixed one).

P.S. IMHO, different API deserves new major version number (not 5.2,
but 6.0).

-- 
Michael Bukin