Re: RFC 159 (v1) True Polymorphic Objects

2000-09-06 Thread Bennett Todd

2000-08-28-18:47:06 Tom Christiansen:
 It strikes me as a bit reminiscent of (one reason) why Larry
 didn't make a+b work on strings, since then while with numbers,
 a+b and b+a would be the same, with strings they would not be, and
 we have these rather deeply held convictions about such matters.

perl's internals may have distinct strings and numbers, but from the
programmer's viewpoint that distinction is nowhere near so clear; by
using distinct operators for string ops and arithmetic ops, Perl
automatically converts as needed, and so prevents the programmer
from seeing distinct strings and numbers, they're all just scalars
and do the right thing.

The a+b != b+a with + as string contatenation may be a happy
additional justification, but I think the underlying principle is
much more basic, and I don't think we can lose it without a really
dramatic change being imposed on the programmer's view of the Perl
language.

-Bennett

 PGP signature


Re: RFC 159 (v1) True Polymorphic Objects

2000-08-25 Thread Nathan Wiger

Oh geez! I'm sorry, I forgot to mention David Nicol in the REFERENCES,
who also gave great input, especially on the BOOLEAN accessor. Thanks
David! I swear I'll put you in v2. :-{

-Nate

Perl6 RFC Librarian wrote:
 
 This and other RFCs are available on the web at
   http://dev.perl.org/rfc/
 
 =head1 TITLE
 
 True Polymorphic Objects
 
 =head1 VERSION
 
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 25 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 159
Status: Developing
 
 =head1 ABSTRACT
 
 Currently, using objects in numeric and string contexts is not very
 useful or easy:
 
$r = new CGI;
$z = $r + $x;  # oops
print "$r\n";  # double-oops
 
 You can use facilities such as Ctie to help fix this issue, but Ctie
 is limited and slow. You can also overload operators, but this is not
 flexible enough for many applications since it applies to a package (and
 not individual objects).
 
 This RFC proposes the concept of Btrue polymorphic objects, which are
 objects that can morph into numbers, strings, booleans, and much more
 on-demand. As such, objects can be freely passed around and manipulated
 without having to care what they contain (or even that they're objects).
 
 =head1 DESCRIPTION
 
 =head1 Overview
 
 The top-level syntax remains the same. As such, transition to Perl 6 is
 very smooth for most people, and in fact most users don't have to care
 about any of the following details. To them, this script will "just
 work":
 
$y = Math-data(7);
$x = 3;
$name = getname("Nate");
if ( $x  5 ) {
   $y += $x;
   if ( ! $name ) {
  $name = "The math whiz";
   }
}
print "$name got $y";   # "Nate got 10"
 
 However, under the hood things might work drastically differently. In
 fact, C$y and C$name might well be polymorphic objects:
 
$y = Math-data(7);  # $y-CREATE, $y-STORE(7)
$x = 3;  # $x = 3
$name = getname("Nate"); # $name-CREATE, $name-STORE("Nate")
if ( $x  5 ) {  # $x  5
   $y += $x; # $y-STORE($y-NUMBER-PLUS($x))
   if ( ! $name ) {  # $name || $name-BOOLEAN
 $name = "The math whiz";# $name-STORE("...")
   }
}
print "$name got $y";# $name-STRING , $y-STRING
 
 Here, C$y and C$name are objects, but we don't have to care. These
 objects have a key property: Icontext sensitivity. They have numerous
 different methods which are each called only in specific instances. So,
 being called in a numeric context calls CNUMBER, whereas being called
 in a string context would call CSTRING.
 
 Plus, operators are overloadable as well. This means that we might
 decide to overload C+ to become a Java-like concatenation operator on
 our objects:
 
$string = $name + "Wiger";   # $name-STRING-PLUS("Wiger")
 
 Yuck. :-) But it can be done, and that's pretty cool.
 
 =head2 Polymorphic Methods
 
 The following are the proposed methods for Perl 6 objects.  Note that
 these methods are completely Ioptional for a class to define. If they
 are not defined, the object would retain its current behavior. The hooks
 are in Perl if you want them, otherwise they don't get in the way.
 
 Note that CSTRING, CNUMBER, and CBOOLEAN are specialized forms of
 CFETCH. If you define them, they are used instead of CFETCH in the
 given context, otherwise CFETCH is used. Also note that the operators,
 when overloaded, behave similarly to 'use overload', but on an
 Iobject-by-object basis, rather than package-wide.
 
Data Conversion and Access
-
STRING   Called in a string context
NUMBER   Called in a numeric context
BOOLEAN  Called in a boolean context
 
Operator Overloading
-
PLUS Called in + context
MINUSCalled in - context
TIMESCalled in * context
DIVIDED  Called in / context
MODULUS  Called in % context
 
NUMCMP   Called in = context
NUMEQCalled in == context
NUMNECalled in != context
NUMLTCalled in   context
NUMGTCalled in   context
NUMLECalled in = context
NUMGECalled in = context
 
STRCMP   Called in cmp context
STREQCalled in eq context
STRNECalled in ne context
STRLTCalled in lt context
STRGTCalled in gt context
STRLECalled in le context
STRGECalled in ge context
 
BITAND   Called in  context
BITORCalled in | context
BITXOR   Called in ^ context
BITNOT   Called in ~ context
 
Assignment and Existence
-
CREATE   Called in object creation
STORECalled