Developers of Sympa

[David Verdin <address@concealed>]

Dear all,


On 19/02/2018 11:26, IKEDA Soji wrote:
> David and all,
>
> I think Sympatic is a sort of syntax suger, syntax suger is useful
> and I'll accept anything reasonable.
Sort of indeed. The purpose is to simplify the writing of a first module 
in Sympa and enforce some best practices module usage.
> However, I don't understand how it is used. I can't neither disagree
> nor agree to what I havn't understood.  First of all, I'd like to see
> how it is used in the practical code.
Yes, I understand. I'm currently working on the Sympa::Aliases module 
and its children to try it "on the ground".
> > First: Sympatic: The idea of Sympatic is to give future developers a
> > boilerplate: include all modules that should be used wherever in Sympa.
> > So adding "use Sympatic;" includes a bunch of modules; adding "use
> > Sympatic -oo" includes the same modules plus Moo.
> At first, I also thought it is nice to gather several pragmatic
> modules into one line, but afterward, I began douting.
>
> The changes this module will bring are non-trivial: People beginning
> to read the code cannot be aware that accessor can be defined using
> "has", function using "fun" or "method", ... and especially,
> Perl builtin functions can suddenly die.  They will be aware only
> after reading Sympatic.pm and finding Moo, Function::Parameter and
> autodie.
I understand you concern. My biggest concern is about autodie. For the 
other, I think they are very useful additions, especially 
Function::Parameters.
About the necessary research to understand the code, I'm not sure that's 
such a big deal: After all, people willing to contribute have always had 
to search the code to understand, for example, how the Sympa::Log or 
Sympa::DatabaseDriver work.
But indeed, the module appears only in the first lines in the code and 
is never used afterwards. It's a kind of obfuscation. If we agree on 
this module usage, maybe we should add some kind of warning next to it 
to increase its visibility.
> To audit, read or modify the code, it seems not always true that
> hiding pragmatic modules is convenient way: People cannot touch the
> code without reading the "user manual" of Sympatic module, in
> addition to the code itself.
>
> However, common boilerplate is useful. At the moment I suppose we
> may agree to use some modules obligatorily (as all programs use
> "strict" and "warnings" pragma now).
>
> > Second: autodie. it's included in Sympatic. Using this modules will
> > raise a die whenever the code can't succeed. eiro's argument is to make
> > sure an exception will be raised whenever the code does not behave as
> > intended.
> >
> > The argument in favour of this module is the decreasing number of lines
> > to maintina to raise exceptions.
> I don't understand why lazy programmers are punished by death of
> program.  Honestly, I feel it hardly pays.
Yes, I found it hard too.
Using autodie certainly implies to have a strong exception handling 
mechanism to prevent the program from dying for wrong reasons.
Nobody should never die for wrong reasons now that I think about it. But 
that's another debate.
> Moreover, I currently understand that, to avoid this punishment,
> programmer have to write code not only checking result of function
> but also additional code preventing penalty: For example, we could
> simply write
>
>    | unless (open $fh, '<', $file) {
>    |    ...
>    | }
>
> but autodie looks requesting more.
Yes, that's a case where autodie is problematic. The lack of a file is 
not a reason good enough to die. Especially in Sympa where we do a lot 
of file manipulations.
> Possiblly I'm wrong. If there is simple way with autodie, please tell
> me. Please.
eiro has solutions about it. He shown me them but I forgot. He will 
certainly explain them in his answer.
> > The argument against it, in my opinion, is that, when reading a piece of
> > code, we won't know that an exception can be raised in that exact place.
> > I think we should maintain a minimum level of hand-made exceptions with
> > explicit exception typing to be able to handle them correctly; the idea
> > is that, in some cases, exceptions should make Sympa die, and in other
> > cases it should not.
> Currently, Sympa::Crash generates traceback and "uncaught
> exceptions" can be tracked.
Yep. that's more or less new to me even though you wrote it a long time 
ago. I'll look at it somewhere in the future.
Again, what we need is an exception handler which shows the right 
informations to the right user: user-friendly information to end-user, 
debug information to administrators ans stacktrace to developers.
Is Sympa::Crash can do it, perfect.
> On the other hand, if autodie aims to implement exception-oriented
> programing style, it is very unsatisfactory implementation, I think.
>
> I once have tried implement more with autodie. However I don't
> want to use such thing.
> See: 
> https://listes.renater.fr/sympa/arc/sympa-developpers/2013-10/msg00010.html
Re-reading this thread, I must tell that I'm quite fond of the 
"try-catch-finally"  syntax. that's how you concluded the mail.
In addition to being secure, it is a pattern that is recognized by a lot 
of people even non-Perl programmers.

More in my answer to Racke.

Cheers!

David
> > What is your opinion on this?
> >
> > Regards,
> >
> > David
> >
> > --
> > "Mieux vaut viser la perfection et la rater que viser la médiocrité et 
> > l'atteindre."
> > - Francis Blanche

--
"Mieux vaut viser la perfection et la rater que viser la médiocrité et 
l'atteindre."
- Francis Blanche

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature