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

2000-08-15 Thread John Porter

David Nicol [EMAIL PROTECTED]:
 
 The other way C++ allows you to overload a named function is
 by return type.  

This is explicitly incorrect.  The return type is not used in the
resolution of an overloaded function.
That's not to say that it wouldn't be nice to have in perl...

-- 
John Porter




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

2000-08-14 Thread Ask Bjoern Hansen

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 Cwantarray with a generic Cwant 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




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

2000-08-14 Thread David L. Nicol




It will run faster, because it doesn't have to evaluate
the want().  (97,98) doesn't invalidate the current way of doing
things, it just gives a new way. And in syntax that is currently
erroneous.



Nathan Wiger wrote:
 
  And what will aSub decide is it's context?
 
  @foo = (1, 2, 3, aSub)
 
  If I have to write scalar(aSub) then I see no point in this RFC.

What is it now?  is 
$ perl -le 'sub A() {wantarray?"array":"scalar"}; @foo = (1,2,3,A); print @foo'
123array

That would be array context.


  And why shouldn't the caller decide? What is the gain in having perl
  do the dirty work.
 
 I agree. I don't see any reason to have to define 2 subs:
 
@ sub mysub {
# whole bunch of stuff happens
return @array;
}
 
$ sub mysub {
# same stuff that happens above happens here too
return $scalar;
}
 
 Instead of just one:
 
sub mysub {
   # whole bunch of stuff happens
   if ( want 'ARRAY' ) {
  return @array;
   } else {
  return $scalar;
   }
}
 
 This doesn't make any sense to me, I don't see any win here. Not being
 mean, just being honest.
 
 -Nate

-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq