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

Re: RFC-Modern OOP In Perl

Thread Previous | Thread Next
Ricardo Signes
January 16, 2022 20:26
Re: RFC-Modern OOP In Perl
Message ID:
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:

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? :)

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About