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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: dnew@zloty.fv.com (Darren New) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/11 Message-ID: <5v9bnn$jbb@newshub.atmnet.net>#1/1 X-Deja-AN: 271678084 References: <5v1gua$fkk@newshub.atmnet.net> <5v4g00$pjr@wdl1.wdl.lmco.com> <5v6mml$jac@newshub.atmnet.net> <341787a6.0@news.uni-ulm.de> Organization: FIRST VIRTUAL Holdings Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-11T00:00:00+00:00 List-Id: In article <341787a6.0@news.uni-ulm.de>, Joerg Rodemann wrote: > >Darren New (dnew@zloty.fv.com) wrote: >> Not at all. You still have the advantage that the specification is "in >> your face" while you're editing the implementation, and hence less is >> likely to get overlooked. You also have the advantage of not needing >> to do that for small projects, or for helper modules that are private >> to a single other module. You still have *all* the advantages. > >Well, you really must have huge screens...I myself prefer having to editor >windows: one for the spec and one for the body. But that's because *your* spec and body are separate, don't you see? Having the spec and body intermingled so the bits of the spec relevant to the bits of the body it's specifying are next to each other makes it unnecessary to have "huge screens". If your average body is maybe ten lines long, and your spec is maybe five lines long, and they're always next to each other, why do you need a big screen? > Otherwise those things >that are currently interesting to me always happen to have just scrolled >out of view. Heck, emacs handles this on a VT100. > And one thing with Java I do not like at all ist this: you >need to search the complete (and often long) file for getting an idea >what methods, variables the class contains. I'd hav to write an extraction >tool of my own and unfortunately I have no time for that right now. Ummmm, surely you've heard of Javadoc? It's free, ya know, and it comes with Java. >So, I do believe that you Eiffel programmers use a similar approach: normal >view to the complete text and an overview by short-flat forms. (Strange >word... :-) ) Thus your argument does not hold at all. Right. But when you're viewing the complete text, you're viewing the spec *and* the implementation, and when you're viewing the "overview" you're viewing the spec by itself. I'm confused about why you seem to think this obviates my argument that when you're editing the body it's easy to see the relevant parts of the spec. >How are you migrating a small project to a big one, when your team decides >the tool/class you wrote is suitable? Or if it simply keeps growing? We hand it to the customer and say "Here, this is what you paid for." ;-) Seriously, I don't know what you're asking. --Darren