Re: RFC 97 (v1) prototype-based method overloading

[email protected] (Ask Bjoern Hansen)
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>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.