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

Re: Preview reviews / comments on feature-class branch

Thread Previous
Elvin Aslanov
September 27, 2022 17:26
Re: Preview reviews / comments on feature-class branch
Message ID:
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.

On Tue, Sep 27, 2022 at 9:12 PM Paul "LeoNerd" Evans
<> 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:
> and so for example github will attempt to generate a set of diffs by
> 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/...`.
> There are also various "Discussion" threads about design or
> implementation details and quirks:
> 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
>      |
>  |

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