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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Loryn Jenkins Subject: Re: Which wastes more time? (Was Re: Software landmines (loops)) Date: 1998/09/05 Message-ID: <35F0C3C9.D1E56FF3@s054.aone.net.au>#1/1 X-Deja-AN: 388070158 Content-Transfer-Encoding: 7bit References: <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <6sebjr$b69$1@nnrp1.dejanews.com> <6sff74$q0s@gurney.reilly.home> <6sh2j5$jnl$1@nnrp1.dejanews.com> <35EC2E5A.16DB6CB1@bigfoot-.com> <6sjc0a$1lk$3@news.indigo.ie> <35EFB09E.15412933@s054.aone.net.au> <35f2bd98.40599408@news.erols.com> <35F06A58.F968BDE1@s054.aone.net.au> <35f48276.90997557@news.erols.com> X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii X-Trace: news.mel.aone.net.au 904971248 7719 203.12.186.163 (5 Sep 1998 04:54:08 GMT) Organization: TekRite Pty Ltd Mime-Version: 1.0 Reply-To: loryn@acm.org NNTP-Posting-Date: 5 Sep 1998 04:54:08 GMT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-05T04:54:08+00:00 List-Id: > Please be concrete. But remember that this is not a tea party. But I have never thought of newsgroups as a combat zone. Actually, why don't you think of this as a nice tea-party? All us software engineers sitting around, sipping tea, engaging each other in stories, techniques, observations, of the things that interest us. Of the things that seem to work for us. Of the things that seem to work generally. Methinks we would all be a bit kinder, if we had this conception. > It seems you have not been around for more than a few months > so it would be impossible for you know about years of on-going > practice. I lurked for over a year before posting: to get a lie of the land. I think I got a pretty good view. > It is evident in that you fail to acknowledge that the onus > for proving an assertion is on the asserter. Yes. It seemed to me that the last I read about scientific principles was: (1) support your theory with evidence (2) attempt to phrase your hypotheses so that they are disprovable (3) don't attempt to 'prove' things, so much as 'disprove' them. Thus, I feel the burden of (dis-)proof is actually on those who seek to "disprove". Anyway, whether or se/se is actually what Dijkstra was on about (actually, I think he was on about something a little bigger than se/se; se/se seems to me to be a principle that enabled him to get where he was wanting to go), it seems useful to me. Actually, what seems useful to me is to adopt a way of doing things that can work in all situations (it's a goal, anyway), so that I don't have to ponder over whether I should *really* do things this way or that way in this case. I feel this approach helps me be more productive. I'll give two examples. The first one is the routines I have been using in the examples I have produced for this thread. I don't have to ponder about whether I can get away with returning early ... I just do it in a way that has been shown to work (the effectiveness, of course, is what we're debating in this thread) in all circumstances. The second (counter) example is inspired by OOSCII, Chapter 12. In it, if I recall correctly, Bertrand has class CAR_OWNER inherit from class PERSON. (He offers this as an example of 'how to do inheritance well'.) He implies that this is acceptable modelling for an application. Now, while I can imagine this working for some applications, I can't believe it is acceptable. I can't believe it is acceptable because it does not model our concept of reality. Instead, it should have been modelled as a role of a person. That is CAR_OWNER inherits from PERSON_ROLE, and PERSON_ROLE has an attribute of type PERSON. Modelling it this way would have future-proofed the application against handling situations when people in the application became car owners and then stopped being car owners. Even if it was valid for an application, the second is preferable, because I don't have to scratch my head, wondering about the possible implications. Loryn Jenkins