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/