Re: RFC 98 (v1) context-based method overloading

yOn 14 Aug 2000, Perl6 RFC Librarian wrote:

> This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
> 
> =head1 TITLE
> 
> context-based method overloading
> 
> =head1 VERSION
> 
>   Maintainer: David Nicol <[email protected]>
>   Date: 14 Aug 2000
>   Version: 1
>   Mailing List: [email protected]
>   Number: 98
> 
> =head1 ABSTRACT
> 
> The other way C++ allows you to overload a named function is
> by return type.  This document is a companion piece to
> a similarly named one about protoypes.  It replaces old Perl's
> "wantscalar" and "wantarray" kluges, which can now be deprecated,
> with a cleaner interface allowing decisions which are possible to
> make at compile time to be made then.
> 
> =head1 DESCRIPTION
> 
> Defining multiple subroutines with both the same name and the same calling
> interface that explicitly return items of differing types is now
> allowed. subject to the following:
> 
> =over
> 
> =item compile-time
> 
> the return-type expectation of all method calls meaning to take advantage
> of this feature must be clear from explicit type tags available at compile time.
> 
> =item what constitutes a context?
> 
> We are familiar with "scalar context" and "array context" from perl5 and
> previous.  Perl6 gives us user-defined contexts as well as user defined
> types or all sorts.  Any unique string can be a context, for the purposes
> of context-based method overloading, and Perl will attempt to guess a
> reasonable base class for the given "context."  Use of undeclared context
> specifiers will of course generate warnings.
> 
> =item interaction with prototype-based and traditional overloading
> 
> A traditional perlsub may be considered the simultaneous
> definition of two routines,
> C<$ sub(PROTO){body}> and
> C<@ sub(PROTO){body}>.
> 
> It is now possible to differentiate between these two explicitly.
> 
> =item guaranteed sane values
> 
> The return context is considered before considering the types of the
> arguments, and in the case of no exact match, the fallback is to a
> default method defined to work in the given context rather than to
> the default method for the name, should one exist.
> 
> =item specification incomplete
> 
> Further points to discuss and agree on include the relation of this
> mechanism to inheritance, and multiple inheritance, and the meta-alteration
> of all aspects of the mechanism.
> 
> =back
> 
> =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 are further extended to include, 
> as well as the prototype,
> the declared type of the return values, when specified,
> as part of the
> name of each method. 
> 
> =head1 REFERENCES
> 
> RFC 21: Replace C<wantarray> with a generic C<want> function
> 
> RFC 57: Subroutine prototypes and parameters
> 
> RFC 61: Interfaces for linking C objects into perlsubs
> 
> RFC 75: first class interface definitions
> 

-- 
ask bjoern hansen - <http://www.netcetera.dk/~ask/>
more than 70M impressions per day, <http://valueclick.com>