Corinna

RFC

This file is automatically generated. If you wish to submit a PR, do not edit this file directly. Please edit templates/README.md instead.

---

Bringing Modern OOP to the Perl Core

class Cache::LRU v0.1.0 {
    use Hash::Ordered;
    use Carp 'croak';

    field $num_caches :common                 = 0;
    field $cache      :handles(exists delete) = Hash::Ordered->new;
    field $max_size   :param  :reader         = 20;
    field $created    :reader                 = time;

    ADJUST { # called after new()
        $num_caches++;
        if ( $max_size < 1 ) {
            croak(...);
        }
    }
    DESTRUCT { $num_caches-- }

    method num_caches :common () { $num_caches }

    method set( $key, $value ) {
        $cache->unshift( $key, $value );    # new values in front
        if ( $cache->keys > $max_size ) {
            $cache->pop;
        }
    }

    method get($key) {
        return unless $cache->exists($key);
        my $value = $cache->get($key);
        $self->unshift( $key, $value );     # put it at the front
        return $value;
    }
}

This repository is to track the RFC for the Corinna MVP OOP proposal.

1. Table of Contents
2. Overview
3. Grammar
4. Classes
5. Class Construction
6. Fields
7. Methods
8. Roles
9. Phasers
10. Method Modifiers
11. Questions
12. Quotes
13. Changes
14. P5P MVP
15. FAQ

Important: All of the above represent works in progress. Please do not consider this the final RFC. We're writing down the shell of the RFC and will fine-tune. Anything in the Wiki should be considered "rough drafts."

Section Numbers

As you navigate the various RFC pages, you'll note that it's broken down into fine-grained section numbers such as 3.2.2. Prior to the RFC being filed, these are fluid and will likely change without warning. After the RFC is filed, we may make minor changes to the sections, but the section numbers themselves should be frozen to make it easy to refer to a given section.

Not a Tutorial

This is not a tutorial on OO programming. That could easily fill a book. It's assumed you're already very familiar with Perl's built-in OO. It's very useful if you're also familiar with Moo/se.

However, here's a basic tutorial for Corinna if you'd like to skip the detail.

Principle of Parsimony

Many things in the proposal are deliberately restrictive, such as Corinna only allowing single inheritance. This is to allow Corinna to be cautious in not promising too much. If we later find this too restrictive, we can allow multiple inheritance. However, if we start with multiple inheritance and discover we don't need or want multiple inheritance, we would break existing code by taking it away.

Any proposals to change the RFC must consider the principle of parsimony.

Note: it's been brought to my attention that the Principle of Parsimony is a phrase used in biology and has a different meaning. Oops.

KIM

We are trying to adhere to the KIM principle. In short, features should try to follow this syntax:

KEYWORD IDENTIFIER MODIFIER? SETUP?

So instead of this:

class Foo isa Bar does SomeRole v1.2.3 {
    overrides method some_method() {
        ...
    }
}

We're doing this:

class Foo :isa(Bar) :does(SomeRole) :version(v1.2.3) {
    method some_method :overrides () {
        ...
    }
}

By trying to have all syntax arranged like this we reduce the core of Corinna down to four new keywords:

• class
• role
• field
• method

Everything which tweaks those behaviors should be a modifier.

This part is still a work in progress and may evolve.

This Repository

This repository is not for code. Instead, it’s to have a central place to discuss the Corinna proposal to bring modern OO to the core of the Perl language.

You may be looking for the Wiki as that has much historical discussion of this project. However, the documents in the rfc/ folder will be considered the canonical ones.

You can file issues to address your particular concerns and get feedback.

MVP

This work is to drive us to v0.1.0—not v1.0.0—the “minimum viable product.” The intent is to get the subset of features we really need into the language, make sure it’s stable, and then iterate on top of that. I don’t want us building on top of this foundation only to discover the foundation is not stable.

I’ve been getting some pushback from people being quite insistent that if I don‘t support one or more of the features that they like to use, that it will be so terribly hobbled that it will be of limited use to them.

Please keep in mind that if this MVP does get into core, I will have lost control over it (yay!) and I’ll have no particularly greater voice than others. That means:

If this gets into the core and you want a feature, lobby for it.

I’m not a gatekeeper. I don’t want to be a gatekeeper. I want to get modern OO into the Perl core and the more things added to the MVP to scratch people’s personal itches, the more bugs there will be and the less likely it is to be stable. Let’s focus on the MVP and getting this in core.

After that, it will be up to the community to decide where it wants to go. I will have zero authority to stop things I disagree with if P5P decides to implement them. This will effectively be a democracy. A level playing field. If you won’t support Corinna because your personal favorite feature isn’t in the MVP, I don’t know what to say to that. You, like everyone else, will be able to lobby for that feature.

DEDICATION

This project is dedicated to the memory of both Jeff Goff and David Adler, two Perl developers who also loved Raku and worked to create a better language. They were both wonderful people and will be missed.