develooper Front page | perl.perl5.porters | Postings from January 2022

RFC-Modern OOP In Perl

Thread Next
From:
Ovid via perl5-porters
Date:
January 7, 2022 17:20
Subject:
RFC-Modern OOP In Perl
Message ID:
1407714050.1642241.1641576001639@mail.yahoo.com
Please note that this RFC is a touch different from others because the scope is much larger than other RFCs. Thus, we'll be light on the details here because it would be overwhelming. If you're not familiar with a particular aspect, please post questions and see the full MVP description if you need clarification on the semantics or syntax: https://github.com/Ovid/Cor

Note that most of the below work already works via https://metacpan.org/pod/Object::Pad. Companies are using this in production now.

I will be able to address many questions, but Paul Evans (LeoNerd) will address others as he's the person who will be implementing this. I've already pledged to help by writing tests. All Around the World, the company I work for, is sponsoring the time for this and we've set up a repositotory for the work on github.

---

This is an MMVP (Minimally Minimal Viable Product). This is written after guidance provided to me by the Perl Steering committee. This addresses a few concerns.

* The more we push into core, the more bugs there will be
* The more we push into core, the more time it will take
* The more we push into core, the more people might rely on misfeatures
* We only have one LeoNerd working on this (send more LeoNerds!)

Thus, Corinna development for core will be staged, with subsequent work to realize the full MVP. 

Thus, we want the simplest thing that could possibly work in the first round, but what would that be?

We can look at code as having two parts:

* functional code (the code we write that solves our problem)
* structural code (the code we write to wire all the functional bits together)

Corinna provides a rich mixture of both functional and structural code.

To approach an MMVP, the intent here is to strip out most structural code that we can write by hand to get us to the functional core of Corinna. However, we want to do this in a way that's forward-compatible.

For example, we don't anticipate implementing the :handles modifier, but we can still handle that manually and it won't break later assuming the code is unchanged:

    class Foo {
        use DateTime;
        field $datetime { DateTime->now };

        method last_date_of_month () {
            return $datetime->last_day_of_month;
        }
    }

What follows is a minimal description of what we'd like for the MMVP. The plan is to implement this in seven stages. Each stage will be pushed separately, giving us time to test and verify that it does what we need. Note that some features are specified, in terms of semantics, but in the spirit of "no plan survives first contact with the enemy," we will nail some of the syntax down as we write tests to verify the behavior and solicit feedback from those playing with it.

The Seven Samurai (er, stages):

1. Classes

Initial `use feature 'class'` to add basic class/field/method. and ADJUST/ADJUSTPARAMS blocks.

No roles, no class/slot/method attrs, no MOP.

2. Class inheritance - class :isa() attr

3. Roles, and class/role :does() attr

The current implementation of required methods is to simply create a forward declaration: method foo; without listing the signature. Signatures are currently not introspectable, so we cannot use them to verify that the correct required method is present, so we only use the name. Including a signature in the forward declaration might be self-documenting, but for now, we'd prefer to omit it because this might impact forward compatibility.

4. Various "convenience" attributes -

field :reader :writer :accessor :mutator
field :weak
field :param
method :overrides()

At this stage, most of the basics are in place and we have a useful system.

5. Slot initialiser blocks

6. MOP

7. Method modifiers (around, before, after)

Missing Features

Obviously, quite a few features are missing from this RFC of Corinna. Our intent is to roll them out as quickly as is feasible, but to ensure the foundation is stable.

Potentially Breaking Changes

The following features are not planned for the MMVP and might break your code in subsequent releases.

* Error on unknown constructor parameters
* Deterministic destruction might cause issues when introduced
* Many other features (see the github repo)

There are a ton of other feature omitted, but have been not mentioned here because they're not even part of the Corinna MVP (role exclusion and aliasing being a perfect example).

Best,
Ovid
-- 
IT consulting, training, specializing in Perl, databases, and agile development
http://www.allaroundtheworld.fr/. 

Buy my book! - http://bit.ly/beginning_perl

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About