TITLE

Everything in Perl becomes an object.

VERSION

  Maintainer: Matt Youell <matt@siliconspike.com>
  Date: 25 Aug 2000
  Last Modified: 26 Sep 2000
  Mailing List: perl6-language-objects@perl.org
  Number: 161
  Version: 4
  Status: Frozen

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".

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.

DESCRIPTION

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.

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.

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;

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.

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.

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.

REFERENCES

RFC 137: Overview: Perl OO should not be fundamentally changed. (specifically the EXECUTIVE SUMMARY)

RFC 159: True Polymorphic Objects

www.youell.com - A C++ string class that emulates Perl's scalar manipulation tools. Bears some similarity to the Scalar object described here.

This file is part of the Perl 6 Archive