| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
prototype-based method overloading
Maintainer: David Nicol <perl6rfc@davidnicol.com> Date: 13 Aug 2000 Last Modified: 29 Sep 2000 Mailing List: perl6-language-subs@perl.org Number: 97 Version: 2 Status: Frozen
I believe several prototyping systems have been proposed, concerned with the exact nature of the parameter lists. Since this RFC does not specify the mechanism for the declaration, beyond that it is a compatible superset of the current syntax, I believe we have compatability.
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.
$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_t $k = new frog(type=>tree);
listargs("franz","tree"); # prints "Two args..."
listargs("franz",$k); # prints "franz and ..."
listargs($k,"franz"); # throws an argsyntax error
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 foo that exactly match none of the
prototypes of defined subroutines named foo
will fall through to a 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.
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.
Perhaps the method is first looked up by name, and then further dispatch is done if needed. This would exempt methods using "relaxed perl5-ish semantics" from any additional processing overhead.
RFC 57: Subroutine prototypes and parameters
RFC 61: Interfaces for linking C objects into perlsubs
RFC 75: structures and interface definitions
camel book, 2nd ed.