Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of luqui (5770)

Friday October 28, 2005
09:36 PM

Principles of Perl 6

[ #27362 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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