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.
