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 Updated: 7 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 161 Version: 3 Status: Developing =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 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.