This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
OO Integration/Migration Path
=head1 VERSION
Maintainer: Matt Youell <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Updated: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 161
=head1 ABSTRACT
Allow Perl 6 to benefit more directly from object orientation and object
syntax while leaving a bridge to Perl 5.
=head1 DESCRIPTION
=head2 Overview
Everything in Perl becomes an object, using existing object-syntax. Out of
plain sight, there would be essentially three base classes: Scalar, List,
and Hash. Stricter typing would be imposed (as needed) at the object level
without the need for new keywords. The Scalar base class would know about a
fixed number of types, perhaps: ref, int, long, bool, and string. Other
types could be added by subclassing Scalar.
=head2 Examples
For example, rather than:
my int $intVal = 0;
you would say:
my $intVal = 0;
$intVal->asInt;
Or possibly even:
my $invVal->asInt = 0;
for simplicity.
Unary operations could also be made the Scalar object's responsibility in
the same style:
$record->chop;
Or even possibly controversial things like:
$value->undef;
Finally, some of the more domain-specific features being requested of the
language could be added in a subclass of Scalar. For example,
transaction-friendly variables might be subclassed:
use Transactions;
my $firstName = "Bob";
# ... (transaction happens) ...
$firstName->commit; # or ->rollback
(Of course, transaction vars might be in their own, independent, class ala
TMTOWTDI.)
=head2 Wrap-up
What this gives us is a means for adding functionality while leaving the
basic language structure alone. This way we don't interfere with
improvements happening elsewhere in the language, and we leave a clean
migration path for Perl 5.
Also, by allowing lower-level extensibility, many language-feature requests
may become moot.
=head1 IMPLEMENTATION
Most of the tools required to implement this system are already there.
- Scalar values already have Perl Doing The Right Thing for type conversion.
Providing the user with methods to activate type conversion explicitly
shouldn't be a major chore. In fact it could lighten Perl's load in many
cases by eliminating guess work about when to convert.
- The existing bless-based object system provides most (if not all) of the
tools needed to implement this system. For example, if I create my own
scalar class in Perl 5, I can say:
$myScalar->chop;
or
chop $myScalar;
and Perl automagically knows what I mean, barring namespace considerations.
It could work the same way in Perl 6. That would mean that older code could
very easily get along with newer code, because all of the same operators
would still be there and they would still work as expected.
=head1 MISC
This approach may also allow for better organization of Perl's internals,
specifically if the plan is to move toward a Topaz-style (C++)
implementation. Also, by organizing responsibilities into explicit classes,
the "mind-reading" load might lighten for the Perl interpreter. At least it
looks that way from outside.
=head1 REFERENCES
RFC 4: "Type Inference"
RFC 35: "A proposed internal base format for perl variables"
RFC 49: "Objects should have builtin stringifying STRING method"
RFC 89: "Controllable Data Typing"
RFC 137: "Overview: Perl OO should I<not> be fundamentally changed."
(specifically the EXECUTIVE SUMMARY)
http://www.perl.com/pub/1999/09/topaz.html : "Topaz: Perl for the 22nd
Century" - Chip Salzenberg
http://www.youell.com/matt/perlstring/ - A C++ string class that emulates
Perl's scalar manipulation tools. Bears some similarity to the Scalar object
described here.
