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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public From: dnew@zloty.fv.com (Darren New) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/10 Message-ID: <5v72it$nhm@newshub.atmnet.net>#1/1 X-Deja-AN: 271398271 References: <33E9ADE9.4709@flash.net> <5utag9$o6s@newshub.atmnet.net> Organization: FIRST VIRTUAL Holdings Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: > >My point was that since changing the spec means you have to go talk to >everyone concerned anyway, I don't see the advantage of putting it in >a separate file.>> > >That's a very informal view of things, corresponding to a few people working >together without any kind of formal CM. In such an environment, word of >mouth can substitute for many things. "Talk to" was not meant to be interpreted literally. >Instead, there must be a very clear notion of who can change a spec, under >what conditions, and following what procedures, and these rules must be >embodied into the CM system, and will be quite different for specs and >bodies. Agreed. >Yes, one can always imagine a CM system that is highly knowledgable about >the particular language you are using, and does all kinds of amazing things, >but in my experience, such speculations tend to be more in the category of >wishful thinking than in real use. Perhaps it's because people using Eiffel don't want to give away their secrets? Anyway, as I've pointed out, it *is* fairly trivial to make CVS do this. It's not worth my time to do it just to convince you it's possible. :-) No offense intended. >By separating the spec into a a file of its own, a CM system that is file >based can provide many of the required procedures WITHOUT particularly >being language knowledgeable. And a file system based on punched cards cannot. That doesn't tell you much about the language. >It is remarkable to me that *no one* has responded to my request for actual >experiences in using Eiffel in such CM systems. Well, ISE obviously uses RCS for their revision control. I would think ISE would want to know when they're accidentally changing the specs of the kernel library. >Darrien says he disagrees with the rationale, but is this based on >experience? Darrien, have you worked with large Ada systems organized >in this manner? My experience is that virtually all of those who have >find this to be one of the really important advantages of Ada. No, I haven't. I've been on several fairly large projects, but probably none you would consider large. In every case where we were using a language that separated specs and bodies, the rule was that the spec was automatically generated from the body. >I often find that people who have never used a language feature don't >understand its utility. I understand the utility. Perhaps if I was trying to organize a 1000-person development effort with unenhanced CVS, I'd think the benefits outweigh the problems. However, that hasn't been my experience. *That* is what I meant by "I understand the rationale but disagree". Nuff said. I see little I can add to this thread. --Darren