Here are two pros to having a libkeryx that interacts with definitions: Python has no true private classes, meaning when we say that something in the base definition cannot be overridden, what we mean is that the developers of project definitions are supposed to play by the rules and not override them (aka the "we're consenting adults" theory of OOP). If we have libkeryx, then those functions can be separate from definitions.If we use libkeryx as something other than a base class, it would be the ideal place to manage multiple projects that are opened simultaneously (one of the stated goals for 1.0). If we did not use libkeryx as an intermediary, then UI code would have to handle opening projects.Those are just two advantages to that approach I can think of off the top of my head. One disadvantage would mean we would have to write more code, but I think the extra code overhead would be rather small.
Another question would be this: if we do not use a libkeryx, then where are plugins handled? Note that when I say plugins I mean modular code designed to extend the functionality of Keryx, not project definitions. -- Douglass Clem Chief Technology Officer, Crashsystems LLC (crashsystems.net) Public Key: 37F9 E685 576A CFD3 B08C
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~keryx Post to : [email protected] Unsubscribe : https://launchpad.net/~keryx More help : https://help.launchpad.net/ListHelp
