Re: [AD] Allegro 4.2 todos

[Angelo Mottola <a.mottola@xxxxxxxxxx>]

>> This is the case when we have to take a choice. Personally I'd prefer to
>> let the user choose if to code his program supporting threads/mutexes, and
>> fail to execute at startup by checking if install_threads() fails.
> 
> You are indirectly advocating to drop DOS support here, by pushing a feature
> that can't be even worked around on this platform. I think that's a
> "political" decision, not a mere technical one.

No, never even thought about dropping it here. I proposed an approach to let
the user test if the thread support is there, and act accordingly.

>> Coders working with threads and mutexes are likely not to be interested in
>> porting to DOS anyway...
> 
> What of Unix without threads?

It'd be the same as under DOS or any other platform that doesn't support
threading: just that install_threads() fails and the program should either
fail returning an error message or work around the need of threads/mutexes.

>> Humm, already commited a patch that makes the lib and all the
>> programs/examples to use a private _al_rand()/_al_srand() interface. Seems
>> the best solution to me and also gives pretty good results here.
> 
> This is blatantly contradictory: how can you make examples use a private
> function !???? Either it is private and you can't advertise it in examples,
> or it is public and you can. No middle position.

Humm, you're right. But then we're at the starting point again: we can't
have it private if we want it in the test program (as first case) and in the
other apps (examples, etc.). And if we make it public, how to call it?
al_rand() comes to mind, but then it sounds like an al_ prefixed function in
an unprefixed library and this is bad IMHO. rand_ex() could fit well enough.

Ideas?

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx