Larry Wall wrote:
> Jonathan Lang wrote:
> : > Arguably, the role's might be required to declare their methods
> : > "multi" if they want to participate in this, but that's one of those
> : > things that feel like they ought to be declared by the user rather
> : > than the definer. On the other hand, maybe a role would feel that
> : > its method *must* be unique, and leaving out the "multi" is the way
> : > to do that. But I hate to get into the trap of culturally requiring
> : > every method in every role to specify "multi". It's a little too
> : > much like the C++ ubiquitous-const problem.
> :
> : What about making multi dispatches the assumed behavior, with a
> : C<unique> keyword to explicitly shut it off (for the sake of
> : optimization)? That is, replace the C<multi> keyword used to define
> : routines that participate in multiple dispatching with a C<unique>
> : keyword used to define routines that don't.
>
> Now that's...an *interesting* idea. Maybe even worth some punctuation
> right there in the name. Maybe "is unique" is written:
>
> my sub print! ([EMAIL PROTECTED]) {...}
>
> meaning: "Always call this one, dang it!"
>
> Then maybe "is default" could be
>
> my sub print? ([EMAIL PROTECTED]) {...}
>
> meaning: "Call this one in case of a tie?"
>
> The character would only be in the declaration, not in the call.
Perhaps; but I'd want the more verbose approach available as well.
> (Of course, that prevents us from actually using those characters in
> names like Ruby does, but I'm not sure that's a big loss.)
>
> But I'm getting sidetracked. The underlying question is whether "multi"
> should be the default. And that's still an interesting idea regardless
> of the syntax.
>
> Another unexplored question is how and whether to open up multiple
> dispatch to more scopes than just the first one in which you find
> the name, which is the normal Perl6 semantics. I doubt looking
> everywhere should be the default, but just as a class might call any
> or all of its roles' methods, a lexically scoped sub might want to
> call or dispatch to any set of subs of that name that are visible in
> the current scope. Naming such collections is an interesting problem.
Naming in what way? As a descriptive term for discussing them in general,
or naming individual collections for reference purposes in the code?
> Taking scope transitions into account in the distance calculation of
> multi signatures could be even more interesting. If you define your
> own multi foo, and there's a global multi foo, how far away is that?
> Is it worth a level of inheritance in one of the arguments? Is it
> worth more? Less? Is it worth anything, if you've included both
> in your set of possible multis to begin with?
Why not do it the same way that namespace scoping collisions are resolved:
the local scope trumps the caller's scope. Rinse, lather, repeat.
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
