Re: RFC 159 (v1) True Polymorphic Objects

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 C<tie> to help fix this issue, but C<tie>
> 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 B<true 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: I<context sensitivity>. They have numerous
> different methods which are each called only in specific instances. So,
> being called in a numeric context calls C<NUMBER>, whereas being called
> in a string context would call C<STRING>.
> 
> 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 I<optional> 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 C<STRING>, C<NUMBER>, and C<BOOLEAN> are specialized forms of
> C<FETCH>. If you define them, they are used instead of C<FETCH> in the
> given context, otherwise C<FETCH> is used. Also note that the operators,
> when overloaded, behave similarly to 'use overload', but on an
> I<object-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
>    MINUS            Called in - context
>    TIMES            Called in * context
>    DIVIDED          Called in / context
>    MODULUS          Called in % context
> 
>    NUMCMP           Called in <=> context
>    NUMEQ            Called in == context
>    NUMNE            Called in != context
>    NUMLT            Called in <  context
>    NUMGT            Called in >  context
>    NUMLE            Called in <= context
>    NUMGE            Called in >= context
> 
>    STRCMP           Called in cmp context
>    STREQ            Called in eq context
>    STRNE            Called in ne context
>    STRLT            Called in lt context
>    STRGT            Called in gt context
>    STRLE            Called in le context
>    STRGE            Called in ge context
> 
>    BITAND           Called in & context
>    BITOR            Called in | context
>    BITXOR           Called in ^ context
>    BITNOT           Called in ~ context
> 
>    Assignment and Existence
>    -------------------------------------------------
>    CREATE           Called in object creation
>    STORE            Called in an lvalue = context
>    FETCH            Called in an rvalue = context
>    READLINE         Called in a <> context
>    PRINT            Called in a print context
>    PRINTF           Called in a printf context
>    DESTROY          Called in object destruction
> 
> There are undoubtedly other functions that should be added. However, the
> purpose of this RFC is to propose an idea and a basic interface. [1]
> 
> Others proposed an alternative set of names for these functions, such as
> "OP_*" and "OP_-". However, I strongly disagree with these names. First,
> they're not English words or phrases, so are bad for humans. Second,
> they're not legal \w+ names, which is something we should not circumvent
> with special cases. Third, they're not consistent with already-existing
> Perl functions like C<FETCH> and C<STORE>. Finally, there is actually a
> good amount of ambiguity. For example, does "OP_*" refer to a unary or
> binary * context? With the word "TIMES" there is no such ambiguity.
> 
> Now, whether the word "TIMES" is better than "MULTIPLY" is open for
> debate. I was trying to get the English verb context right:
> 
>    $x * $y     # $x->NUMBER->TIMES($y)
> 
> Which I think makes the function names intuitive and easy to remember. I
> left out any potential _'s because these are a pain to type, and no
> other Perl builtins have them.
> 
> Also, note the C<CREATE> method is actually quite useful. This allows
> you to have multiple methods for creating objects, and C<CREATE> is
> always called first (so you can do your basic blessing in there). This
> is just like a C<BEGIN> for objects. Again, you don't have to use it,
> but the hooks are there.
> 
> =head1 IMPLEMENTATION
> 
> Let's not get ahead of ourselves...yet...
> 
> =head1 MIGRATION
> 
> This introduces new functionality, however p52p6 would have to catch any
> subs defined with the names listed above and warn the user that this sub
> name is now reserved for Perl.
> 
> =head1 NOTES
> 
> [1] Abiding by the KISS property (Keep It Simple, Stupid)
> 
> =head1 REFERENCES
> 
> RFC 49: Objects should have builtin stringifying STRING method
> 
> RFC 73: All Perl core functions should return objects
> 
> Thanks to brian d foy and Damian Conway for their input
> 
> Thanks to Uri Guttman for suggesting CREATE on a different topic