Hi,

The following item is by the wizard who showed that it was possible to
do good, serious OOP in Perl5 after all--although it still is an
enormous chore and it still takes/wastes a lot of brainpower. His
comments on the problems of Perl5 OOP are probably among the most
credible ones that could be incorporated in the existing Ruby to Perl
comparisons. 

Given the objectives and constraints of Perl6 plus the existing user
community of Perl5, my guess at present is that the following proposal
will likely prevail for Perl6. And even though this would be a major
improvement for Perl, Ruby OO would still look great in comparison.


((On a side note, does it make (any sort of (good)) sense (from a human
usability perspective) to say that (very loosely speaking) "Ruby is to
Perl what Smalltalk is to Lisp"?))


Damian Conway (author of Object Oriented Perl):
=================================================================

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 <damian / conway.org>
  Date: 21 August 2000
  Version: 1
  Mailing List: perl6-language-objects / perl.org
  Number: 137

=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<INIT> -- to separate construction
from initialization. C<INIT> 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<INIT> methods are automatically
called on the object. An additional trailing C<@> parameter for
C<bless>, to allow arguments to be passed to C<INIT> 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<INIT>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 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
=================================================================

-- 
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)