develooper Front page | perl.perl5.porters | Postings from July 2020

Re: On actually implementing core features [was: Re: Dual-life perl5-or-7 code and prototypes - impossible?]

Thread Previous | Thread Next
From:
Branislav Zahradník
Date:
July 4, 2020 10:14
Subject:
Re: On actually implementing core features [was: Re: Dual-life perl5-or-7 code and prototypes - impossible?]
Message ID:
CAB=rbOmzWE=qFi_B4rHb482X2kKcNkxBmegm_UhHnstBueAuZA@mail.gmail.com
On Thu, 2 Jul 2020 at 20:38, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Thu, 2 Jul 2020 13:03:37 -0400
> Chris Prather <chris@prather.org> wrote:
>
> > If the Perl community has taught me anything it's consensus building
> > takes *way* longer than 3-5 years. Moose is now 14 years old and
> > based on the conversations around Cor there is still not a full
> > consensus about the need for a core object system beyond bless(), and
> > we're just barely (say the last 3-5 years) into a majority consensus
> > that Moose is probably a reasonably good idea as long as you remove
> > about 50% of it, without a real agreement on which 50% should be
> > removed.
>
> I'm not sure that's really true these days. I think most of the core
> folks are relatively clear on the fact that several things are missing:
>
>  * try/catch
>  * proper exceptions to go along with theabove
>  * an object and class system
>  * a better thing than given/when/smartmatch
>
> Up until now there has been much talk and very little real activity.
> People sometimes come along and suggest an idea or so, but very few
> concrete implementations of real code ever turn up. I know because
> until quite recently I have been very guilty of this - I'll suggest
> "Hey, it would be great if ..." and nobody objects, but then nothing
> ever happens. You can't just suggest a feature and expect that "someone
> else" will implement it.
>
>
> Midway through 5.31.x I was given a commit bit, and took it upon myself
> to add the `isa` feature, as I saw it was a) necessary and b) a gateway
> to gaining quite a few of the above features. All of them, in fact.
>
> It is very much my intention to keep going; through 5.33.x I hope to
> address some of the above - at the very least, arriving at having a
> properly stable try/catch syntax, in core, by the time a 5.34 would be
> released (summertime next year). I don't think it's realistic to aim at
> having the object system in by then, but provided nothing too major
> ends up getting in my way, I would expect that within a year's time you
> could
>
>   use feature 'try';
>
>   try {
>     foo();
>   }
>   catch ($e isa My::App::Exception) {
>

To be honest, as long as there are roles, usage of isa is not clean yet.
- similar java operator instanceof behaves the same for classes and
interfaces, why not here?
- how to catch $e with a parameterized role?
- how to resolve multiple inheritance ?
- in what order catches will be executed?

imagine:
exception X;
exception X::Y extends X;
catch ($e isa X) { ... }
catch ($e isa X::Y) { ... }

And this concerns only simple OOP matching.

I'd suggest delivering this feature in multiple steps:
1. lexical CATCH { BLOCK }
- will be consistent with your other plan - lexical LEAVE
- will add good enough value on its own
- still maintain try module but using this feature

2a. design data pattern language
there is a long discussion (and none usable result) about it since smart
match operator was introduced.
IMHO this should include first class class literals as well.

2b. CATCH should handle any kind of asynchronous events, including
- signals
- warnings
- core events (eg: there is a thread to join)
- custom asynchronous events (eg: file has data to read, file can be
written to, HTTP request succeeded, ...)

3. extend lexical CATCH using data pattern language
- issue to solve: evaluation priority in case exception matches multiple
patterns along with  unreachable code detection



>     say "Oopsie, you did ", $e->detail;
>   }
>   catch ($e) {
>     say "Oopsie, something went bad: $e";
>   }
>
> and maybe also
>
>   use feature 'match';
>
>   match(bar()->colour : eq) {
>     case ("red") {
>       say "It was red";
>     }
>     case ("green", "blue") {
>       say "It was green or blue";
>     }
>     default {
>       say "It was some other colour";
>     }
>   }
>
> --
> 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 | 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