[% setvar title Overview: Perl OO should I be fundamentally changed. %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/


Overview: Perl OO should not be fundamentally changed.


  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


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.


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


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:

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:

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.


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


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


See Migration issues.


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

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


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