Newsgroups: comp.lang.eiffel
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!stanford.edu!leland.Stanford.EDU!leland.Stanford.EDU!craig
From: craig@leland.Stanford.EDU (Craig Chambers)
Subject: Re: Old confusion
Message-ID: <1991May30.195846.16916@leland.Stanford.EDU>
Keywords: old, ensure, postconditions
Sender: news@leland.Stanford.EDU (Mr News)
Reply-To: craig@self.stanford.edu
Organization: Stanford University
References: <1991May21.040742.1520@syacus.acus.oz.au> <1166@tetrauk.UUCP> <1991May23.212347.23486@leland.Stanford.EDU> <1170@tetrauk.UUCP>
Distribution: comp
Date: Thu, 30 May 91 19:58:46 GMT
Lines: 21

In article <1170@tetrauk.UUCP>, rick@tetrauk.UUCP (Rick Jones) writes:
|> ... However,
|> there is a whole category of functions which are essential and do change the
|> state of the whole system, if not directly the state of the object on which
|> they are called.  These are functions which create and return new objects.  An
|> example is a user interface, where some class contains a function to generate
|> and return a new window.  Part of the operation is to add the new window to the
|> current display tree, so the total state is changed.  (You can't always do this
|> conveniently using direct calls to "Create", for various reasons.)

Sounds like this is very much in conflict with the rules suggested in
OOSC.  According to them, you should be able to call a function many
times over idempotently, and include them in assertions that may or
may not execute.   If your function adds a window to the screen, this
clearly is not going to follow the "rules" for functions.

I guess the answer to my original question seems to be that people
agree with the OOSC style rules when they work, but feel free to craft
other solutions when the style isn't practical.

-- Craig Chambers