Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!mstr!mstr!jcm
From: jcm@mstr.hgc.edu (James McKim)
Newsgroups: comp.lang.eiffel
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <1991Jun5.144629.5030@mstr.hgc.edu>
Date: 5 Jun 91 14:46:29 GMT
References: <1991May30.141218.3446@mstr.hgc.edu> <130242@tut.cis.ohio-state.edu>
Sender: Usenet@mstr.hgc.edu (Action News Central)
Reply-To: jcm@mstr.hgc.edu (James McKim)
Organization: The Hartford Graduate Center, Hartford CT.
Lines: 75
Nntp-Posting-Host: sc3.hgc.edu

In article <130242@tut.cis.ohio-state.edu> ogden@seal.cis.ohio-state.edu (William F Ogden) writes:
>
>There are a number of considerations that bear upon this issue, but
>comprehensibility and efficiency are probably the most important.
>
>Functions enjoy a prominent position in twentieth century mathematics, and
>thus in the educational background of most software professionals. It
>makes sense to exploit this shared knowledge when designing software.
>Now the principle feature of functions is that they can be composed
>into arbitrarily large expressions. If you don't anticipate clients
>forming expressions, then functions offer no particular advantage
>over procedures as class operations.
>
>The answer to the question of whether functions should have side-effects
>which are visible at the client level is clear when you observe that
>side-effects will make the value of experessions dependent upon the
>order of evaluation of subexpressions, and hence quite unapparent.
>
>On the other hand, side-effects which only affect the internal representationsof objects (such as changing the shape of a tree being used to realize a set)should be permitted for efficiency reasons.
>
Well said! I obviously agree.

>The pop/top discussion raises an important efficiency issue in class
>design. While we now give lip service to object-oriented design, we
>often fail to recognize some of the consequences of what we're advocating.
>If the object based software thesis is correct, then our software will be
>organized around increasingly large and sophisticated objects, yet when
>we design things like stacks, we persist in thinking of the objects
>being stored in stacks as being small objects like integers. Instead,
>we should recognize that the really serious uses of stacks will involve
>storing large objects ( sets, polygons, other stacks, etc. ), and that
>to achieve real reusability, our stack operations should be chosen with
>an eye to making them efficient for storing large objects.
>
>Probably the most significant feature of large objects, as opposed to
>small objects like integers, is that they are usually quite expensive (if
>not impossible) to replicate. Consequently operations like Top make poor
>choices as primary operations, since their implementation inevitably
>involves making a copy of a data structure entry. The proper choice
>of primary operation for the stack then is the procedure (not function
>-- see above) Pop which does return the top value, since this does not
>entail replicating an entry. Top can be provided as a secondary operation,
>but clients should be warned that it is potentially an expensive operation.
>
Now I'm confused. The first part of your post argues that functions
should, in general, not have side effects that change the visible state
of an object. The second part argues that procedures, which do change
the state, should often have return values. Are you making a distinction
between functions with side effects and procedures with return values?

I also must question the premise of the second part of your argument.
Most of the OO data structure classes I have seen use referential
semantics, so a function like Top does not necessarily involve any
replication beyond that of a pointer. But even if I agree that such
replication _should_ be the norm I would argue for Top as a side
effect free function and Pop as a return free (to coin a phrase)
procedure on the basis of comprehensibility. If a particular application
requires the efficiency of a Pop_Top then extend the class, possibly
via inheritance to include it, but don't include it as a matter of
course. All such features make the class harder to understand, and
if done as a matter of course there will be _lots_ of them. All the
efficiency in the world won't help if users, maintainers, implementers
cannot understand the class.
>--
>
>/Bill

Interesting thread!
-- Jim



*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458   _Give_ people fish and they eat for a day.  
Internet:  jcm@mstr.hgc.edu _Teach_ people to fish and they eat for a lifetime.