How to devise run-time pluggable classes? (MRO problem)

Discussion in 'Python' started by =?iso-8859-1?Q?Fran=E7ois?= Pinard, Aug 20, 2005.

  1. Hi, everybody. I wish someone could advise me.

    I'm running in circles, trying to find an elegant way to devise run-time
    pluggable classes. It all goes around method resolution order, I guess.
    (We already use various solutions, but the maintenance burden is high.)

    We have a common module containing many basic classes, but for the sake
    of simplicity here, I'll use only Element and Connection. Next to this
    common module, we have many "plugin" modules importing it, and each
    plugin also defines an Element class having common.Element among its
    bases, and a Connection class having common.Connection among its bases.
    Or nearly, as some plugins just do not override common classes that just
    "fit" like they are. Plugins are really meant to enrich common classes.

    The common module and all plugins are part of a single package, but
    there are many other packages meant to provide work schemas, installed
    separately and maintained by different programmers. Each work schema
    package contains a core schema module which, after having imported the
    already installed common module above, defines tons of classes having
    either common.Element or common.Connection in their bases, relating
    them, and a schema class reaching everything, for applications to use.

    And finally, we have a flurry of applications. These applications
    import at least one and typically a few work schemas, and for each,
    specify _at run time_ which plugin to use (we use an URL-like syntax for
    specifying plugins, work schemas, and other various parameters, these
    URLs being read from configuration files while applications progress).

    So, while all work schemas are programmed to use classes from the common
    module, I would need at run time that all base classes be automatically
    "promoted" into plugin classes, depending on plugin as selected at run
    time, for being able to benefit from enriched methods. More or less,
    it might mean something like the virtual substitution of common classes
    by corresponding plugin classes whenever they appear in the class bases
    of work schemas, and consequently virtually altering the MRO of such
    classes so plugin methods override common methods, yet common methods
    staying available for fall back, that is, if not overridden by plugins.

    I feel ready to allow some complexity to the common module, but would
    like the overall approach to be as clean and unobtrusive as possible
    everywhere else, (that is, for plugins, work schemas, and applications).
    It ought to be overall simple. So, zealots: no Zope nor Twisted! :).

    Another constraint is that the same work schema may be used at run-time
    with two different plugins, and this means that ideally, a work schema
    may not be altered (in a non-reentrant way) for a particular plugin.
    This is a lesser constraint, because it occurs only occasionally, and I
    presume that we could afford unusual stunts whenever necessary.

    Fran├žois Pinard
    =?iso-8859-1?Q?Fran=E7ois?= Pinard, Aug 20, 2005
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Perks and Sarah Mount

    MRO problems with diamond inheritance?

    John Perks and Sarah Mount, May 1, 2005, in forum: Python
    Michele Simionato
    May 3, 2005
  2. Uwe Mayer

    don't understand MRO

    Uwe Mayer, Jun 23, 2005, in forum: Python
    Martin Franklin
    Jun 24, 2005
  3. Replies:
    Michele Simionato
    Jun 27, 2006
  4. flamesrock
    Hendrik van Rooyen
    Nov 24, 2006
  5. Clarence

    MRO theory

    Clarence, Apr 11, 2007, in forum: Python
    Apr 12, 2007
  6. Pierre Yves
    Pierre Yves
    Jan 10, 2008
  7. Nitin
    Juha Nieminen
    Sep 12, 2008
  8. saurabh purnaye

    issue with the devise

    saurabh purnaye, Sep 7, 2010, in forum: Ruby
    saurabh purnaye
    Sep 7, 2010