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>