On Sat, Dec 20, 2003 at 12:41:10PM -0800, Jonathan Lang wrote:
: So what happens if more than one of the candidates is tagged as the
: default? The same thing as if none of them was? This could happen if
: both Predator and Pet have declared their 'feed' methods as the default.
Could blow up, or look for a more generic default that isn't in a tie. The latter seems more fail-soft, since something else of the same name is likelier to know what to do than some random exception handler in who-knows-what dynamic context.
It's straightforward enough to pitch an exception at sub definition time. That'll be a compile time error generally, which is likely fine, or an eval/do/require runtime error, which is also fine as anyone doing runtime code loading should be ready to catch compile-class errors. Installing new subs symbolically into symbol tables might be a bit more problematic, but mostly syntactically so it's not my 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.
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.
And, IMAO, a very, *very* bad one. I dunno about you, but when I install a sub into a symbol table I fully expect it to be the only one of that name, and if there's an existing sub of that name I expect it to be replaced, not supplemented. (Or have a warning and/or error pitched, that's fine too)
This also makes language interoperability somewhat tricky, as it is *not* the default for any other language in our class, including perl 5. That means either we change the default behaviour of perl 5 (which strikes me as bad) or we retain the base default behavior of each language in which case you end up with subs that may or may not be multi depending on the order of inclusion of modules. (if you include two modules that define the same sub in the same namespace, one with multi-by-default and one without)
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
I can do lexically-scoped multi-method dispatch tables, the same way we're going to do lexically-scoped method caches, but I'm not sure it's a wise idea. (Well... I'm pretty sure it's an unwise one, but I'm unsure of how correct that is)
Could we just leave it as global multimethod subs and methods, and package-local multimethod subs and methods for now? We can always bring in the more insane^Wexpansive version later, in perl 6.2 or something, once we see how things are going and how people are dealing with it.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
