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

Re: RFC-Modern OOP In Perl

Thread Previous | Thread Next
Ovid via perl5-porters
January 17, 2022 09:05
Re: RFC-Modern OOP In Perl
Message ID:
On Sunday, 16 January 2022, 21:27:01 CET, Ricardo Signes <> 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.

IT consulting, training, specializing in Perl, databases, and agile development 

Buy my book! -

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