This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Everything in Perl becomes an object.
=head1 VERSION
Maintainer: Matt Youell <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Modified: 26 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 161
Version: 4
Status: Frozen
=head1 ABSTRACT
Everything in Perl becomes an object, out of sight, but within easy reach.
Perl stays Perlish. Syntax remains fundamentally the same; Perl 5 code
migrates well.
Previous versions of this RFC were entitled "OO Integration/Migration Path".
=head1 NOTES ON FREEZE
Not an awful lot was said once this RFC was condensed down to "Everything
becomes an object". I believe some implementation and conceptual hurdles
exist which have discouraged more serious discussion. At the suggestion of
others I've opted to freeze rather than withdraw.
=head1 DESCRIPTION
=head2 Goals
1. Provide a more complete mechanism for extending the language.
2. Organize responsibilities closer to the corresponding data structures.
3. Maintain a compatibility bridge to Perl 5.
=head2 Proposal
Everything in Perl becomes an object, using (mostly) existing object-syntax.
The built-in types $scalar, @list, and %hash become the extensible base
classes Scalar, List, and Hash. New built-in data types (such as int, bool,
string, etc.) are derived from Scalar. Regular "vanilla" $scalars don't go
away, they are simply considered to be instances of Scalar. And like any
$scalar, they still Do The Right Thing.
=head2 Syntax
"my Dog $spot" works under this model.
Where a class is not provided, a default is deduced from context ($, @, %).
For example:
my $foo = "foo";
is equivalent to:
my Scalar $foo = new Scalar("foo"); # (Or similar. This syntax is
currently in discussion.)
Methods would be called as they are for any object:
$noun->verb();
or, indirectly:
verb $noun;
=head2 Extensibility
By allowing Perl's built-in types to be extended, programmers can retain
Perl's simple syntax while better fitting their particular problem domain.
All without polluting the core language.
For example, there has been discussion of adding transaction support to
Perl. Rather than adding such support into the language directly, it could
be added as a subclass of Scalar. This might work like so:
use Transactions::Scalar; # This replaces the default scalar with a derived
class. A detail needing exploration.
my $firstName = "Bob"; # AKA: my Transactions::Scalar $firstName = new
Transactions::Scalar("Bob");
# ... (transaction happens) ...
commit $firstName; # or rollback $firstName
Or, say that you wanted to override built-in behavior. Perhaps you want
'ord' to return numeric EBCDIC values. You can create your own 'ord' routine
in your derived class and have it do that very thing.
=head2 Conclusion
This approach provides a means for adding functionality while leaving the
basic language structure alone. It doesn't interfere with improvements
happening elsewhere in the language, and it leaves a clean migration path
for Perl 5 code.
=head1 IMPLEMENTATION
This RFC tries to present a user-interface view of how this feature would
work. Other RFCs cover the specific nuts & bolts approaches that are
possible.
=head1 REFERENCES
RFC 137: Overview: Perl OO should I<not> be fundamentally changed.
(specifically the EXECUTIVE SUMMARY)
RFC 159: True Polymorphic Objects
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.
