[Author’s note: If you’ve read Curtis Poe’s most recent blog post, what follows is going
to seem eerily familiar. This post uses the same concepts, arguments, and code examples as his, and
reaches exactly the same conclusions. That’s because both posts originate from a long
and wide-ranging email discussion between Curtis and myself, as I’ve been privately
consulting with him over the past few months on the design of Corinna.
When I read Curtis’s post I almost decided to bin this one, as he managed to cover everything
necessary in his usual succinct, eloquent, and engaging style. But he has encouraged me to post
my version of this discussion too, as it provides a little more detail on some of the issues
we’re addressing, and on the design rationale for the changes we are jointly proposing.
Personally, I always relish the opportunity to read two versions of exactly the same story by
two very different authors, or to watch two directors’ very different takes on the same
screenplay. In fact, that’s what initially attracted me away from SmallTalk/C++/Eiffel
and into Perl: I read Larry’s version of “Object Orientation”, and found it much more
entertaining, and also more enlightening than the other earlier interpretations.
So here’s the “Conway cut” of our joint proposal.
Of course, if you’re short on time, you should just go and read
Curtis’s original version of this story.
But if you’d like some extra insights into the syntactic design of Corinna (and of Perl itself!),
and perhaps a slightly more detailed and stereoscopic view of the issues we’re addressing...read on!]
The Corinna project is fundamentally about providing
a declarative mechanism for building OO code in Perl,
as opposed to Perl’s current fundamentally emergent approach.
So let’s look at the way we declare things in Perl.
Overwhelmingly, declarations (of variables, subroutines, packages, and formats)
are made using the following syntax:
<keyword> <identifier> <modifiers>? <setup>?
For example:
<keyword> <identifier> <modifiers>? <setup>?
my $lexvar :shared
our $packvar :Tracked = 0
state $statevar :Readonly = 1
sub action :lvalue () {...}
package Namespace v1.2.3 {...}
format Report = ... .
Note that in every case, except for the package keyword, any modifications
or deviations from standard behaviour (i.e. anything in the <modifiers> column)
are always specified by attributes. And, arguably, the package version syntax
is a mis-design; it should have been :vers(v1.2.3) instead.
The only other significant deviation from this general syntactic pattern
is the way in which modern lexical subroutines are specified:
my sub foo () {...}
This syntax concatenates two keywords to denote the non-standard
behaviour of a lexically scoped subroutine. However, I would argue that
this too was a mis-design, or at least an anomaly. It would have been
much more consistent with Perl’s underlying syntactic structure if the
syntax had been:
sub foo :lexical () {...}
Or, perhaps, if we had added a completely new declarator keyword
to reflect the fundamental differences between package and lexical subs:
lexsub foo () {...}
Except in the two cases noted above, the unifying principle of Perl’s
declaration syntax is that the keyword specifies what the declarand is,
and the optional modifiers (i.e. attributes) specify how this particular
declarand differs from the standard behaviour for that kind of declarand.
Or in OO terms: the keyword specifies the standard type
that the declarand IS-A new instance of, and the modifiers
specify any unusual roles/traits or non-standard behaviours
that this particular declarand also DOES.
Which brings us to the new object-oriented declaration syntax
proposed in Corinna.
Here’s a somewhat contrived example that attempts to exercise
all of the new OO features that Corinna provides:
role Tracked {
slot $msg :param;
method report () { $self->show($msg++) }
method show;
}
class Root {
method is_root () { return 1; }
}
abstract class Counter {
my $obj_count = 0; # common slot for all objects in class
method obj_count :common () { return $obj_count; }
ADJUST { $obj_count++ }
DESTRUCT { $obj_count-- }
}
class MetaHandler isa Counter does Tracked {
slot $handler :handles(exists delete) = Handler->new;
slot $size :reader :param = 100;
slot $created :reader = time;
ADJUST { croak("Too small") if $size < 1; }
DESTRUCT { $handler->shutdown; }
method insert :private ($key, $value ) {
if ( ! $self->exists($key) ) {
$handler->set( $key, $value );
}
}
method show ($msg) { say $msg; }
method obj_count :overrides :common () {
$self->next::method() - 42;
}
before method obj_count :common () { warn "Counting..."; }
after method obj_count :common () { warn "...done"; }
around method obj_count :common () { return 1 + $class->$ORIG(); }
}
Note that most of these new constructs conform well to the standard syntactic structure
for declarations:
<keyword> <identifier> <modifiers> <setup>?
role Tracked {...}
class Root {...}
slot $msg :param
slot $handler :handles(exists delete) = Handler->new;
slot $size :reader :param = 100;
slot $created :reader = time;
method is_root () {...}
method show
method report () {...}
method obj_count :common () {...}
method insert :private ($key,$value) {...}
method show ($msg) {...}
method obj_count :overrides :common () {...}
But a few of them diverge significantly from that standard syntactic structure:
<modifier> <keyword> <identifier> <setup>
abstract class Counter {...}
<keyword> <identifier> <keyword-modifiers> <setup>
class MetaHandler isa Counter does Tracked {...}
<modifier> <keyword> <identifier> <modifiers> <setup>
before method obj_count :common () {...}
after method obj_count :common () {...}
around method obj_count :common () {...}
So while Corinna usually specifies modifiers on a declarand in the standard
Perl <modifier> syntactic position, sometimes a modifier is instead
specified via a prefix keyword, or with both a prefix keyword and
something in the usual <modifier> slot:
before method obj_count :common () {...}
Of course, the class and role declarators do specify some modifiers
(namely: the classes they inherit and the roles they compose)
in the third syntactic position that is traditionally reserved for modifiers.
But they don’t specify those modifiers in the standard form: as attributes.
Instead, they are specified as internal keyword-modifier subsequences:
class Name isa <modifier> does <modifier> {...}
There is one other significant deviation from standard Perl
syntactic structure in the Corinna proposal: a particularly
nasty case in which specific non-standard behaviour must be
requested implicitly by context, rather than explicitly
by a distinct keyword or attribute.
Namely, when specifying class data slots:
my $obj_count = 0; # common slot for all objects in the class
Of course, this declaration does still have a keyword, but that my keyword
is silently behaving very differently from every other my keyword, simply because
of the context in which it’s being used. Hence the need to comment it,
as a reminder of those unusual extra behaviours.
So how is it different? (And notice that the very fact you have to ask about this
tells you that it really shouldn’t be different at all!)
The example my keyword does still inject the symbol $obj_count into
the current lexical scope but, because that lexical scope is the block
of a class, that particular my has two fundamental context-sensitive
differences from any other my declaration anywhere else in the program.
Specifically, because it is declared inside a class declaration,
the initialization behaviour and the destruction behaviour of
this lexical variable are completely different. Normally, a my
variable is initialized at run-time, every time it is encountered
in the code. And it is garbage-collected in the usual way
whenever it goes out of scope with a zero reference-count.
But inside a Corinna class, a my variable is initialized only
once — at compile-time — and is garbage-collected only once — after
all execution terminates.
That’s the correct and necessary behaviour for a variable which is
acting as a class data slot, because we have to be able to use
class data slots everywhere, including inside a BEGIN, CHECK, INIT,
or END block. So class data has to be initialized
at compile-time and persist until the end of execution.
But those special context-sensitive initialization and destruction
semantics are nothing like the behaviour of a regular my variable
in any other Perl code. So, even though they’re essential to the correct
working of their surrounding class, those semantics are
also likely to be misleading, confusing, bug-inducing, and brittle.
So, how do we fix these various problems?
The inconsistencies that are purely syntactic in nature:
abstract class Counter {...}
class MetaHandler isa Counter does Tracked {...}
before method obj_count :common () {...}
after method obj_count :common () {...}
around method obj_count :common () {...}
...could easily be handled either by replacing all pre-keyword modifiers
and all post-identifier keyword-modifier pairs with simple attributes:
class Counter :abstract {...}
class MetaHandler :isa(Counter) :does(Tracked) {...}
method obj_count :before :common () {...}
method obj_count :after :common () {...}
method obj_count :around :common () {...}
...or, alternatively, by providing additional keywords to replace the current prefix
modifier-keyword sequences:
abstraction Counter {...}
before obj_count :common () {...}
after obj_count :common () {...}
around obj_count :common () {...}
Creating new attributes is almost certainly the better choice here, however.
One of Corinna’s fundamental design principles is to avoid adding new
declarator keywords to Perl wherever possible. So far, we’ve only needed to add four:
class, role, slot, and method.
We could add more keywords for abstract classes plus the three kinds of
method wrappers, but that would double the proposed number of new keywords,
and with a proportionately much smaller payback on the second four,
as those specialized constructs are
far less common than classes, roles, slots, and methods.
Method wrappers can also be a “code smell” in OO code, indicating something
is amiss is the original design of a class hierarchy. So it seems odd to
devote three entire keywords to them.
Of course, the concept of being able to extend an existing chunk
of behaviour without having to copy-and-paste the original code is,
in itself, perfectly valid. But that concept is also
not unique to methods. We might, for example want to be
able to wrap regular subroutines as well. But if we make before
mean before method, we’d then have to come up with yet another
keyword (ante? ere?, afore?) if we ever want to support
before sub. And that way lies madness.
To leave open the future possibility of general-purpose wrappers,
it’s clearly better to specify method wrappers with attributes
(:before, :after, :around), so that those same
attributes might later be applied to subroutines as well,
if we ever decide that Perl should also have that capacity.
As for the implicit, context-sensitive behaviour of my inside
a class or role, it could also be made explicit and context-free
via either of those same two syntactic changes.
That is: either by an explicit attribute on an existing keyword:
slot $obj_count :common = 0;
...or else with a more precise, distinct, and explicit keyword:
common $obj_count = 0;
Here too, an attribute is probably the right choice. A class data slot
still intrinsically IS-A data slot, just one that DOES something
slightly different in terms of its initialization and destruction.
So the slot keyword is the right one for it, with a :common
attribute to denote the differing behaviour.
Moreover, we already specify class methods using the :common attribute.
So it would be more consistent (i.e. more teachable and more likely to just DWIM)
if we also specify class slots with that same attribute.
But whether or not we add a common keyword, or simply allow
a :common attribute on the slot keyword, the use of my
as a declarator for class data slots really has to go.
Having declarators whose behaviour silently changes in fundamental
ways depending on their context is always a Very Bad Idea.
Note, too, that by adopting the slot $name :common approach for
specifying class slots, we also remove the very real annoyance
of always having to hand-code any accessors for such slots:
my $obj_count = 0;
method obj_count :common () { return $obj_count; }
...because now we can just write:
slot $obj_count :common :reader = 0;
The only remaining problem is the actual name of the :common attribute.
While I do agree that “common” is the least-worst linguistic alternative
to have been suggested so far, it’s still significantly less-than-awesome.
So what is the fundamental difference between an instance slot and a class slot,
or between an instance method and a class method?
Well, it’s right there in the definition:
Class slots and methods are mutually shared
and jointly accessible by all objects, classwide.
So, instead of:
slot $obj_count :common = 0;
method obj_count :common () {...}
before obj_count :common () {...}
...why not:
slot $obj_count :joint = 0;
method obj_count :joint () {...}
before obj_count :joint () {...}
...or:
slot $obj_count :mutual = 0;
method obj_count :mutual () {...}
before obj_count :mutual () {...}
...or even:
slot $obj_count :classwide = 0;
method obj_count :classwide () {...}
before obj_count :classwide () {...}
Myself, I rather like :joint. It’s concise, distinct, and (best of all)
I’m sure there are a couple of really good “role-ing a joint” and
“high-class joint” puns to be had in there somewhere!
Ahem.
Anyway, putting all those ideas together, the earlier full example
would become:
role Tracked {
slot $msg :param;
method report () { $self->show($msg++) }
method show;
}
class Root {
method is_root () { return 1; }
}
class Counter :abstract {
slot $obj_count :common :reader = 0;
ADJUST { $obj_count++ }
DESTRUCT { $obj_count-- }
}
class MetaHandler :isa(Counter) :does(Tracked) {
slot $handler :handles(exists delete) = Handler->new;
slot $size :reader :param = 100;
slot $created :reader = time;
ADJUST { croak("Too small") if $size < 1; }
DESTRUCT { $handler->shutdown; }
method insert :private ($key, $value ) {
if ( ! $self->exists($key) ) {
$handler->set( $key, $value );
}
}
method show ($msg) { say $msg; }
method obj_count :common :overrides () {
$self->next::method() - 42;
}
method obj_count :common :before () { warn "Counting..."; }
method obj_count :common :after () { warn "...done"; }
method obj_count :common :around () { return 1 + $class->$ORIG(); }
}
They’re not huge changes to the current proposal,
but I think they make the new OO syntax cleaner, clearer,
more consistent, and — most importantly — more Perlish.
