Principles of Perl 6

luqui on 2005-10-29T02:36:59

Ever since the Great Multimethod Debate, I've been introducing various principles into my arguments. These are my "axioms of semantics", and my hope is to take the hard questions and answer them purely in terms of reasoning from these basic principles. This is the kind of reasoning that makes me love mathematics: to reduce all hard decisions into obvious truths by using proper definitions of terms.

So, anyway, here's the list I have so far. (The other well-known Perl principles like Least Surprise, Waterbed, and Endweight are omitted. Maybe I'll do a writeup about those soon.)

The principle of free derivation (or composition): If you derive a class B from a class A, and B has an empty body (defines nothing new), then objects of class B should behave exactly like objects of class A[1]. Likewise for roles. This was the first principle I ever introduced, and I used it to argue against manhattan distance dispatch.
• The principle of partial definition: Defining a new type or instance can only break a previously well-typed program by making it ambiguous. Another way of saying that is: there may be types and instances already hidden in the algebra of your program, and making those instances explicit should not break anything.
• The principle of type:set isomorphism: There exists a type that describes every possible set of objects in your program, even if it not named, or even possible to name.

The motivations for the three were: manhattan MMD, the junctive one() type, and manhattan MMD again, respectively. Also note that the first principle precludes the existence of submethods. Now it's clear why I keep asking why we need submethods. It's not entirely clear why I continue not to get any answers[2].

[1] Up to metainformation, such as asking which class the object is in, of course.

[2] To be fair, Damian responded to my query, but he didn't answer my question. He gave more an example of how submethods are used, rather than why they are used.

---

Why submethods

Damian on 2005-10-29T10:24:09

To be fair, Damian responded to my query, but he didn't answer my question. He gave more an example of how submethods are used, rather than why they are used.

Subroutines are useful inside classes, for factoring class-specific implementation details out of the class's methods. The main reason they're useful is because they're not part of the object interface, and are not inherited. So they can be used purely as encapsulated implementation.

But factoring method implementations out into a subroutines is also extremely annoying, because a subroutine doesn't provide the internal conveniences that a method does. In particular, it doesn't have an invocant and so you can't call $.attrs or &.methods. Instead you would have to pass the invocant to the subroutine call as an argument and then call accessors and methods explicitly through that argument.

So we need a mechanism that is externally (i.e. from a class interface point-of-view) a subroutine, but internally has the features of a method (i.e. has an invocant). Since it's externally sub-like but internally method-like, we call this useful construct a submethod.