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
Paul "LeoNerd" Evans
June 21, 2021 14:10
Re: This is not an RFC to bring modern OO into the Perl core
Message ID:
On Sun, 20 Jun 2021 22:04:27 -0400
"Ricardo Signes" <> wrote:

> In general, I want to say that this is welcome.  What I'm most keen
> to get a handle on is "where it all gets shoved in".  That is:  I can
> imagine that this is "perl5.git gets oo.c which handles all this" or
> "we need to add three new parser hooks and a new kind of SV" or "this
> will all run on top of the existing core, but I want it to ship with
> perl."
> Can you (or Paul) give even a rough idea of where you think this will
> fall?  It will help set my level of circumspection later. ;)

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

Paul "LeoNerd" Evans      |  |

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