Front page | perl.perl5.porters |
Postings from September 2022
Re: Preview reviews / comments on feature-class branch
Thread Previous
From:
Elvin Aslanov
Date:
September 27, 2022 17:26
Subject:
Re: Preview reviews / comments on feature-class branch
Message ID:
CAJ4KP=322Pqqmt9Xbh0+QmCkV-p3anGfMALFHxk2GwYp3QcKvQ@mail.gmail.com
Happy to read, hoping to start using `class` with Perl 5.38 instead of
`bless` for many relatively simple cases.
I don't have enough C experience so cannot add much regarding the
code, but the design of it is beautiful.
Thanks.
On Tue, Sep 27, 2022 at 9:12 PM Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> TL;DR - please help review this large work ahead of PR-time, to avoid
> surprises later on and make the process run smoother
> (or explicitly opt-out)
>
>
> Hi all,
>
> Aside from needing some more waffly-english-wording in the
> documentation, the Stage 1 work for feature-class is basically done. We
> now have a branch with a simple implementation of standalone classes
> and lexical-like fields. Still missing and yet to be done are
>
> Stage 2 - :isa attribute and subclassing
> Stage 3 - :does attribute and roles
> Stage 4 - :reader, :writer etc.. conveniences on fields
> Stage 5 - field initialisation blocks
> Stage 6 - metaprogramming / introspection API
> ...
>
> These remaining stages aren't really in a dependency order - while it
> would be good to get subclassing before roles, the rest of the thoughts
> are fairly independent. I would like to get at least one or two more of
> them done before we think about presenting this in a "formal" PR for
> actual review with a view to merging into blead. I'm hoping that by
> Christmas (of 2022 ;) ) there will be something noteworthy here, so
> that we can enter 2023 with the beginnings of this real object system
> in blead, giving us enough time to shake out many of the initial bugs
> and issues so it can make its first public outing in 5.38 in May 2023.
>
> Since this set of changes is many times larger than any of the usual
> sorts of feature work that tends to go on around core perl, I think it
> would be useful to extend the usual review process. I would like to get
> some early feedback from the sorts of folks who are likely to review it
> officially when the time comes, way ahead of that time, so as to keep
> people informed and that there be no huge surprises when the real
> review happens.
>
> I have emailed you folks specifically as I feel that you are all the
> sort of people who are likely to express opinions on the code and the
> features contained therein at the time of the real PR, but may not be
> aware of the existing work or its current state. I would like to ask
> for some initial amount of looking-over and commentary and discussion
> ahead of that if possible, so as to try to avoid getting stuck in
> arguments later on. What I don't want to happen is to spend the next
> three months building on top of this and getting lots of feature work
> in time for a real review in December, only for everyone to go "no no no
> this isn't right at all" when we get there.
>
> (Other folks than these are also of course welcome to comment - I just
> singled out this list in particular because I imagined these people are
> likely fit the category.)
>
> I don't know what's a good mechanism for this. Currently the work is
> sitting on a branch in my own repo fork of Perl5:
>
> https://github.com/leonerd/perl5/tree/feature-class/
>
> and so for example github will attempt to generate a set of diffs by
>
> https://github.com/Perl/perl5/compare/blead...leonerd:perl5:feature-class
>
> Probably a fairly good place to start looking at what is involved, is
> to look over the unit tests - which all exist in their own
> subdirectory, `t/class/...`.
>
> https://github.com/leonerd/perl5/tree/feature-class/t/class
>
> There are also various "Discussion" threads about design or
> implementation details and quirks:
>
> https://github.com/leonerd/perl5/discussions
>
> I don't think that simply creating a (draft) PR at this stage would be
> helpful. This is branch is still a good couple of months away yet from
> being merge-candidate-ready, and will likely entail many many more
> commits, rebases and force-pushes before then. I don't think github's
> mechanisms will cope very well with that because of the volume of
> commentary over time that it may involve.
>
> I'm open to suggestions on what may be a good way to handle this design
> and implementation feedback, ahead of the review. I'm also open to
> being told "I have no opinions here" from individuals - though it would
> be an unfortunate outcome of the process to be told that at this stage,
> only to then receive objections later on at review time. If you have
> thoughts about the current direction, now is a far better time than
> December to air them ;)
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous