Re: RFC 97 (v1) prototype-based method overloading
[email protected] (Ask Bjoern Hansen) Mon, 14 Aug 2000 11:50:52 -0700 (PDT)
| Newsgroups | perl.perl6.language.subs,perl.perl6.announce |
|---|---|
| Message-ID | <Pine.LNX.4.21.0008141150490.22338-100000@impatience.valueclick.com> |
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 C<foo> that exactly match none of the > prototypes of defined subroutines named C<foo> > will fall through to a C<foo> 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>