Re: Naming convention to identify functions with side effects

[Adam Beneschan <adam@irvine.com>]

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;

Separating the procedure call and the query sounds like a great idea
theoretically, but it does mean that things such as the above must be
made more verbose (e.g. by adding a Boolean variable, as below:)

   if URL_Name = null then
      Success := False;
   else
      Web_Page.Load (URL_Name.all);
      Success := Web_Page.Is_Loaded;
   end if;
   if Success then ...

So, right or wrong, at least one can understand the temptation to
writing a Boolean function in order to make its use more concise in
such cases.

                                -- Adam