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.
