TITLE

Overview: Perl OO should not be fundamentally changed.

VERSION

  Maintainer: Damian Conway <damian@conway.org>
  Date: 21 Aug 2000
  Last Modified: 18 Sep 2000
  Mailing List: perl6-language-objects@perl.org
  Number: 137
  Version: 2
  Status: Frozen

ABSTRACT

This RFC proposes that the OO model and mechanisms present in Perl 5 not be changed significantly in Perl 6. It provides an overview of a suite of forthcoming RFC proposals that will provide the features, convenience, and safety that are missing from Perl 5, without compromising the essential flexibility of the existing Perl OO model.

EXECUTIVE SUMMARY

It ain't broken. Don't fix it.

DESCRIPTION

Perl's current OO model has a number of well-known deficiencies: lack of (easy) encapsulation, poor support for hierarchical method calls (especially constructors and destructors), limited (single) dispatch mechanism, poor compile-time checking. More fundamentally, many people find that setting up reliable OO class hierarchies requires too much low-level coding.

But these very deficiencies are also Perl's great strength, compared to other, more restrictive, OO languages. The non-prescriptive, non-proscriptive nature of Perl's OO model makes it possible to construct am enormous range of OO systems within the one language: from archetype-based classless OO (Class::Classless), to formal Design-By-Contract models (Class::Contract). Effectively, Perl's OO mechanism spans the range of metaphors from Self to Eiffel -- an astonishing achievement.

It is proposed that modules like Class::Classless, Class::Struct, and Class::Contract continue to be the preferred method of constraining and simplifying the creation of Perl classes, and that a better range of such modules (at very least, Class::Contract) be included in the standard distribution.

To deal with the existing deficiencies without losing the remarkable power, I intend to propose the following extensions to OO Perl:

• A private keyword that lexically scopes hash keys to the current package, and allows hashes to contain two or more identically named (but differently scoped) entries. This would solve the problem of encapsulation in OO Perl for the vast majority of (predominantly hash-based) class structures.
• A new special subroutine name -- SETUP -- to separate construction from initialization. SETUP methods would be automatically -- and hierarchically -- called whenever an object is created.
• Changes to the semantics of bless so that, after associating an object with a class, the class's SETUP methods are automatically called on the object. An additional trailing @ parameter for bless, to allow arguments to be passed to SETUP methods.
• Changes to the semantics of DESTROY, so that all inherited destructors are, by default, automatically called when an object is destroyed.
• Pre- and post-condition specifiers, which associate code blocks with particular subroutine/method names. These blocks would be automatically called before and after the subroutine/method of the same name, and trigger an exception on failure. For methods, pre- and post-conditions would be inherited and called hierarchically (with disjunctive short-circuiting, in the case of post-conditions).
• Class invariant specifiers, which associate code blocks with a particular package/class. These blocks would be called automatically after the the execution of subroutine/method of the same name, and trigger an exception on failure. For methods, invariants would be inherited and called hierarchically.
• Optional, configurable, multiple dispatch of methods, based upon typed parameters.
• A NEXT pseudo-class, enabling resumption of the dispatch search from within an invoked method, as well as the "rejection" of invocation (e.g. by an AUTOLOAD).
• Constraints on lexical variables such that my Dog $spot can only be assigned a value $v if $v-isa('Dog')>.
• An optional constraint (use strict 'objvars'?), making it a fatal error to store a object reference in a non-typed lexical.
• A new pragma -- delegation -- that would modify the dispatch mechanism to automatically delegate specific method calls to specified attributes of an object.

Collectively these extensions would significantly reduce the amount of code required to construct safe OO classes, whilst leaving available the existing "unconstrained" OO model where it might be needed.

There will also be one additional -- and far more radical -- proposal that does not form part of the above suite. It would greatly enhance the reusability of OO Perl software, but at the cost of existing flexibility and greater migration effort.

The proposal is:

• That in Perl 6, only hashes (and perhaps pseudohashes) may be blessed.

This would result in no loss of functionality, since any other data type that was previously blessed as an object could instead be made a single attribute of a blessed hash. However, combined with the proposed private keyword and use delegation pragma, this proposal would ensure that it was always possible to inherit from an existing class without detailed knowledge of its implementation.

NOTE ON TERMINOLOGY

Several of the above proposals refer to "hierarchical calling". This means that if a method is invoked, all methods of the same name in all base classes are also called. The order in which this occurs depends on the nature of the method: SETUPs would be called "top-down" (most-ancestral first), whereas DESTROYs, pres, and posts would be called "bottom-up" (most-immediate ancestor first).

MIGRATION ISSUES

Virtually none. That's the point. :-)

IMPLEMENTATION

See Migration issues.

REFERENCES

Conway, D., "Object Oriented Perl", Manning, 2000.

Meyer, B., "Eiffel: The Language", Prentice-Hall, 1992.

www.sun.com

RFC 8: The AUTOLOAD subroutine should be able to decline a request

RFC 28: Perl should stay Perl.

RFC 92: Extensible Meta-Object Protocol -- Method Search

RFC 95: Object Classes

RFC 126: Ensuring Perl's object-oriented future

RFC 128: Subroutines: Extend subroutine contexts to include name parameters and lazy arguments

Numerous forthcoming proposals