Re: Naming convention to identify functions with side effects

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

Adam Beneschan schrieb:
> On Sep 29, 1:48 pm, Georg Bauhaus <see.reply...@maps.futureapps.de>
> wrote:
> 
>> Again, it might be tempting to pack the two calls in just
>> one in order to hide the locking mechanism, to give the
>> illusion of atomicity. But shouldn't normal Ada
>> concurrency features be employed instead?
> 
> This is a bit too esoteric for me.  I think a much simpler reason for
> the temptation to pack the two calls into just one is that it makes it
> easier to stick the call into more complex Boolean expressions, e.g.
> (assuming URL_Name's type is access string):
> 
>    if URL_Name /= null and then
>       Load_Web_Page (URL_Name.all) then ...
>       [stuff to do if we succeed]
>    else ...
>       [other stuff]
>    end if;

This solution looks like a straight forward one at least in
case of a single additional test in the conditional.
However, as soon as the URL needs a little more inspection,
I need more predicates. Since these are called before Load_Web_Page
is called, Load_Web_Page is "pushed down" the conditional chain,
hiding it and also blurring the distinct sources of error:

   if URL_Name /= null and then
      Valid_Protocol (URL_Name.all) and then
      Host_Allowed (URL_Name.all) and then
      No_Up_Directories (URL_Name.all) and then
      Load_Web_Page (URL_Name.all)
   then ...
      [stuff to do if all test succeed and the page was finally loaded]
   else ...
      [something has failed, maybe loading has failed, do other stuff]
   end if;

So, first, Load_Web_Page, which presumably has the important side
effect of initializing some variable, looses the focus
of attention.

Then, sources of error may need to be distinguished since
the errors are different in character (null pointer, syntax,
and I/O). Load_Web_Page (I/O), being appended to the list
of predicates and the null test, becomes one of many
sources of potential failure in the same conditional.

Finally, the programmer wanting to reduce verbosity by
making Load_Web_Page a Boolean function now causes
verbosity by chaining the many predicates.
This amount by far exceeds the intended reduction in verbosity
and renders the original intent (of saving words) mostly
fruitless.

So the distinct issues become blurred in this single
conditional and the Boolean function Load_Web_Page does
not significantly reduce verbosity.

At this point I remember advice from The Little Schemer
to use little helper functions (that can be nested if
needed). Thus,

   if Is_Acceptable (URL_Name.all) then
      Load_Web_Page (URL_Name.all, Data);
      Construct (Data, Result);
   else
      raise Syntax_Error;
   end if;

(where URL_Name is of subtype "not null String_Ptr")
Stupid obedience to command-query separation like in
Is_Acceptable and Load_Web_Page might pay off in the end.
Not that anyone cares.