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:
Paul "LeoNerd" Evans
Date:
July 4, 2020 11:27
Subject:
Re: On actually implementing core features [was: Re: Dual-life perl5-or-7 code and prototypes - impossible?]
Message ID:
20200704122712.1d863c7a@shy.leonerd.org.uk
On Sat, 4 Jul 2020 12:14:15 +0200
Branislav Zahradník <happy.barney@gmail.com> wrote:

> >   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?

One reason the `isa` is still experimental (other than being so new) is
that there still needs to be a corresponding `does` operator to perform
the role check via the ->DOES method.

> - how to catch $e with a parameterized role?

There isn't the concept of a parameterized role anywhere else in Perl
currently, so this isn't a question that is meaningful.

> - 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.

Multiple catch blocks, as for dumbmatch, simply perform their tests in
lexical order. If you want a particular case to take precedence over
another case, move it higher up in the source code. This is by far the
simplest to implement, to understand, and to explain to users.

It also makes it feel similar to the test order in the traditional
if/elsif/.../else style of code.

> 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

I still majorly dislike the idea of a `CATCH` block, because its mere
presence inside the parent block changes the semantics of that block,
even at lines before it appears. This isn't the case with `LEAVE` or
any of the other existing phaser blocks in perl; which only observe at
a particular moment in time but do not otherwise alter it.

Restated: `LEAVE` is fine as a passive observer simply sitting as a
sibling block to other code. But the interruption of control flow
implied by `catch`-like behaviour is sufficiently surprising that it's
good to warn the (human) reader of the code by the presence of the
`try` block to contain it. The `try` part of `try/catch` syntax exists
primarily for the benefit of the human programmer, not the perl
interpreter.

-- 
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