Re: MMD as an object.

[Rod Adams]

Leopold Toetsch wrote:
Rod Adams <[EMAIL PROTECTED]> wrote:
 

It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short name.
   

Discussion seems to have went off into esoteric cases of locally
overriden dispatcher policies and what not.
 

I don't think it's as esoteric as you might think. Consider:
   package Foo;
   use MMD::Random;
   our &bar is MMD::Random is export(DEFAULT);
   multi sub bar ($x) {...};
   multi sub bar ($x) {...};
   multi sub bar ($x) {...};
 
   ==========

   use Foo;
  
   multi sub bar ($x) {...};

Note that they all have the same signature. The Manhattan policy would 
complain about this, since it's looking for the closest parameter match. 
The Random policy does not care. It's going to randomly pick any member 
method for each call.

So what we then fall into is the problem of which policy is in effect 
for a given multi can affect what's in scope at a given point. If the 
later file included:

   sub baz {
     my multi sub bar ($x) {...};
     bar(5);
   }
A Manhattan policy would have the local bar mask the package bar with 
the same signature. A Random policy would temporarily add it into the mix.

Since the main goal of treating multis as an object was to be able to 
override the dispatch policy, I think how a user defined policy 
interacts with different localities is very much on topic.

What I'd like to know is more basic things:
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
 

As for whether such a thing is visible at the Perl level, I think that 
depends on if we allow user defined dispatch policies or not. If not, 
it's just an introspection tool that could be addressed in other ways.

Even without custom policies, p6c may decide to go the MultiSub object 
route at the compiler level. But I can't speak to that, nor on the 
Compiler <-> Parrot interaction.

What about multi subs? They can be defined everywhere. Given:
 multi sub *foo(A $a, B $b) {...}
Is this something like:
 %globals{"foo"}  -->  MultiSub{"foo_A_B" => Sub, ...}
What about a not so global multi:
 multi sub foo(A $a, B $b) {...}
 

This can be seen as questioning how to keep track of what multi's are in 
scope at any given point in time, because you must dispatch amongst all 
the multi's visible, regardless of the differing scope.  Method dispatch 
has a similar issue with hunting down all the C< isa >s for possible 
method's to include in dispatch. So far, I think this issue has been 
politely ignored as p6c's problem, not p6l's.

However if you have multi's from a mix of different sources and scopes, 
all with the same short name, which policy decides how to dispatch 
amongst them at a given calling locality is very much at issue, and is 
roughly where we are in the discussion.

Thanks for clarifying,
 

Sorry I couldn't clarify more.
-- Rod Adams