Also, there needs to be an update strategy for applications. It is
very helpful that a compatibility layer exists. For example, FB was
designed with sdlpl 1.x, and as sdlpl 2.x was not compatible with
it,
or I didn't know how to do it, I finally had to write the "surf" sub
and friends to be able to use both versions, and let distros upgrade
smoothly. This creates problems. Or your new SDL needs to be
parallel
installable with the old one, and FB would be migrated to using the
new one only months after the new one is released, to wait for
propagation in distros.
I think we can do the second one. Maybe we can seperate the SDL
view code
from frozen bubble main logic so that we can swap SDL versions.
Sort of like
an interface. Similar to how DBI does it. What do you think?
I think if you write your SDLX sugar layer and make it compatible with
sdldl 2.x, then no need for such an interface, and all sdlpl
applications can upgrade to using your new SDL+SDLX stuff without a
code change. It seems better.
There probably is going to be a little change but not as drastic as
now. The biggest problem I see is the fundamental type has changed but
if SDLX:: bless the SDL objects to hash refs we should be fine. I
think ... breno is better at this stuff let me ask him.
He has already written a SDLX::Rect.
--
Guillaume Cottenceau - http://zarb.org/~gc/
