Re: RFC 97 (v1) prototype-based method overloading
Damian Conway [EMAIL PROTECTED] writes: Why would anyone want to select a different method based upon the arguments. Have you seen Class::Multimethods? This kind of despatch can be very useful. Of course, the existence of Class::Multimethods proves that it can be done already so there may be no need to put it in the core. There's a definite need to put it in the core. Class::Multimethods is too slow. I'll be proposing this form of multiple dispatch and overloading in a forthcoming RFC. Oh, I don't doubt it. My point was that if it *doesn't* get in then it won't be the end of the world (and hopefully there will be improvements in basic dispatch speed that will mean that the multiple hit on the dispatch system entailed by Class::Multimethods won't be quite so gruesome). I'm in the camp that would rather see it in core though. -- Piers
Re: RFC 97 (v1) prototype-based method overloading
Chaim Frenkel wrote: "PC" == Piers Cawley [EMAIL PROTECTED] writes: PC Chaim Frenkel [EMAIL PROTECTED] writes: Why would anyone want to select a different method based upon the arguments. PC Have you seen Class::Multimethods? This kind of despatch can be very PC useful. Of course, the existence of Class::Multimethods proves that it PC can be done already so there may be no need to put it in the core. You answered the HOW, not the WHY. The question for the audience is WHY, I would want to do this. (As a counterpoint. Dr. Myers argues very strongly against this.) There are a couple of reasons for overloading. simple arithmetic operations, you can use plus(int, int), plus(float, float). another approach is to use genericity like in eiffel, and the templates in C++, which is probably better in the sense that you only have one function ie plus(type, type). peter -- "Speak loudly, and carry a beagle!" -- Charles Schulz
Re: RFC 97 (v1) prototype-based method overloading
Why would anyone want to select a different method based upon the arguments. Have you seen Class::Multimethods? This kind of despatch can be very useful. Of course, the existence of Class::Multimethods proves that it can be done already so there may be no need to put it in the core. There's a definite need to put it in the core. Class::Multimethods is too slow. I'll be proposing this form of multiple dispatch and overloading in a forthcoming RFC. Damian
Re: RFC 97 (v1) prototype-based method overloading
On 14 Aug 2000, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE prototype-based method overloading =head1 VERSION Maintainer: David Nicol [EMAIL PROTECTED] Date: 14 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 97 =head1 ABSTRACT When I read the chapter on OO in the second edition camel book I was saddened that C++ style method overloading was not explicitly described. Ever hopeful, I wrote some quick code that I hoped would do what I meant and discovered that it didn't. This document is an attempt to remedy the situation. =head1 SUMMARY $frog_t = qs(frog); sub listargs($){ print "One arg, $_[0]"} sub listargs($$){ print "Two args, $_[0] and $[1]"} sub listargs($$frog_t){ print "$_[0] and a frog $[1]"} sub listargs { throw argsyntax, "odd arguments to listargs" } my frog $k = new frog(type=tree); listargs("franz","tree"); # prints "Two args..." listargs("franz",$k); # prints "franz and ..." listargs($k,"franz"); # throws an argsyntax error =head1 DESCRIPTION It it now possible to define two subroutines with the same name but different interfaces without error. Perl will puzzle out which one to call in a given situation based on lexical information available in the program text. Defining two subroutines with both the same name and the same calling interface is undefined and may be an error. This may change. No coercion protocol is defined at this time. This document will be updated as a protocol for coercing function calls with arguments that don't explicitly match is developed, such as having a method name (which is now distinct from a method, but still a strong grouping characteristic) have a "coercion" method associated with it which would indicate what to do if no prototypes matched. For now, for the greatest ease for implementors, calls to method Cfoo that exactly match none of the prototypes of defined subroutines named Cfoo will fall through to a Cfoo with no prototype, should one exist. Programmers using this feature are advised to include a full coercion system into their unprototyped methods, when writing in a strongly typed environment. =head1 IMPLEMENTATION At compile time, the keys in the big hash (be it global or per-package or per-class) that holds the mapping from the names of the classes to their coderefs is extended to include the prototype as part of the name of each method. The nature of this extension is beyond the scope of this document. =head1 REFERENCES RFC 57: Subroutine prototypes and parameters RFC 61: Interfaces for linking C objects into perlsubs RFC 75: first class interface definitions Programming Perl, 2ed -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
Re: RFC 97 (v1) prototype-based method overloading
"ABH" == Ask Bjoern Hansen [EMAIL PROTECTED] writes: =head1 ABSTRACT When I read the chapter on OO in the second edition camel book I was saddened that C++ style method overloading was not explicitly described. Ever hopeful, I wrote some quick code that I hoped would do what I meant and discovered that it didn't. This document is an attempt to remedy the situation. =head1 SUMMARY $frog_t = qs(frog); sub listargs($){ print "One arg, $_[0]"} sub listargs($$){ print "Two args, $_[0] and $[1]"} sub listargs($$frog_t){ print "$_[0] and a frog $[1]"} sub listargs { throw argsyntax, "odd arguments to listargs" } Please do not do this. It is a mess. Action at a distance. There are otherways to solve the same problem. Why would anyone want to select a different method based upon the arguments. The calling routine can easily dispatch differently. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183