This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Overview: Perl OO should I<not> be fundamentally changed. =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 21 Aug 2000 Last Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 137 Version: 2 Status: Frozen =head1 ABSTRACT This RFC proposes that the OO model and mechanisms present in Perl 5 I<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. =head1 EXECUTIVE SUMMARY It ain't broken. Don't fix it. =head1 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: =over 4 =item * A C<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. =item * A new special subroutine name -- C<SETUP> -- to separate construction from initialization. C<SETUP> methods would be automatically -- and hierarchically -- called whenever an object is created. =item * Changes to the semantics of C<bless> so that, after associating an object with a class, the class's C<SETUP> methods are automatically called on the object. An additional trailing C<@> parameter for C<bless>, to allow arguments to be passed to C<SETUP> methods. =item * Changes to the semantics of DESTROY, so that all inherited destructors are, by default, automatically called when an object is destroyed. =item * 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). =item * 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. =item * Optional, configurable, multiple dispatch of methods, based upon typed parameters. =item * A C<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 C<AUTOLOAD>). =item * Constraints on lexical variables such that C<my Dog $spot> can only be assigned a value $v if C<$v->isa('Dog')>. =item * An optional constraint (C<use strict 'objvars'>?), making it a fatal error to store a object reference in a non-typed lexical. =item * A new pragma -- C<delegation> -- that would modify the dispatch mechanism to automatically delegate specific method calls to specified attributes of an object. =back 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: =over 4 =item * That in Perl 6, only hashes (and perhaps pseudohashes) may be blessed. =back 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 C<private> keyword and C<use delegation> pragma, this proposal would ensure that it was always possible to inherit from an existing class without detailed knowledge of its implementation. =head1 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 I<also> called. The order in which this occurs depends on the nature of the method: C<SETUP>s would be called "top-down" (most-ancestral first), whereas C<DESTROY>s, C<pre>s, and C<post>s would be called "bottom-up" (most-immediate ancestor first). =head1 MIGRATION ISSUES Virtually none. That's the point. :-) =head1 IMPLEMENTATION See Migration issues. =head1 REFERENCES Conway, D., "Object Oriented Perl", Manning, 2000. Meyer, B., "Eiffel: The Language", Prentice-Hall, 1992. http://www.sun.com/research/self/index.html 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
