Re: [AD] Allegro 4.2.0 RC1 timetable

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> Someone on #allegro gave entheh and I a brilliant Idea, making it easier 
for 
> people to chain a builtin datafile object onto a custom one:

Hmm... it looks useful, though I'm too tired right now to pass proper 
judgement. My main concern is that it's a relatively big patch at a late 
stage in development. On the other hand, if it just exposes internal 
functionality, then it shouldn't break anything.
(Note: a quick look at the patch suggests you missed out changing at least 
one static declaration to a public one).

That said,

> On June 4, 2005 02:40 pm, Chris wrote:
> > AFAIK, we're not using a newer naming scheme until 4.3 to avoid
> > confusion between the new API and old. IMO, the names should be left
> > alone. Also, what's the point of the two unload functions? Wouldn't
> > destroy_sample/destroy_midi be enough?

Chris is quite right in pointing out that the al_ naming scheme is 
inappropriate here. I know there are already exceptions in the API as it 
is, but I personally don't want to add more at this stage.
There's also something else to consider: we're going to move the current 
API to the 4.3 compatibility layer. The fewer API functions that need to 
be put there, the better.
Should we include this patch, then I'd keep the original names instead of 
renaming them with the al_ prefix. For some functions, the risk of 
namespace collisions might make this undesirable though. I'm not sure how 
to handle that.

Evert




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/