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
[Scheme 2: loadable-library style plugins]
>Is there anything in the above that stands out as potentially being
Well, there are a lot of languages that really dislike having their
inheritance hierarchy change at runtime, so the first scheme might be
rather problematic. (I also think it's likely a really bad misuse of
inheritance, but that's a matter of opinion) Scheme 2 is also much
safer from a pure security standpoint. Personally it's what I'd
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Design-wise, that pretty well sums up my opinion also. Unfortunately, I
think I'm outnumbered. :( I think I was rather hoping for a technical
knockout with a language iteroperability argument, but...
Can you really have a perl class inherit from a ruby class which
inherits from a python class which inherits from a perl class, etc, etc,
BTW, Is there going to be a seperate mailing-list for module authors
making the transition to Parrot and Perl 6? I'm not sure if topics like
this are appropriate for this list.
How 'bout a "No way in hell it'll ever make it in as parrot's
standard module building system if you do it"? Not *exactly*
Also, the plugin system should *not* require objects in its
interface, nor should it in the interface you present to the world if
you want it to be standard. If you do it'll mean that non-object
languages aren't able to extend it or use it and that ought not
I don't care if it's OO internally, but the external and plugin
interfaces should be purely procedural.
>Can you really have a perl class inherit from a ruby class which
>inherits from a python class which inherits from a perl class, etc,
>etc, ad nauseam?
>BTW, Is there going to be a seperate mailing-list for module authors
>making the transition to Parrot and Perl 6? I'm not sure if topics
>like this are appropriate for this list.
Eventually, yeah. There'll also be a separate list for compiler writers.
This design decision applies to most class-based object oriented languages,
but not for the delegation-based languages (the latter are sometimes called
propotype-based instead). Self, the archetypical delegation-based langugage,
permits objects being used as part of an inheritance tree to be modified at
I guess this matters little as far as the internals go, but it would be a
shame to cut out a language as classic as Self, especially as its VM was the
first to demonstrate astonishing efficiency.
Jon Shapcott <ed...@xibalba.demon.co.uk>
"This is the Space Age, and we are Here To Go" - Wlliam S. Burroughs