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

Re: RFC-Modern OOP In Perl

Thread Previous | Thread Next
From:
Dan Book
Date:
January 17, 2022 17:08
Subject:
Re: RFC-Modern OOP In Perl
Message ID:
CABMkAVXPVZOzRq4+oKhV3ya8kLCP7K5U3XveQ7muHZ4NYuwuYA@mail.gmail.com
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

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