Mailing List Archive

RFC-Modern OOP In Perl
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
Re: RFC-Modern OOP In Perl [ In reply to ]
This all sounds good, I support it.

To clarify, do you consider each Samurai to be shippable without subsequent
ones, so for example if the first Samurai was completely done in time it could
be released with production perl this Spring even if later Samurai are not?

As your company is already financially supporting the implementation of this,
what is the estimate for when the first Samurai would be delivered as a "perl"
pull request?

-- Darren Duncan

On 2022-01-07 9:20 a.m., Ovid via perl5-porters wrote:
> 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
Re: RFC-Modern OOP In Perl [ In reply to ]
The company is supporting this effort in terms of donating my time and paying for the LeoNerd as a collaborator on the git repo (we’re maxed out on free collaborators).
Each step builds on previous steps but should be independently shippable. I can’t say that they’ll be particularly useful to any except those helping to find bugs. Expectation management will be important here. 
LeoNerd is better place to give a time estimate. 
Best,Ovid


Sent from Yahoo Mail for iPad


On Saturday, January 8, 2022, 2:56 AM, Darren Duncan <darren@darrenduncan.net> wrote:

This all sounds good, I support it.

To clarify, do you consider each Samurai to be shippable without subsequent
ones, so for example if the first Samurai was completely done in time it could
be released with production perl this Spring even if later Samurai are not?

As your company is already financially supporting the implementation of this,
what is the estimate for when the first Samurai would be delivered as a "perl"
pull request?

-- Darren Duncan

On 2022-01-07 9:20 a.m., Ovid via perl5-porters wrote:
> 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
Re: RFC-Modern OOP In Perl [ In reply to ]
On 2022-01-07 11:48 p.m., Ovid via perl5-porters wrote:
> Each step builds on previous steps but should be independently shippable. I
> can’t say that they’ll be particularly useful to any except those helping to
> find bugs. Expectation management will be important here.

> On 2022-01-07 9:20 a.m., Ovid via perl5-porters wrote:
> >
> > 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.

I think you under-estimate the usefulness of early steps.

As far as I'm concerned, Samurai 1 delivers like 50% of the total value and
usefulness of the MMVP all by itself.

That gives us a distinct opaque base type for real Perl objects, that is
mutually exclusive from all Perl types that exist now, with fields that are
syntactically like regular variables rather than hash keys. Everything more
than that is gravy.

So a Perl major release that has just Samurai 1 would be huge by itself, a game
changer by itself, a MMMVP, and VERY useful.

I would definitely make heavy use of said new Perl version for that alone. For
my personal industrial-scale FLOSS project, nothing I expect to make money from
in the short term.

So while the full MMVP is nice, delivering Samurai 1 to production this Spring
is a very worthwhile goal by itself.

I would also be willing to personally donate some coin specifically towards a
Samurai 1 for Spring release.

-- Darren Duncan
Re: RFC-Modern OOP In Perl [ In reply to ]
If you want to donate, contact LeoNerd. My contributions are taking time from some clients, but it’s a fair trade off. 
Best,Ovid


Sent from Yahoo Mail for iPhone


On Saturday, January 8, 2022, 9:39 AM, Darren Duncan <darren@darrenduncan.net> wrote:

On 2022-01-07 11:48 p.m., Ovid via perl5-porters wrote:
> Each step builds on previous steps but should be independently shippable. I
> can’t say that they’ll be particularly useful to any except those helping to
> find bugs. Expectation management will be important here.

>    On 2022-01-07 9:20 a.m., Ovid via perl5-porters wrote:
>      >
>      > 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.

I think you under-estimate the usefulness of early steps.

As far as I'm concerned, Samurai 1 delivers like 50% of the total value and
usefulness of the MMVP all by itself.

That gives us a distinct opaque base type for real Perl objects, that is
mutually exclusive from all Perl types that exist now, with fields that are
syntactically like regular variables rather than hash keys.  Everything more
than that is gravy.

So a Perl major release that has just Samurai 1 would be huge by itself, a game
changer by itself, a MMMVP, and VERY useful.

I would definitely make heavy use of said new Perl version for that alone.  For
my personal industrial-scale FLOSS project, nothing I expect to make money from
in the short term.

So while the full MMVP is nice, delivering Samurai 1 to production this Spring
is a very worthwhile goal by itself.

I would also be willing to personally donate some coin specifically towards a
Samurai 1 for Spring release.

-- Darren Duncan
Re: RFC-Modern OOP In Perl [ In reply to ]
* Ovid via perl5-porters <perl5-porters@perl.org> [2022-01-08 09:25:40 +0000]:

> If you want to donate, contact LeoNerd. My contributions are taking time from some clients, but it?s a fair trade off.?
> Best,Ovid

Please go on. I feel like I am the only one not getting
paid for the effort. xD

Cheers,
Brett

>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Saturday, January 8, 2022, 9:39 AM, Darren Duncan <darren@darrenduncan.net> wrote:
>
> On 2022-01-07 11:48 p.m., Ovid via perl5-porters wrote:
> > Each step builds on previous steps but should be independently shippable.?I
> > can?t say that they?ll be particularly useful to any except those helping to
> > find bugs. Expectation management will be important here.
>
> >? ? On 2022-01-07 9:20 a.m., Ovid via perl5-porters wrote:
> >? ? ? >
> >? ? ? > 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.
>
> I think you under-estimate the usefulness of early steps.
>
> As far as I'm concerned, Samurai 1 delivers like 50% of the total value and
> usefulness of the MMVP all by itself.
>
> That gives us a distinct opaque base type for real Perl objects, that is
> mutually exclusive from all Perl types that exist now, with fields that are
> syntactically like regular variables rather than hash keys.? Everything more
> than that is gravy.
>
> So a Perl major release that has just Samurai 1 would be huge by itself, a game
> changer by itself, a MMMVP, and VERY useful.
>
> I would definitely make heavy use of said new Perl version for that alone.? For
> my personal industrial-scale FLOSS project, nothing I expect to make money from
> in the short term.
>
> So while the full MMVP is nice, delivering Samurai 1 to production this Spring
> is a very worthwhile goal by itself.
>
> I would also be willing to personally donate some coin specifically towards a
> Samurai 1 for Spring release.
>
> -- Darren Duncan
>
>
>

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: RFC-Modern OOP In Perl [ In reply to ]
On Friday, 7 January 2022, 18:20:01 CET, Ovid <curtis_ovid_poe@yahoo.com> wrote:


> Please note that this RFC is a touch different from others because the scope is much larger than other RFCs. <snip>

Oops. I realize, belatedly, that I didn't quite follow the process as it's currently described: https://github.com/Perl/RFCs/blob/master/docs/process.md

The following is the original RFC in the Corinna repository: https://github.com/Ovid/Cor/blob/master/rfc/overview.md

That should cover the basics of what we intend for this RFC, with the scope reduced as described in the original email.

If you would like me to rewrite the RFC into a single document, please let me know. I would still prefer to omit fine-grained detail and provide reference to the RFC repository. Otherwise, I would be providing an email long enough that I guarantee it won't be read :)

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

Buy my book! - http://bit.ly/beginning_perl
Re: RFC-Modern OOP In Perl [ In reply to ]
I figured I'd give all of this a few days to percolate, but aside from Darren wanting this, there's been silence. Where do we go from here?

The scope's been reduced to meet the PSC's request, there's broad community support, there's a working prototype, LeoNerd's ready to do it.

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

Buy my book! - http://bit.ly/beginning_perl
Re: RFC-Modern OOP In Perl [ In reply to ]
On 2022-01-11 12:19 a.m., Ovid via perl5-porters wrote:
> I figured I'd give all of this a few days to percolate, but aside from Darren wanting this, there's been silence. Where do we go from here?
>
> The scope's been reduced to meet the PSC's request, there's broad community support, there's a working prototype, LeoNerd's ready to do it.

Perhaps it would be good to have a few explicit declarations from people with
the ability to do so that they would be willing to review and merge LeoNerd's
implementing pull requests once they exist, since that is the very least that we
actually need to land it, even if nothing else happens. -- Darren Duncan
Re: RFC-Modern OOP In Perl [ In reply to ]
On 1/11/22 01:39, Darren Duncan wrote:
> On 2022-01-11 12:19 a.m., Ovid via perl5-porters wrote:
>> I figured I'd give all of this a few days to percolate, but aside from
>> Darren wanting this, there's been silence. Where do we go from here?
>>
>> The scope's been reduced to meet the PSC's request, there's broad
>> community support, there's a working prototype, LeoNerd's ready to do it.
>
> Perhaps it would be good to have a few explicit declarations from people
> with the ability to do so that they would be willing to review and merge
> LeoNerd's implementing pull requests once they exist, since that is the
> very least that we actually need to land it, even if nothing else
> happens. -- Darren Duncan

I say we don't need such declarations. That's never been a requirement
for a pull request, and though some languish, there will be significant
pressure and enthusiasm to cause it to be reviewed.

Go for it.
Re: RFC-Modern OOP In Perl [ In reply to ]
On Fri, Jan 7, 2022, at 12:20 PM, Ovid via perl5-porters wrote:
> 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

Thanks, Ovid! Sorry for the (much longer than I realized) delay in replying. This reply is probably going to be a bit all over the place, so let me start with: I think this looks good.

Later in the thread, Karl said, "I don't think you need a pronouncement from the PSC." I think that's true. People who show up with great work won't get turned away just because they didn't ask permission first. But, also, as we talk about RFCs and making sure you don't show up with work that we could've said no to up front, I think it's a good idea to get some up-front response!

Paul and Neil and I spoke on Friday about Corinna, and I think it's safe to sum it up as follows — but those two should correct me if they think I'm wrong:
* This looks good.
* We would like to commit features to perl5.git as they are suitable for experimental use.
* We think the whole enchilada should *probably* remain experimental until either (a) it has done or (b) work seems to have ceased.
I want to elaborate on that last point:

The three of us and Curtis spoke a while ago, and talked about wanting to avoid something that was experimental for ages and that people came to rely on, but also to avoid having something developed only in a weird branch somewhere that was never compiled or played with by even avid Perl users. That led to "let's try to deliver in chunks, and small ones."

But say we deliver in small chunks. There are to be seven chunks. By the time we're delivering chunk six, we may realize that chunk one needs a design change. If we've made it non-experimental, this is off limits! We should have wiggle room in the early chunks on the later ones that build on them are coded.

On the other hand, if we ship chunks 1-3, and then Paul and Ovid both win the lottery and retire from working on Perl, we would want to be able to say "chunks 1-3 were good, we should call them done." If we want to start up later, well, now the concrete of the foundation has set.

The actual calendar time required to implement all this stuff isn't known, so the impact of "let's keep it experimental until done" is not clear, and I think a lot of this can be negotiable as we go along. If Ovid says "We finished part 1, and it's 100% perfect, and we should call it stable, and I promise not to renege on that later," I (at least) am open to hearing it! But we're thinking "let's start by assuming it's fluid until done, but that shipping in pieces helps accelerate contact with the enemy."

???? That, above, is the biggest point to communicate. "Looks good, we have thoughts on how we mark it stable."

Now, maybe just one or two almost tediously small questions:

> 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.

You say class/field/method, then class/slot/method. I presume that "field" and "slot" are interchangeable?

> 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

How much inspectability would you have? Arity? Variable name? Requiredness of each? Op tree of defaults? :)

--
rjbs
Re: RFC-Modern OOP In Perl [ In reply to ]
On Sunday, 16 January 2022, 21:27:01 CET, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:


> The actual calendar time required to implement all this stuff isn't known, so the impact of "let's keep it
> experimental until done" is not clear, and I think a lot of this can be negotiable as we go along.  If Ovid
> says "We finished part 1, and it's 100% perfect, and we should call it stable, and I promise not to
> renege on that later," I (at least) am open to hearing it!  But we're thinking "let's start by assuming it's
> fluid until done, but that shipping in pieces helps accelerate contact with the enemy."

I think the odds of me saying that are pretty much zero. Different people will have different expectations, but for me, Corinna won't really be usable until stage five is delivered (maybe stage 6). The preceding stages just lay the groundwork.

Further, I *do* remember pseudohashes and am keen not to make the same mistake.

> ???? That, above, is the biggest point to communicate.  "Looks good, we have thoughts on how we mark
> it stable."

> Now, maybe just one or two almost tediously small questions:

> You say class/field/method, then class/slot/method.  I presume that "field" and "slot" are
>  interchangeable?

Yes, they are. I say "slot" out of habit, but now it's just "field," so pretend the word "slot" doesn't exist.

> > 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

> How much inspectability would you have?  Arity?  Variable name?  Requiredness of each?  Op tree of
> defaults? :)

Is this needing an answer now? I've started to answer several times and it kept getting too long-winded and too speculative, and I'm going to do it again.

I can't easily answer that and it's going to take a lot of discussion/design. To do it properly for required methods in roles, we also need types and return values and I don't expect either of those are on the table, so we can just punt and go with arity, but that could hobble further development if we get it wrong.

But let's say we go with arity, defined as the minimum *required* number of arguments. Do we include the invocant such that no method can have an arity of zero? And is this only for introspection or do we expose it for can()?

    class Some::Class {
        sub bar($first,$second,$third) {...}
        method bar($baz) {...}
    }

In other words, do we allow `can('bar/1')`? It would only refer to the method and for a Corinna class, it would always return false for subs.

And what's the arity of these?

    method foo(@bar) {...}
    method foo(%bar) {...}

If we don't include the invocant in arity, both of the above are foo/0, even though we have different expectations on how they would be called. We'd have to decide if we're ok with that. If those didn't flatten, it might be easier, though that's not going to happen.

And if we go with variable names, that would be used for named arguments, yes? Otherwise, it wouldn't matter and I don't think it applies to our case.

As for requiredness, that's hard, too because it complicates arity. 

    method foo($bar) {...} # foo/1
    method foo($quuz, $extra = rand) { ... } # foo/1 

And note that code (rand) is embedded in that last signature. Great; sigs are Turing Complete. Screw me, I don't want to think about that right now.

There are many questions I think it would be worthwhile to answer, but perhaps outside the scope of the MMVP because this will require lots of careful thought/design. I don't think most of these questions are hard if we limit ourselves to only arity and never think about future needs, but here be dragons.

At the end of the day, we've scraped by for decades by ignoring this. I'm happy to scrape by a little longer unless we identify a compelling need to answer this now.

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

Buy my book! - http://bit.ly/beginning_perl
Re: RFC-Modern OOP In Perl [ In reply to ]
On 2022-01-17 1:05 a.m., Ovid via perl5-porters wrote:
> On Sunday, 16 January 2022, 21:27:01 CET, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>  > 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
>>
>>  How much inspectability would you have?  Arity?  Variable name?  Requiredness of each?  Op tree of
>> defaults? :)
>
> Is this needing an answer now? I've started to answer several times and it kept getting too long-winded and too speculative, and I'm going to do it again.

For what its worth, languages like Java and C# have a fair amount of
introspectability of classes/routines/parameters/etc, maybe something to learn from.

> I can't easily answer that and it's going to take a lot of discussion/design. To do it properly for required methods in roles, we also need types and return values and I don't expect either of those are on the table, so we can just punt and go with arity, but that could hobble further development if we get it wrong.
>
> But let's say we go with arity, defined as the minimum *required* number of arguments. Do we include the invocant such that no method can have an arity of zero? And is this only for introspection or do we expose it for can()?
>
>     class Some::Class {
>         sub bar($first,$second,$third) {...}
>         method bar($baz) {...}
>     }

In the general case, the invocant object instance absolutely is a logical
required argument.

So-called object-orientation is just syntactic sugar anyway that lets you treat
one argument as special. There's nothing in OO that doesn't have counterparts
in functional languages and such.

Saying "$x->f($y)" is nothing more than syntactic sugar for "f($x,$y)".

Logically the ONLY zero-argument function is a constant definition, it always
returns the same single value.

A common use case of these is to define the default value for a field/variable/etc.

Any method that can behave differently depending which invocant object it is
called on must have an arity of at least 1, that being the invocant.

So you CAN have arity-zero methods, but these do NOT have any references to the
invocant in them, so you get the same result no matter which object you call
them on.

-- Darren Duncan
Re: RFC-Modern OOP In Perl [ In reply to ]
On Mon, Jan 17, 2022 at 4:05 AM Ovid via perl5-porters <
perl5-porters@perl.org> wrote:

> On Sunday, 16 January 2022, 21:27:01 CET, Ricardo Signes <
> perl.p5p@rjbs.manxome.org> wrote:
>
>
> > The actual calendar time required to implement all this stuff isn't
> known, so the impact of "let's keep it
> > experimental until done" is not clear, and I think a lot of this can be
> negotiable as we go along. If Ovid
> > says "We finished part 1, and it's 100% perfect, and we should call it
> stable, and I promise not to
> > renege on that later," I (at least) am open to hearing it! But we're
> thinking "let's start by assuming it's
> > fluid until done, but that shipping in pieces helps accelerate contact
> with the enemy."
>
> I think the odds of me saying that are pretty much zero. Different people
> will have different expectations, but for me, Corinna won't really be
> usable until stage five is delivered (maybe stage 6). The preceding stages
> just lay the groundwork.
>
> Further, I *do* remember pseudohashes and am keen not to make the same
> mistake.
>
> > ???? That, above, is the biggest point to communicate. "Looks good, we
> have thoughts on how we mark
> > it stable."
> >
> > Now, maybe just one or two almost tediously small questions:
> >
> > You say class/field/method, then class/slot/method. I presume that
> "field" and "slot" are
> > interchangeable?
>
> Yes, they are. I say "slot" out of habit, but now it's just "field," so
> pretend the word "slot" doesn't exist.
>
> > > 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
> >
> > How much inspectability would you have? Arity? Variable name?
> Requiredness of each? Op tree of
> > defaults? :)
>
> Is this needing an answer now? I've started to answer several times and it
> kept getting too long-winded and too speculative, and I'm going to do it
> again.
>
> I can't easily answer that and it's going to take a lot of
> discussion/design. To do it properly for required methods in roles, we also
> need types and return values and I don't expect either of those are on the
> table, so we can just punt and go with arity, but that could hobble further
> development if we get it wrong.
>
> But let's say we go with arity, defined as the minimum *required* number
> of arguments. Do we include the invocant such that no method can have an
> arity of zero? And is this only for introspection or do we expose it for
> can()?
>
> class Some::Class {
> sub bar($first,$second,$third) {...}
> method bar($baz) {...}
> }
>
> In other words, do we allow `can('bar/1')`? It would only refer to the
> method and for a Corinna class, it would always return false for subs.
>
> And what's the arity of these?
>
> method foo(@bar) {...}
> method foo(%bar) {...}
>
> If we don't include the invocant in arity, both of the above are foo/0,
> even though we have different expectations on how they would be called.
> We'd have to decide if we're ok with that. If those didn't flatten, it
> might be easier, though that's not going to happen.
>
> And if we go with variable names, that would be used for named arguments,
> yes? Otherwise, it wouldn't matter and I don't think it applies to our case.
>
> As for requiredness, that's hard, too because it complicates arity.
>
> method foo($bar) {...} # foo/1
> method foo($quuz, $extra = rand) { ... } # foo/1
>

I don't have enough experience in how other languages may represent arity,
but indeed to me, it seems if you are going for "how many arguments is the
call *required* to provide" then both optional arguments and slurpy
arguments don't contribute to it, but instead contribute to the maximum
allowed argument count.

Not that it really needs to be discussed right now, but I would strongly
prefer a new interface entirely over monkey patching this into
UNIVERSAL::can. Or at the very least, using additional arguments would be
cleaner and more extensible: ->can('foo', 1)

-Dan
Re: RFC-Modern OOP In Perl [ In reply to ]
On Mon, Jan 17, 2022, at 4:05 AM, Ovid wrote:
> On Sunday, 16 January 2022, 21:27:01 CET, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
> > > 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
> >
> > How much inspectability would you have? Arity? Variable name? Requiredness of each? Op tree of
> > defaults? :)
>
> Is this needing an answer now? I've started to answer several times and it kept getting too long-winded and too speculative, and I'm going to do it again.

It doesn't need to be answered now. I only ask because inspecting arity of subroutines was a live conversation in another thread. Thanks for your comments on this, I read them and took them in.

--
rjbs