On Jan 26, 12:32 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > Carl Banks <[EMAIL PROTECTED]> writes: > > AirplaneInterface = InterfaceTracker("Airplane") > > ... > > set_up_initial_state() > > ... > > AirplaneInterface.report(self) > > Thoughts? (Surely someone's thought to do this before.) > > A decorator might express the idea a little more naturally.
Details. I didn't thoroughly map out the whole system in my head or anything. > Also, I'd say the interface tracker really should be told explicitly > when something is part of the interface and when it's specific to a > particular class implementing the interface. It shouldn't try to > guess this based on some operation appearing in more than one class. Well, that kind of defeats the purpose, doesn't it? If you're going to all that trouble, it's probably not too much more trouble to just manually specify the whole interface and be done with it. Anyways you don't always know what's going to end up as part of the interface in early stages. It goes without saying there should be ways to manually override the interface tracker's decision, but that falls more into the category "So your interface tracker has guessed wrong". > Maybe there's some operation done on all jet planes and on no > propeller planes, that shouldn't be part of the top level airplane > interface. Well, then the interface tracker would see that some member (say, "set_mixture") exists on some objects and not others, and would consider it not part of the interface. Only members that are defined universally or nearly universally would be considered part of the interface. Now if you're concerned that you could implement a bunch of prop planes, and then suddenly you throw a jet in there and it breaks everything, there's a simple solution: convert the AirplaneInterface to PropAirplaneInterface. (Yeah, suck it up and replace it everywhere. If you haven't implemented any jets you shouldn't have released the damn thing yet.) Create a new JetAirplaneInterface tracker and (if useful) define Airplane as the union of the two. Obviously something like this could get really intelligent--it could perhaps work out the difference between props and jets itself (using, say, statistical correlation). I bet there are some high-end code analysis tools for various languages that do stuff like that. (But I doubt many of them factor time into it; my idea was to incorporate time into it somehow. Something does not become part of an interface until it's universally used AND has been around for awhile.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
