Please discuss this RFC on the -objects sublist. Thanks. Matt, you should probably update the Mailist List to perl6-language-objects for v2. -Nate Perl6 RFC Librarian wrote: > > 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 > Mailing List: [EMAIL PROTECTED] > Version: 1 > 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 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.
