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. -- Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
