> Apologies if I've missed some earlier discussions on multimethods. The > apocolypses, exegesises and synopses don't seem to say much other than > (a) they will exist and (b) wait for apocolypse 12 for more information. > > Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the > intent is to implement method overloading similar to C++/Java or > multimethods in CLOS in a Perlish fashion. Dan's WTHI MMD[***] has also > been quite helpful. > > I'm paging through "The Art of the Metaobject Protocol" for bedtime reading > material, and multimethods are starting to give me a big case of The Fear. > > > As I understand it, the idea behind MMD is that languages like C already > do it with basic operators, since '5 + 3' generates different instructions > than '5 + 3.1' or '5.5 + 3.1' do. But weak languages like C do not allow > that mechanism to be triggered by user defined functions. The obvious > answer in type heavy languages like C++, Java or Common Lisp is to extend > that behavior for user defined functions.
That's called "overloading". It's compile-time. MMD usually refers to run-time semantics, but in Perl it refers to both. > Somehow that just feels wrong in Perl. In all of the Perl code I've > written, I've *never* felt the need to overload the + operator, or have > one of five possible implementations of new() automagically selected by > the datatypes of its arguments. Furthermore, most Perl programs I've read > or written aren't very type heavy -- there's still a lot of text slinging > and plain vanilla reference processing going on, and presumably that will > still be the case in five years' time. You must not be following Perl 6 closely enough, then. Perl 6 is a "real" programming language now, as opposed to a "scripting" language. It will still have a lot of power in text processing, and still be a powerful "quicky" language, but that's no longer its primary focus -- not to say that highly structured programming is. Some applications want strong typing, some don't. That's why typing is optional (which is still driving me nuts as to how that's going to work). > Type-based MMD as it exists elsewhere are solving a problem that does not > exist in Perl, or at least does not exist to the same extent it does in > other languages. Similarly, value-based dispatching is dirt simple in > Perl and easy to implement that it's an idiom that at least I use > constantly. And you can still do it the Perl 5 way in Perl 6. We're just taking common idioms and adding them into the language so not as much typing is required. And also adding the always-useful procedural-to-declarative transformation. > Add all that up, and MMD is a lot of pain for not a huge benefit. Not > because MMD is a necessarily bad idea, but because MMD doesn't go *far* > enough, since it's limited to type signatures. Well, type signatures are the only relevant information we have, so that's what we'll use. See below. > A better fitting solution wouldn't focus on classic MMD, but simply > "Dispatch", where type- and value-based dispatching are two of many kinds > of dispatching supported. If there's a third kind of dispatching (e.g. > a hybrid model), then the dispatching machinery would be open enough for > someone to write a new dispatcher class in Perl instead of warping the > language. Perl will easily be (is) powerful enough for someone to write a dispatcher class. Whether that will be easy to do doesn't matter, because some Damian will write a module to make it easy. What the A6 MMD's accomplish are the common case. There's one "most common" kind of dispatch that it implements. But Perl's not going to stop you from redefining the "multi" declarator, registering the routines, and using your own dispatcher. Perl 5 sure didn't :-) About the type system, considering MJD's article and some experience, I don't think it's Perl enough. It needs to be both stronger and less explicit. But that's a post for another day, when I get a proposal hashed out. > I haven't been following language syntax discussions recently, so I'll > refrain from proposing a straw man. That's all right. Personally, I correct people's syntax, but try not to let it get in the way of their ideas. Luke
