On the Module-Build mailing-list we are currently discussing
plugin architectures which will allow users to modify and extend
Module::Build's functionality. One thing that we would like to have
happen is that when the transition is made to parrot we'd like it to be
possible to script Module::Build installs and write plugins in any of
the languages supported by Parrot. In order to accomplish this we need
to make sure that the plugin architecture chosen is compatible with any
restrictions or limitations with regards to language interoperability.
For example, right now there are two prototypes for the plugin
architecture. One depends on inheritance, basically interjecting
plugins into the class hierarchy and thus giving plugin authors access
to modify and extend Module::Build's funtionality. The other does not
depend on inheritance; instead plugins must be installed into a certain
directory structure where they can be found by Module::Build, and they
must provide a compatible interface. These plugins require Module::Build
to provide an API in order to modify or extend Module::Build's behaviour.
My concern is that restrictions in language interoperability may dictate
certain design constraints, especially with regards to inheritance and
runtime modification of the inheritance hierarchy, but also with regards
to creating and manipulating objects across language boundaries. Another
concern with the contract based architecture is that it generates
methods within Module::Build at runtime that are intended to be
overridable in subclasses of Module::Build.
Is there anything in the above that stands out as potentially being
1. Module::Build is a replacement for MakeMaker.
2. Module-Build mailing-list on SourceForge:
3. Ken's inheritance based plugin architecture
Subject: [Module::Build] Plugins
Date: Thu, 1 Apr 2004 22:31:11 -0600
4. My contract based plugin architecture
Subject: [Module::Build] [RFC] [PATCH] Action plugins
Date: Sun, 30 Nov 2003 09:15:23 -0500