Re: [AD] Allegro generalization/extension mechanism

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


On Tue, 2005-03-15 at 02:40 -0800, Chris wrote:
> guilt wrote:
> > It doesn't change a bit, right? So what's the problem.
> 
> Dependancies and licensing.
> 

Download-size might be the 3rd. If e.g. loadpng stays a separate plugin,
I can update it anytime by just downloading the addon and recompiling
(or in case we make all the addons shared libs, everything could stay
binaries even), and not having to update the huge Allegro for every
change in one component.

And 4th might be complexity. Having a lot of simple libraries will be
much easier to maintain and work with then one huge complex. But that's
just my opinion of course. You can always argue that just organizing the
code better achieves the same. But if I make it separate libs, even the
worst organization still would be good - not so in the case where every
addon is stuffed into CVS and then all (ab)use internal global
variables. If I want for example use OpenGL, then of course we might
suceed in writing the code so with static linking Allegro's gfx system
isn't linked in (or we might not). If there's a separate addon with
drawing primitives, there would be no question that it works, without
even spending a thought on it. And that addon could then easily support
things like anti-aliased primitives as well.. which would be harder to
simply put into the core Allegro. So, well, splitting it just would
inherently organize it better, IMHO :)

-- 
Elias Pschernig





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