This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects should have builtin string SCALAR method
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 06 Aug 2000
Version: 1
Status: developing
Mailing List: [EMAIL PROTECTED]
Number: 49
=head1 ABSTRACT
Currently, $ single-whatzitz types in Perl can hold several different
things. One of the things that these are commonly used to hold are
objects, such as:
$q = new CGI;
$r = Apache->request;
Unfortunately, there is no easy way to tell these are actually objects
without lots of annoying ref checks throughout your code. So if you say:
print "$q";
This prints out something like this:
CGI=HASH(0x80ba4e8)
Which isn't very useful. This RFC attempts to fix this.
=head1 DESCRIPTION
Currently, there is no way to easily distinguish between these two
syntaxes:
$scalar = date; # scalar ctime date, same as localtime()
$object = date; # date object with accessor functions
As such, there is no easy way to have the C<date()> function return both
- it must decide what to return within the general scalar context.
Damian's excellent RFC 21 on C<want()> addresses several specific cases,
several have suggested alternate syntaxes, such as:
my Date $object = date; # return object of class 'Date'
my tm $object = date; # return object of struct 'tm'
However, this doesn't solve the problem, since printing out either of
these in a scalar context still results in "garbage".
I suggest that objects provide a default method called C<SCALAR> that
determines what they produce in a scalar context. When stringified, an
object would automatically call its C<SCALAR> function and return the
correct value. For example, RFC 48 describes a new C<date()> interface.
It could produce a date object always:
$date = date;
However, when you went to do anything with it in a stringifying context,
it would call the appropriate method:
print "$date"; # calls $date->SCALAR, which in this case would
# print out a ctime formatted date string
This gives us several other really neat side effects. First, we can now
return a list of objects and have them act the same as a "regular old
list":
(@objects) = Class->new;
Since, in a stringifying context, each of these objects would call their
C<SCALAR> methods:
print "@objects"; # calls $objects[0]->SCALAR, $objects[1]->SCALAR,
# and so on for the whole array, thus making it
# look like a plain old list
As such, we no longer have to distinguish between objects and "true"
scalars. Objects are automatically converted when appropriate.
=head1 IMPLEMENTATION
All core objects should be modified to include a C<SCALAR> function.
This function may just be a typeglob pointing to another function, or it
may be an actual separate function.
A line must be drawn for what counts as a "scalar" or "stringifying"
context. This shouldn't be a difficult line to draw, but it must be made
clear.
I chose C<SCALAR> as the name of the function because it seemed the most
obvious. It also leaves us room to add a C<LIST>, C<HASH>, and so forth
(although I don't see how or why these would be added). I thought of
several other alternatives, including C<DEFAULT>, C<TOSCALAR>,
C<STRING>, and C<TOSTRING>. One of these (or something else) might be
more appropriate.
=head1 REFERENCES
RFC 21: Replace C<wantarray> with a generic C<want> function
A couple other people (sorry, can't find the emails). This is
an IOU for "your name here" in version 2. ;-)
