Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Language Interoperability
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Randy W. Sims  
View profile  
 More options Apr 4 2004, 6:48 am
Newsgroups: perl.perl6.internals
From: ml-perl-intern...@thepierianspring.org (Randy W. Sims)
Date: Sun, 04 Apr 2004 06:12:59 -0400
Local: Sun, Apr 4 2004 6:12 am
Subject: Language Interoperability

On the Module-Build[1] mailing-list[2] 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[3] 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[4] 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
problematic?

Thanks,
Randy.

1. Module::Build is a replacement for MakeMaker.
    <http://search.cpan.org/dist/Module-Build/>

2. Module-Build mailing-list on SourceForge:
    <http://tinyurl.com/37k6d>

3. Ken's inheritance based plugin architecture
    Subject: [Module::Build] Plugins
    Date: Thu, 1 Apr 2004 22:31:11 -0600
    <http://tinyurl.com/ysxmu>

4. My contract based plugin architecture
    Subject: [Module::Build] [RFC] [PATCH] Action plugins
    Date: Sun, 30 Nov 2003 09:15:23 -0500
    <http://tinyurl.com/29k4e>


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.