From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,35d52809fb2aac8f
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!postnews.google.com!26g2000hsk.googlegroups.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Naming convention to identify functions with side effects
Date: Mon, 29 Sep 2008 14:10:01 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <2ed64106-52ef-4909-a0f0-ebb277856e8d@26g2000hsk.googlegroups.com>
References: 
 <5654ee5f-aa9f-4fff-87e0-45854b850f26@y38g2000hsy.googlegroups.com>
	<29ac62e1-78da-4048-ad95-8f88a29f7d31@z6g2000pre.googlegroups.com>
	<h9civa1o39f6$.79cdhcp3sfms$.dlg@40tude.net>
 <48e13f14$0$6610$9b4e6d93@newsspool3.arcor-online.net>
NNTP-Posting-Host: 66.126.103.122
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: posting.google.com 1222722601 13754 127.0.0.1 (29 Sep 2008 21:10:01
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 29 Sep 2008 21:10:01 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: 26g2000hsk.googlegroups.com; posting-host=66.126.103.122;
	posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12)
	Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:2146
Date: 2008-09-29T14:10:01-07:00
List-Id: <comp.lang.ada>

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