From: jjh@evb.com (John Halper)
Subject: Re: ADA question
Organization: EVB Software Engineering, Inc.
Date: Mon, 31 Aug 1992 21:14:50 GMT

*In article <1992Aug27.102951.8681@news.uni-stuttgart.de>, ucaa2385@ruscvx.rus.uni-stuttgart.de (Peter Hermann) writes:
*|> In article <1992Aug27.004228.19551@evb.com> jjh@evb.com (John Halper) writes:
*|> >Daljeet writes:
*|> >>I have a function in a package A which returns string. I am using
*|> >>that function in another package B and try to give the value returned
*|> >>by that function to a variable (which has been declared in package B).
*|> >>The variable is of type string (1 .. max) initialised to empty string.
*|> >
*|> >I don't like making the call twice, and would rather use one of first two 
*|> >solutions, but ...
*|> 
*|> It is advisable to call any function only once
*|> for the same purpose, because a function result
*|>  1. may change from call to call
*|>  2. may be expensive
*|>
*
*Absolutely! Avoid this like the plague.
*



Ok, maybe I didn't explain my position adequately.  


At EVB Software Engineering, this is not a problem for the following
reasons.  

1) Functions that return strings, other unconstrained arrays, or even limited
   types are created under the rarest of circumstances. I would say never created
   but the word 'never' is more black and white than most of the rest of reality.
   Anybody know of a case requiring a function that returns one of these types?
   So (IMHO), the "correct" solution is to rewrite the function as a procedure.

2) At EVB, all development is done using an OO method which identifies 
   operations as selectors, constructors or iterators ala Booch.  Selectors
   almost always map to functions and by definition don't change the state of 
   the associated object.  Therefore, other than selectors on an object
   with life (life meaning the ability of an object to change it's own state),
   selectors (functions) will always return the same result as long as a 
   constructor has not been ivoked between the calls to the selector.  When a 
   task is involved we have a number of schemes for dealing with protection of
   shared data, some of which allow the double call to the selector to still 
   work correctly.  In those cases where the selector could return a different
   result, we apply #1.  I know you guys are not writing functions with 
   side effects so I assume these circumstances had been considered. Then again 
   the last time I assumed anything I got equated with a plague.     

3) As to the efficieny of making two calls.  If I ever attempted to get something
   like this through an inspection, well lets say this would consume the better 
   part of an afternoon.  We try to give equal consideration to the portability, 
   maintainability,  modifiability, reliability and efficeincy.  In this case, 
   would strive for an implementation based on a single function call? 
   See point #1.


The only reason I resonded to the original post was to show that the result of a 
function call can be used with a attribute.  Maybe I should have just said that in
the first place.


John Halper 
Software Engineer
EVB Software Engineering, Inc.
1 800 877 1815
jjh@evb.com 
-- 

John Halper
halper@evb.com
Newsgroups: comp.lang.ada