On Jan 26, 5:03 am, Carl Banks <[EMAIL PROTECTED]> wrote:
> While thinking about generational garbage collection, the thought of
> generational interfaces occurred to me. I'd thought I'd run it by you
> guys. I'm curious if there are any examples of this out there.
>
> I've opined on this chat room before that interfaces are more often
> cumbersome than helpful, especially in the early stages of a project
> where lots of refactoring is (or ought to be) happening. But as
> projects mature, interfaces do too, and that made me think interfaces
> could be generated automatically by monitoring the software over time.
>
> As an example, say I'm writing a flight simulator, and I have a
> abstract base class Airplane, that I want to have an interface
> someday, but I don't know what it is yet. So I define an
>
> AirplaneInterface = InterfaceTracker("Airplane")
>
> What this does is to open a sort of persistent database called
> Airplane (details aren't important now). The database tracks all
> objects that claim to implement the interface.
>
> So say the first airplane is a Piper Cherokee. I'd write a class like
> this:
>
> class PiperCherokeeX1(object):
> wingspan = 52.2
> wingchord = 7.9
> ...
> def __init__(self):
> self.x = 0.0
> self.y = 0.0
> self.z = 0.0
> ...
> set_up_initial_state()
> ...
> AirplaneInterface.report(self)
> def move_stick(self,dx,dy):
> ...
> def move_thottle(self,ds):
> ...
> def move_rudder_pedals(self,ddr):
> ...
> def camera_matrix(self):
> return self._quat_to_matrix(self.q0,self.q1,self.q2,self.q3)
> def step(self,dt):
> ...
>
> The key here is the call to AirplaneInterface.report() at the end of
> __init__; this tells the interface tracker that, as of this call, this
> object is implementing the Aircraft interface.
>
> At this point, the interface tracker notes that PiperCherokeeX1 object
> has certain methods (move_stick, move_throttle, etc), certain class
> attributes, and certain instance attributes. And that's all it does--
> at first. It just writes information into the database.
>
> As time passes, and development continues, methods and data are added,
> changed, reconfigured. For instance, I might split up move_stick()
> into move_stick_x() and move_stick_y() for some reason. Then I might
> get rid of these functions altogether in favor of a
> move_control(self,n,dx). And so on. I add more classes that
> implement the Aircraft interface, too. They look almost nothing like
> the original interface.
>
> However, through all that, the class attribute "wingspan" remains
> there. Until one day when the project is quite mature I add a new
> class, say Airbus380, that fails to define "wingspan". When this
> class calls AirplaneInterface.report(), it raises an
> InterfaceException.
>
> Basically, the InterfaceTracker decides, after some threshold of
> nearly universal usage of a certain method or attribute, that it has
> become a required part of the interface and starts raising exceptions
> when it's not there.
>
> Make sense? Details can vary, but that's the basic idea. In this
> way, you can combine some of the openness that helps in early
> development, but also have some of the benefits of stricter typing
> when things mature and turn out to be pretty strictly useful, without
> much effort.
>
> Thoughts? (Surely someone's thought to do this before.)
>
> Carl Banks
I thought a major use of an interface is to allow separate development
that comes together at the interface. If so then such fluid interface
changing would scupper separate development.
- Paddy.
--
http://mail.python.org/mailman/listinfo/python-list
