develooper Front page | perl.perl5.porters | Postings from June 2021

Re: This is not an RFC to bring modern OO into the Perl core

Thread Previous | Thread Next
From:
mah.kitteh via perl5-porters
Date:
June 22, 2021 01:02
Subject:
Re: This is not an RFC to bring modern OO into the Perl core
Message ID:
9-zYRWftwAP61EFS6oEnakvtBqgf5INq58RarCl7mhrkgjRdC0W0wc8MvKJaGPjXm3N1d7U0TaxMculReIIozvNMIShr3dLEfMyy5u5tvNY=@protonmail.ch
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, June 21st, 2021 at 5:26 PM, Darren Duncan <darren@darrenduncan.net> wrote:

> On 2021-06-21 7:10 a.m., Paul "LeoNerd" Evans wrote:
>
> > I can imagine two stages of implementation.
> >
> > In Stage 1 we do a fairly surface-level lift of the existing
> >
> > Object::Pad implementation, using perl core's parser (so plenty of
> >
> > edits to perly.y) and implementing most of the inner pieces in some new
> >
> > file - oo.c seems as good a working title as any. Some still-open
> >
> > questions at that point about things like where MOP objects will go.
> >
> > In Stage 2 we can do a deeper dive into things like making a true
> >
> > SVt_OBJECT (and maybe even SVt_CLASS) type to avoid some of the
> >
> > limitations that Object::Pad has had to do to work around the fact it
> >
> > is "only" an XS module and not true core, so it has limits to the new
> >
> > things it can invent.
> >
> > We'd only have to get as far as Stage 1 in order to be useful to Perl
> >
> > programmers as a core feature. (Well personally I'd argue that Stage 0,
> >
> > of Object::Pad existing, is also useful to Perl programmers ;). Stage 2
> >
> > is mostly about improving efficiency, better integration into core, and
> >
> > making possible things that could not be done currently in the CPAN
> >
> > module.
>
> So to confirm, these 2 stages are such that all user-visible changes happen in
>
> stage 1 and stage 2 is just performance improvements? Or would there be
>
> differences between stage 1 and stage 2 that are visible to the user?
>
> I would expect that if they're visibly different to users then these 2 stages
>
> would be part of a single development series, for example in 2 different 5.35.x,
>
> and that we wouldn't have say stage 1 only in 5.36.0 and stage 2 in 5.38.0, so
>
> regular users only ever see the outcome of stage 2.
>
> -- Darren Duncan

There is a reason people use the term "MVP" (minimal viable product). It's because in most cases that's all that gets delivered for an appreciable amount of time. Any RFC should encapsulate just a single pass without relying on a second to deliver something complete. Let's get some minimal, achievable "wins" under the belt. This will do wonders for moral. Anything else will demoralize further, there is no "in between". I think that the RFC as "use feature 'class'" accomplishes this. The trick is to define what is minimal, yet complete. So I have some skin in the game, I volunteer to help write Perl based tests given some well defined specification; that's where I can be most of service at this time. If someone can let me know where to start, I am happy to start working on that now (perhaps with Object::Pad?).

Cheers,
Brett

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