> <boiled down version of George's exmaple>

I'm not sure if it was clear to you, but my problem is the dummy
WorldModel_v1.MovableObject class. It doesn't do anything by itself,
but it has to be in the inheritance chain to make its descendants work
properly.

> Are you using the *_v1 naming convention for backwards compatibility?
> Backwards compatibility is a giant pain in the ass, I notice you are
> posting from a .edu address so if this is just something you are
working
> on by yourself or in a small group drop the versioning aspects from
the
> code.

Sure, if there was a single version there would be no need for this
post, but that's not the point; backwards compatibilty is part of the
sad reality. I'm trying to write a client for a framework that has gone
through 9 protocol version changes so far and now goes for the 10th.
There are 5-7 different game object classes, so this makes 50-70
classes overall for the ten versions. Most of them would be dummy like
the WorldModel_v1.MovableObject in the example. So the candidate
solutions so far are:
1. Write the dummy classes by hand.
2. Generate them on the fly using some metaprogramming technique
(introspection/metaclass/?)
3. Find an appropriate design pattern that avoids the need for the
dummy classes.

Any ideas for (2) or (3) ?

George

-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to