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>