Language Interoperability

[Randy W. Sims]

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>

[Dan Sugalski]

At 6:12 AM -0400 4/4/04, Randy W. Sims wrote:
[Scheme 1: hierarchy munging]

[Scheme 2: loadable-library style plugins]

>Is there anything in the above that stands out as potentially being
>problematic?

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
prefer.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Randy W. Sims]

On 4/6/2004 11:06 AM, Dan Sugalski wrote:
> At 6:12 AM -0400 4/4/04, Randy W. Sims wrote:
> [Scheme 1: hierarchy munging]
>
> [Scheme 2: loadable-library style plugins]
>
>> Is there anything in the above that stands out as potentially being
>> problematic?
>
>
> 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 prefer.

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,
ad nauseam?

Thanks,
Randy.

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.

[Dan Sugalski]

At 6:04 PM -0400 4/6/04, Randy W. Sims wrote:
>On 4/6/2004 11:06 AM, Dan Sugalski wrote:
>>At 6:12 AM -0400 4/4/04, Randy W. Sims wrote:
>>[Scheme 1: hierarchy munging]
>>
>>[Scheme 2: loadable-library style plugins]
>>
>>>Is there anything in the above that stands out as potentially
>>>being problematic?
>>
>>
>>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 prefer.
>
>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...

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*
technical, but...

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
happen.

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?

Yes.

>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.

[Jon Shapcott]

On Tue, Apr 06, 2004 at 06:04:56PM -0400, Randy W. Sims wrote:
> On 4/6/2004 11:06 AM, Dan Sugalski wrote:
> >At 6:12 AM -0400 4/4/04, Randy W. Sims wrote:
> >[Scheme 1: hierarchy munging]
> >
> >[Scheme 2: loadable-library style plugins]
> >
> >>Is there anything in the above that stands out as potentially being
> >>problematic?
> >
> >
> >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 prefer.
>
> 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...

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
runtime.

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