* Re: Design by Contract [not found] ` <EFM1Lx.GD2@syd.csa.com.au> @ 1997-08-28 0:00 ` Robert Dewar 0 siblings, 0 replies; 65+ messages in thread From: Robert Dewar @ 1997-08-28 0:00 UTC (permalink / raw) <<Sorry about that. I can't help thinking, however, that you object more to the *content* rather than the volume of what was quoted.>> No, he is probably reacting to the fact that due to some unwise cross posting by someone back in the depths of time, other groups are being subjected to furious Eiffel advocacy, that no doubt is at home on comp.lang.eiffel (remind me not to visit), but is even by comp.lang.ada standards a bit strident :-) :-) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Critique of Ariane 5 paper (finally!) @ 1997-08-21 0:00 aek [not found] ` <33FC66AD.9A0799D4@calfp.co.uk> 0 siblings, 1 reply; 65+ messages in thread From: aek @ 1997-08-21 0:00 UTC (permalink / raw) In <dewar.872088939@merv> dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >In this particular case, the very reasonable point that DBC may be a useful >tool in helping to achieve reliability in some circumstances ^^^^^^^^^^^^^^^^^^^^^ This is the point. When one claims that some new method or tool may be useful in some circumstances he seems to be obliged to describe those circumstances more or less precisely. But if one claims that this new method or tool is very useful universally then he frees himself from this trouble and invites other people to do this job. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia \x1a -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <33FC66AD.9A0799D4@calfp.co.uk>]
[parent not found: <33FFA4B1.3543@flash.net>]
* Re: Critique of Ariane 5 paper (finally!) [not found] ` <33FFA4B1.3543@flash.net> @ 1997-08-26 0:00 ` Nick Leaton [not found] ` <3403940F.4154@pseserv3.fw.hac.com> 0 siblings, 1 reply; 65+ messages in thread From: Nick Leaton @ 1997-08-26 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 8512 bytes --] Ken Garlington wrote: > > Nick Leaton wrote: > > > > Let us say for the moment that in some circumstances DBC helps. > > For those that have been critising DBC, since DBC is optional, and is an > > addition to the current methodology I think the only valid criticism one > > make, is if you can find a situation where DBC causes a problem. > > > > That is, where does DBC screw up, and the current methodologies do not. > > See my Ariane paper for some examples of such information: > > http://www.flash.net/~kennieg/ariane.html#s3.1.6 QUOTE ----------------------------------------------------------- 3.1.6 Adverse effects of documenting assertions There is a line of reasoning that says, "Even if DBC/assertions would have been of minimal use, why not include them anyway just in case they do some good?" Such a statement assumes there are no adverse impacts to including assertions in code for documentation purposes. However, there are always adverse effects to including additional code: As with any other project, there are management pressures to meet cost and schedule drivers. Additional effort, therefore, is discouraged unless justified. More importantly, all projects have finite time and other resources available. Time spent on writing and analyzing assertions is time not spent elsewhere. If the work that is not performed as a result would have been more valuable (in terms of its effect on the safety and integrity of the system) than the time spent with assertions, then the resulting system may be less safe. There is a growing consensus in the safety-critical software field that simpler software tends to be safer software [21]. With this philosophy, additional code such as assertions should only be added where there is a clear benefit to the overall safety of the particular system being developed. END QUOTE -------------------------------------------------------- 1) Additional effort. There is plenty of evidence that the cost of finding and fixing a bug early in the development process is much cheaper that fixing it later. Now *IF* DBC as a methodology produces earlier detection of faults, then this 'additional effort' is justified, as it is effort early in the development process. I believe this to be the case from practical experience. Developing code last week I detected errors in my code very early, even though the fault would have only shown itself in an exception. I had an invariant that made sure I had an error handler in a class. It broke as soon as I tried to construct the class, it didn't wait until I tried to generate an error, all because I hadn't set the handler up. That combined with permantant testing of assertions has the effect of producing less effort. 2) Time spent else where. Is this the case? Some of it may be, but I believe if you cannot be rigourous about what your software is trying to do, by writing assertions, then you are unlikely to produce a quality system. The effect of writing assertions overlaps with the design process. It is not wasted time, it just comes under a different heading. If your design process listed the assertions in the specification, would implementing them be a waste of effort? 3) Simple software. You bet. The simpler the better. Occams Razor rules. Now here there is a split between DBC a la Eiffel and DBC, say in C++. In Eiffel it is simple. In C++ it is hard, particularly with inheritance of assertions. One common theme from Eiffel practitioners is their support for DBC. Why? They are simple to write. Prior to using Eiffel I had read about the language. I was extremely sceptical about assertions because in my experience with C++ and C++ programmers, no one writes them, mainly because it is hassle. Take away the hassle and people will write them because of the benefits. > http://www.flash.net/~kennieg/ariane.html#s3.2.2 QUOTE -------------------------------------------------------- 3.2.2 Adverse effects of testing with assertions Assume for a moment that the proper testing environment and data had been available. Putting aside for the moment the question as to whether assertions would have been necessary to detect the fault (see section 4.2), are there any disadvantages to using assertions during testing, then disabling them for the operational system? In the author's experience, there are some concerns about using this approach for safety-critical systems: The addition of code at the object level obviously affects the time it takes for an object to complete execution. Particularly for real-time systems (such as the Ariane IRS), differences in timing between the system being tested and the operational system may cause timing faults, such as race conditions or deadlock, to go undetected. Such timing faults are serious failures in real-time systems, and a test which is hindered from detected them loses some of its effectiveness. In addition, the differences in object code between the tested and operational systems raise the issue of errors in the object code for the operational system. Such errors are most likely to occur due to an error in the compilation environment, although it is possible that other factors, such as human error (e.g. specifying the wrong version of a file when the code is recompiled) can be involved. For example, the author has documented cases where Ada compilers generate the correct code when exceptions are not suppressed, but generate incorrect code (beyond the language's definition of "erroneous") when they are suppressed. This is not entirely unexpected; given the number of user-selectable options present with most compilation environments, it is difficult if not impossible to perform adequate toolset testing over all combinations of options. Nothing in the Eiffel paper indicates that Eiffel compilers are any better (or worse) than other compilers in this area. Although this is a fault of the implementation, not the language or methodology, it is nonetheless a practical limitation for safety-critical systems, where one object code error can have devastating results. One possible approach to resolving this issue is to completely test the system twice; once with assertions on and another time with assertions suppressed. However, the adverse factors described in section 3.1.6 then come into play: By adding to the test time in this manner, other useful test techniques (which might have greater value) are not performed. Generally, it is difficult to completely test such systems once, never mind twice! This effect is worse for safety-critical systems that perform object-code branch coverage testing, since this testing is completely invalidated when the object code changes [25]. Overall, there are significant limitations to using this technique for safety-critical systems, and in particular real-time systems such as the Ariane 5 IRS. END QUOTE -------------------------------------------------------- Assertions affect timing in safety critical systems. Firstly it depends on the implementation. It is easy to envisage a system where the assertions are redundantly executed. But you would only want to do that if you were running with faulty software ?!*^�% I also find it worrying that systems are being used for safety critical apps where there is the possibility of a race or deadlock to occur. Compilation problems. These can occur in any system as you are aware. From discussions with some of the people involved in writting Eiffel compilers, the enabling, disabling of assertions has a very trivial implementation, which is very unlikely to go wrong. It has also be extensively tested in the field by end users. Do you trust your compiler? If not, you shouldn't be writing safety critical software with it. Period. Next I find some of the logic of your arguments here very weak. Paraphrasing. We have trouble testing safety critical systems, but we will use them anyway. Hmmm. > http://www.flash.net/~kennieg/ariane.html#s3.3 > > There are approaches that can avoid such costs, particularly those of > 3.2.2 and 3.3 (by not requiring object code modification). 3.1.6 can > be mitigated through the use of techniques that minimize cost (e.g. > automated structural testing analysis). > > > > > -- > > > > Nick -- Nick ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <3403940F.4154@pseserv3.fw.hac.com>]
* Re: Design By Contract [not found] ` <3403940F.4154@pseserv3.fw.hac.com> @ 1997-08-27 0:00 ` Ted Velkoff [not found] ` <5u3c6v$gtf$2@miranda.gmrc.gecm.com> [not found] ` <JSA.97Aug27180328@alexandria.organon.com> [not found] ` <EFM140.Fy9@syd.csa.com.au> [not found] ` <349224633wnr@eiffel.demon.co.uk> 2 siblings, 2 replies; 65+ messages in thread From: Ted Velkoff @ 1997-08-27 0:00 UTC (permalink / raw) W. Wesley Groleau x4923 wrote: > > Question for anyone who _really_ knows both Eiffel and Ada: > Suppose Ada added Eiffel assertions and Eiffel added separate > compilation of specs. Or even some sort of automated control that > prevented changing contract without special privilege. > > What remaining feature of either language (or both) would be a > significant advantage over the other and why? > In no particular order I offer my view of the remaining differences. To the best of my ability I've responded with reason and judgement :-) Concurrency. Ada's tasking is certainly more mature and tested in fielded products. There has been a lot of research done into concurrency in Ada that benefited Ada95. I personally find the SCOOP approach to concurrency proposed for Eiffel to be quite elegant from the standpoint of the ordinary programmer building a concurrent system. I think the jury's still out on how well it can be implemented. There are some important issues (like priority inversion, rate-monotonic scheduling, etc., among many others) that need to be addressed in order to be applied to the some of the kinds of systems that have been done in Ada. Constrained genericity. Constrained genericity is achieved in Ada typically by adding generic function or procedure parameters to the parameter list. Depending on the generic type, that list of parameters could be long. I think the Eiffel approach, which says an actual parameter must conform to (i.e. inherit from) some class, is simple and powerful, and typically results in shorter parameter lists. Multiple inheritance. I've read the section on multiple inheritance in the Ada95 Rationale several times and I confess I have never been able to understand the 2nd or 3rd examples. At the very least, it appears that just emulating multiple inheritance in Ada95 is hard. Of course the religious question is whether you believe in MI or not. After not being sure for about a year, I've come to believe it is extremely useful. I think Bertrand Meyer is correct in saying that MI is not bad as long as it is implemented properly. Using MI in Eiffel is really just no big deal. Dynamic binding. Someone please correct me if I'm wrong on this one, but I think in Ada95, the programmer has to designate whether dynamic binding can be applied by making a type "classwide" with 'Class. I think this is comparable to C++ "virtual", but I think I read that the Ada compiler is supposed to figure out which classwide calls are actually static in an executable. The chief objection (if I have understood the Ada mechanism correctly) might be that one might forget to make a type classwide that a descendant would need to override, and require a change to the code. In Eiffel, dynamic binding is the default. The programmer has to do something special ("frozen") to make it impossible for descendants to redefine. Garbage collection. There are many applications being done in Ada for which garbage collection is not appropriate (hard real-time, etc.). I suspect that there are many more applications being done in Ada that could benefit from garbage collection. Eiffel is of course garbage collected. There are also library facilities for fine-grained control during execution. Exception handling. Ada is fairly permissive with exceptions. (Meyer has written about this in several places.) The bad things that I have done and seen done in Ada are to use exceptions as gotos, and sweep problems under the rug. Eiffel is much more restrictive about what can be done in response to exceptions. It significantly reduces the chances of programmers doing these sorts of things. Tool environments. Articles have appeared in Ada Letters that questioned the wisdom of incorporating inheritance into Ada95, based on the fact that comprehension of a class interface requires manually finding and traversing the set of ancestors. This problem is of course not unique to Ada. As far as I know, Eiffel environments are the only I know of that support class flattening (i.e. generating the union of all features of all ancestors). They also support push-button access to the list of clients, suppliers, ancestors, descendants. I don't know how many times in other languages (including Ada) I have really needed to find out "who's calling this?" and had nothing better at my disposal than grep. Of course these are not language issues - I'd love to see vendors of Ada products add these kinds of capabilities. Child packages. At a minimum, the rules about child packages are complicated. I'm personally unconvinced by the examples in the Ada95 Rationale for their use. In particular, the example of complex numbers seems to be more properly addressed by inheritance (i.e. tagged types). I would worry that programmers using that as a guide would attempt to solve many problems with child packages that should use inheritance instead. Pointers to functions, aliases. I sort of got the heeby-jeebies when I saw these introduced into Ada95. They didn't appear any easier or safer to use than their counterparts in C/C++. In Ada83, you could sort of see the argument for subprogram pointers, but once inheritance and abstract subprograms were introduced, they seemed out of context to me. Eiffel doesn't have these things since they are tricky to use and jeopardize reliability. -- Ted Velkoff ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <5u3c6v$gtf$2@miranda.gmrc.gecm.com>]
* Re: Design By Contract [not found] ` <5u3c6v$gtf$2@miranda.gmrc.gecm.com> @ 1997-08-28 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Joachim Durchholz [not found] ` <34058808.3BF@pseserv3.fw.hac.com> 1 sibling, 1 reply; 65+ messages in thread From: Patrick Doyle @ 1997-08-28 0:00 UTC (permalink / raw) In article <5u3c6v$gtf$2@miranda.gmrc.gecm.com>, Paul Johnson <paul.johnson@gecm.com> wrote: >In article <3403C44F.2424@erols.com>, velkoff@erols.com says... > >[In the middle of an otherwise good posting] > >> In Eiffel, dynamic binding is the default. The programmer has >>to do something special ("frozen") to make it impossible for descendants >>to redefine. > >I've seen this mistake made a few times around the net. The assumption is >that "frozen" was introduced as a sort of "anti-virtual", or at least that >it has this effect. [Discussion of difference between dynamicity and redefinability] >The correct answer is "2". The dynamic binding still happens. The only >effect of "frozen" is that if I create a new descendant of "B", I cannot >redefine "foo" in it. > >Dynamic binding and "frozen" are orthogonal issues. Now, have a look at the quote you took, and tell me how it contradicts this. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-08-28 0:00 ` Patrick Doyle @ 1997-09-06 0:00 ` Joachim Durchholz 1997-09-06 0:00 ` Patrick Doyle 0 siblings, 1 reply; 65+ messages in thread From: Joachim Durchholz @ 1997-09-06 0:00 UTC (permalink / raw) Patrick Doyle wrote: > >Dynamic binding and "frozen" are orthogonal issues. > > Now, have a look at the quote you took, and tell me how it > contradicts this. Nonvirtual C++ functions and frozen Eiffel routines are not the same. 1) Even a frozen routine can be polymorphic - it may itself override an inherited routine. (This is not an issue for the frozen features declared in ANY, PLATFORM or GENERAL.) 2) There is no way in Eiffel to achieve the effect of C++ nonvirtual member functions. If you have a routine blah (x: A_CLASS) is do x.do_something end the standard C++ policy (nonvirtual routine) would be to always call A_CLASS.do_something, regardless of wether the parameter passed in for x is of that type or of a descendant. In Eiffel, the decision which routine to call will always be based on the run-time type of x, *never* on the declared type along. (Of course, if do_something is frozen in A_CLASS, no polymorphism is possible, so the compiler should optimize this to a static call. But that's the same as when the compiler determines that only A_CLASS objects will be passed for x in the given program.) Regards, Joachim -- Please don't send unsolicited ads. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-06 0:00 ` Joachim Durchholz @ 1997-09-06 0:00 ` Patrick Doyle 0 siblings, 0 replies; 65+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) In article <34108452.BAF03BA5@munich.netsurf.de>, Joachim Durchholz <joachim.durchholz@munich.netsurf.de> wrote: >Patrick Doyle wrote: >> >Dynamic binding and "frozen" are orthogonal issues. >> >> Now, have a look at the quote you took, and tell me how it >> contradicts this. > >Nonvirtual C++ functions and frozen Eiffel routines are not the same. I don't disagree with this. My point is that what you quoted did not claim they were the same. However, you've removed the quote and my mail reader no longer has the original, so I can't explain further. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <34058808.3BF@pseserv3.fw.hac.com>]
* Re: Design By Contract [not found] ` <34058808.3BF@pseserv3.fw.hac.com> @ 1997-08-28 0:00 ` Darren New 0 siblings, 0 replies; 65+ messages in thread From: Darren New @ 1997-08-28 0:00 UTC (permalink / raw) In article <34058808.3BF@pseserv3.fw.hac.com>, W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote: >Paul Johnson wrote: >> Now in my code I have something like: >> >> a: A; >> b: B; > >Is this legal Eiffel? If so, put case insensitivity on the list of >Ada's advantages. > >Unless Eiffel demands upper case for types/classes and lower case >for variables/constants. In that case, it's even, i.e., the >distinction introduces some benefits but also some problems. Uh, no. That's not the point. In Eiffel, there's certain syntactic places the name of a class can appear, and certain syntactic places the name of a variable can appear, and the two don't overlap. Hence, the case distinction is irrelevant. This is like saying in C struct x { struct x * next; int data; } struct x next; [...] next = next->next; Now, granted, in this case it's probably bad style, but there's no confusion that the first two "next" references are to the variable and the third is to the structure member. Same idea in the Eiffel code. ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <JSA.97Aug27180328@alexandria.organon.com>]
* Re: Design By Contract [not found] ` <JSA.97Aug27180328@alexandria.organon.com> @ 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-09-03 0:00 ` Don Harrison 1 sibling, 0 replies; 65+ messages in thread From: W. Wesley Groleau x4923 @ 1997-08-28 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > In article <3403C44F.2424@erols.com> Ted Velkoff <velkoff@erols.com> writes: > > > Constrained genericity. > > Constrained genericity is achieved in Ada typically by adding > > generic function or procedure parameters to the parameter list. > > Depending on the generic type, that list of parameters could be long. > > I think the Eiffel approach, which says an actual parameter must > > conform to (i.e. inherit from) some class, is simple and powerful, and > > typically results in shorter parameter lists. > > That's not quite right. The Ada approach basically subsumes the > Eiffel approach: an actual must conform/inherit from some class or you > can use an approach sort of like what you mention. Also, in the > latter case, the parameter lists can be captured in a signature > package which can then be passed as a single parameter to another > generic. > > > Of course the religious question is whether you believe in MI or > > not. > > Right. > > > After not being sure for about a year, I've come to believe it is > > extremely useful. I think Bertrand Meyer is correct in saying that MI > > Somewhat interestingly, I (and some others here) went the other way > 'round and now consider MI to be (generally speaking) poor modeling. > > > is not bad as long as it is implemented properly. Using MI in > > Eiffel is really just no big deal. > > It makes it at least "reasonable" - but it does not address the > modeling issue. > > > Dynamic binding. > > Someone please correct me if I'm wrong on this one, but I think > > in Ada95, the programmer has to designate whether dynamic binding can be > > applied by making a type "classwide" with 'Class. I think this is > > A dynamic binding can be applied to primitive operations of "tagged" > types. _Whether_ any given _invocation_ of such an operation will be > so treated requires that the actual involved be classwide. So, all > primitive ops of tagged types are dispatchable, but if you can control > for any given call instance whether you really want that to happen > > > comparable to C++ "virtual", but I think I read that the Ada compiler is > > Not like C++ "virtual". In C++ only operations tagged with "virtual" > can be dispatching and this tagging happens at the point they are > _declared_. In Ada, all primitive ops of tagged types are > dispatching. > > > executable. The chief objection (if I have understood the Ada mechanism > > correctly) might be that one might forget to make a type classwide that > > a descendant would need to override, and require a change to the code. > > This is indeed a problem with C++ "virtual" but has nothing to do with > Ada. > > > Garbage collection. > > There are many applications being done in Ada for which garbage > > collection is not appropriate (hard real-time, etc.). I suspect that > > there are many more applications being done in Ada that could benefit > > from garbage collection. > > Absolutely. > > > Eiffel is of course garbage collected. There are also library > > facilities for fine-grained control during execution. > > Right. > > > Exception handling. > > This actually seems to be another religious issue. > > > to Ada. As far as I know, Eiffel environments are the only I know of > > that support class flattening (i.e. generating the union of all features > > of all ancestors). > > I seem to recall some freeware stuff that can do this for any language > with class based heirarchy. If anyone actually cares, I think I can > dig this up... > > > They also support push-button access to the list of clients, > > suppliers, ancestors, descendants. I don't know how many times in > > other languages (including Ada) I have really needed to find out > > "who's calling this?" and had nothing better at my disposal than > > grep. > > Such tools certainly do exist. Emacs ada-mode does much of this. > Other environments pretty much do it all and then some. > > > more properly addressed by inheritance (i.e. tagged types). I would > > worry that programmers using that as a guide would attempt to solve many > > problems with child packages that should use inheritance instead. > > Or vice-versa. I'm no longer a big fan of class-based inheritance. > It is useful and has its place. But like anything else - it is a poor > choice for "universal" application. > > > Pointers to functions, aliases. > > I sort of got the heeby-jeebies when I saw these introduced > > into Ada95. They didn't appear any easier or safer to use than > > their counterparts in C/C++. In Ada83, you could sort of see the > > argument for subprogram pointers, but once inheritance and abstract > > subprograms were introduced, they seemed out of context to me. > > These things do have their ups and downs. To be fair, the way they > are done in Ada, probably the "worst" thing about them is they look > "ugly" - makes it look like you are cheating or up to something > nefarious. Note that no matter what, you kind of need subprogram > pointers to be a "good citizen" in today's C dominated world. They are _certainly_ safer than in C. Ada ensures conformance of parameter profiles and being in scope. It is true (as evidenced by the number of "why doesn't this work?" posts on the subject) that they are not easier to use than in C, but that is a side-effect of the safety rules. Inheritance, abstract subprograms, generic subprog params can substitute for subprog pointers, but not sometimes in a less readable and/or less efficient way, and sometimes not at all (as with the X11 & C callback paradigm). -- ---------------------------------------------------------------------- Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA Senior Software Engineer - AFATDS Tool-smith Wanna-be wwgrol AT pseserv3.fw.hac.com Don't send advertisements to this domain unless asked! All disk space on fw.hac.com hosts belongs to either Hughes Defense Communications or the United States government. Using email to store YOUR advertising on them is trespassing! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract [not found] ` <JSA.97Aug27180328@alexandria.organon.com> 1997-08-28 0:00 ` W. Wesley Groleau x4923 @ 1997-09-03 0:00 ` Don Harrison 1997-09-03 0:00 ` Jon S Anthony 1 sibling, 1 reply; 65+ messages in thread From: Don Harrison @ 1997-09-03 0:00 UTC (permalink / raw) Jon S Anthony wrote: :OTOH, Ada has no system validity problems. System validity, in its broadest sense, means that all usage of entities (variables) in a system is legal for all possible objects/values that can become attached (assigned) to them at runtime. This definition includes, but is not limited to, what is traditionally regarded as polymorphic usage. While Eiffel currently fails WRT polymorphic usage, Ada fails WRT other usage. See Deja News for details. So, your claim that Ada doesn't have system validity problems is false. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-03 0:00 ` Don Harrison @ 1997-09-03 0:00 ` Jon S Anthony 1997-09-04 0:00 ` Don Harrison 0 siblings, 1 reply; 65+ messages in thread From: Jon S Anthony @ 1997-09-03 0:00 UTC (permalink / raw) In article <EFx966.8LB@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: > System validity, in its broadest sense, means that all usage of entities Well, you can define it anyway you wish, I suppose, but I was simply refering to its "traditional" usage vis-a-vis Eiffel. > While Eiffel currently fails WRT polymorphic usage, Ada fails WRT other > usage. See Deja News for details. > > So, your claim that Ada doesn't have system validity problems is false. As I recall, that scenario required the _concious_ and _explicit_ choice to violate certain aspects via Unchecked_Conversion. Not at all the same as the concealed land mines of Eiffel. But, I'm not going to say these are somehow ultra-bad or something. In practice they are probably not that big of a deal if you are aware and careful to avoid the situations. Besides, you snipped the one of two smileys I had in there... /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-03 0:00 ` Jon S Anthony @ 1997-09-04 0:00 ` Don Harrison 0 siblings, 0 replies; 65+ messages in thread From: Don Harrison @ 1997-09-04 0:00 UTC (permalink / raw) Jon S Anthony wrote: :In article <EFx966.8LB@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: : :> System validity, in its broadest sense, means that all usage of entities : :Well, you can define it anyway you wish, I suppose, but I was simply :refering to its "traditional" usage vis-a-vis Eiffel. Sure. :> While Eiffel currently fails WRT polymorphic usage, Ada fails WRT other :> usage. See Deja News for details. :> :> So, your claim that Ada doesn't have system validity problems is false. : :As I recall, that scenario required the _concious_ and _explicit_ :choice to violate certain aspects via Unchecked_Conversion. No, I'm not referring to Unchecked_Conversion. As we both know, all bets are off when you choose to do naughty things. I recall we agreed that neither Ada nor Eiffel stopped you statically from trying to attach an out-of-range value at runtime - for Ada, to a subtype; for Eiffel to a precondition-constrained type. However, I recall Norman Cohen (I think) volunteering a hole in Ada's type system - don't remember the details, though. BTW, where is Norm these days? Haven't seen him in c.l.a. lately. :Not at all the same as the concealed land mines of Eiffel. But, I'm not :going to say these are somehow ultra-bad or something. In practice :they are probably not that big of a deal if you are aware and careful :to avoid the situations. Quite true. Essentialy, being able to break polymorphism isn't any worse than the uncertainty of not knowing whether a precondition will always be satisfied. It can justifiably be regarded as a variant of just that. There's no question, of course, that it would be preferable to exclude such errors statically, rather than having to deal with them dynamically. :Besides, you snipped the one of two smileys :I had in there... True. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <EFM140.Fy9@syd.csa.com.au>]
* Re: Design By Contract [not found] ` <EFM140.Fy9@syd.csa.com.au> @ 1997-08-28 0:00 ` Robert Dewar 1997-08-29 0:00 ` Don Harrison 1997-08-28 0:00 ` Jon S Anthony 1 sibling, 1 reply; 65+ messages in thread From: Robert Dewar @ 1997-08-28 0:00 UTC (permalink / raw) Don says << - Simplicity which enables developers to focus on designing rather than trying to remember language rules. A simplistic macroscopic comparison of Eiffel and Ada based on the number of validity rules suggests that Eiffel is about 50 times simpler than Ada.>> Simplicity is a very slippery term, what do you mean: Simplicity of the description Simplicity of format definition Simplicity of programming applications Simplicity of implementation These are nowhere *near* the same thing. For example, let's compare the floating-point rules in C and Ada. Gosh, C is FAR simpler, look at all those rules in annex G in Ada, not to mention the basic stuff in chapter 3. None of that nonsense in C, C is much simpler. But suppose the task is: write portable numerical codes. Oops, now we are in big trouble in C, and the task is far *more* complex, because now we have no guarantees from the language, and either the task is impossible, or involves all kinds of complex external configuration control. It is helpful whenever you use the word simple or complex to say exactly what domain you are talking about. I see all the time people playing the game where they argue simplicitly in one of these domains, implicitly appealing to people's agreement that simplicity in another domain is crucial. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-08-28 0:00 ` Robert Dewar @ 1997-08-29 0:00 ` Don Harrison 0 siblings, 0 replies; 65+ messages in thread From: Don Harrison @ 1997-08-29 0:00 UTC (permalink / raw) Robert Dewar wrote: :Don says : :<< - Simplicity which enables developers to focus on designing rather than : trying to remember language rules. A simplistic, macroscopic comparison : of Eiffel and Ada based on the number of validity rules suggests that : Eiffel is about 50 times simpler than Ada.>> : : :Simplicity is a very slippery term, what do you mean: : :Simplicity of the description :Simplicity of format definition :Simplicity of programming applications :Simplicity of implementation It's perhaps more convenient to express this in terms of the opposite quality: complexity. What I mean specifically is the complexity of relationships between language features (including libraries) in terms of its impact on developing applications. :These are nowhere *near* the same thing. For example, let's compare the :floating-point rules in C and Ada. Gosh, C is FAR simpler, look at all :those rules in annex G in Ada, not to mention the basic stuff in chapter :3. None of that nonsense in C, C is much simpler. : :But suppose the task is: write portable numerical codes. Oops, now we are :in big trouble in C, and the task is far *more* complex, because now we :have no guarantees from the language, and either the task is impossible, :or involves all kinds of complex external configuration control. Yes, I agree there are problems in attempting to compare languages when one provides a facility and another doesn't. In such cases, it's necessary to add appropriate hypothetical mechanisms to the one that lacks them to compare fairly. In the case of Eiifel, you would need to add certain standard and optional class libraries, for example, to compare it with Ada. Even though my formula for relative complexity is macroscopic, I think it has a sufficiently objective basis to be of some interest. It does require some more accurate data than I currently have at my disposal. In particular, I would like to know: How many distinct numbered validity requirements are there in: - The core language part of the Ada RM - Each Annexe of the Ada RM What I mean is how many of these: RM 10.1.2(4), for example. (Examples should be omitted). If you, or anyone is willing to supply this information, I'll post the formula and a discussion of it. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract [not found] ` <EFM140.Fy9@syd.csa.com.au> 1997-08-28 0:00 ` Robert Dewar @ 1997-08-28 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Don Harrison 1997-08-29 0:00 ` Patrick Doyle 1 sibling, 2 replies; 65+ messages in thread From: Jon S Anthony @ 1997-08-28 0:00 UTC (permalink / raw) In article <EFM140.Fy9@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: > - Strict enforcement of encapsulation while maximising visibility. Eiffel > offers a look-but-don't-touch view of object attributes. In Ada83, > an attribute and its type has to be declared in the visible interface in > order for clients to see it's structure but then they can also update it > directly. If you declare its type as private, clients can't update it > directly but neither can they see its structure. Isn't that exactly the point? Why should a client be able to see the actual structure, aka implementation???? > - Simplicity which enables developers to focus on designing rather than > trying to remember language rules. A simplistic macroscopic comparison > of Eiffel and Ada based on the number of validity rules suggests that > Eiffel is about 50 times simpler than Ada. IMO, this is obviously one of those "yes it is, no it isn't" sort of things. It would be very difficult to get a _consistent_ objective metric for this. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-08-28 0:00 ` Jon S Anthony @ 1997-08-29 0:00 ` Don Harrison 1997-08-29 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Patrick Doyle 1 sibling, 1 reply; 65+ messages in thread From: Don Harrison @ 1997-08-29 0:00 UTC (permalink / raw) Jon S Anthony wrote: :In article <EFM140.Fy9@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: : :> - Strict enforcement of encapsulation while maximising visibility. Eiffel :> offers a look-but-don't-touch view of object attributes. In Ada83, :> an attribute and its type has to be declared in the visible interface in :> order for clients to see it's structure but then they can also update it :> directly. If you declare its type as private, clients can't update it :> directly but neither can they see its structure. : :Isn't that exactly the point? Why should a client be able to see the :actual structure, aka implementation???? No, the point is that there is no need to hide the structure of an attribute so long as it's read-only (look-but-don't-touch). These semantics allow you to query components of visible objects directly: a.SOME_TYPE ... if a.y > 0 then x := a.y end but prevent you from updating them directly (which would break encapsulation): a.y := x -- Illegal [You can update them *indirectly* by calling an operation in the object: a.set_y (x)] To get similar read-only semantics in Ada, you have to declare the attribute in the package body (hiding it) and return it via an exported function (which can't have the same name): the_a: SOME_TYPE ... function a return SOME_TYPE is begin return the_a; end; I prefer the Eiffel model because: - It's simple and direct. - It doesn't clutter the spec and body with functions. - It doesn't force you to invent multiple identifiers (one of which has a contrived name: "the_a" above). IMO, the other possibilities for attributes in Ada are unattractive because they are either too permissive (look-and-touch - attributes declared in the visible part of the spec) or too restrictive (don't-look-don't touch - private attributes). BTW, someone with a sense of humour may enjoy BM's discussion of Ada private types (OOSC-2, 33.4 - Hiding the Representation: The Private Story. P.1085-1087). [...] Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-08-29 0:00 ` Don Harrison @ 1997-08-29 0:00 ` Jon S Anthony [not found] ` <EFqE8L.4Eq@ecf.toronto.edu> 1997-09-02 0:00 ` Don Harrison 0 siblings, 2 replies; 65+ messages in thread From: Jon S Anthony @ 1997-08-29 0:00 UTC (permalink / raw) In article <EFnoJv.1vx@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: > :Isn't that exactly the point? Why should a client be able to see the > :actual structure, aka implementation???? > > No, the point is that there is no need to hide the structure of an attribute > so long as it's read-only (look-but-don't-touch). These semantics allow you > to query components of visible objects directly: I'm not convinced that is sufficient. Knowing the structure can lead one into writing things that still depend on it (efficiency hacks come quickly to mind). > I prefer the Eiffel model because: > > - It's simple and direct. > - It doesn't clutter the spec and body with functions. > - It doesn't force you to invent multiple identifiers (one of which has > a contrived name: "the_a" above). Fine. Of course, all of these are simply _subjective_ characterizations. If that is what floats your boat - go for it. > IMO, the other possibilities for attributes in Ada are unattractive > because they are either too permissive (look-and-touch - attributes > declared in the visible part of the spec) or too restrictive > (don't-look-don't touch - private attributes). Again, this is simply personal perspective. It may mean a lot to you, but you should be aware that this subjective stuff ("unattractive" "too permissive" "too restrictive") is just opinion and preference and that others may well view _your_ preferences as "unattractive", "too permissive" and "too restrictive". There just is no consistent objective criteria here. And no amount of saying it's so will make it so. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <EFqE8L.4Eq@ecf.toronto.edu>]
[parent not found: <JSA.97Aug30145058@alexandria.organon.com>]
* Re: Design By Contract [not found] ` <JSA.97Aug30145058@alexandria.organon.com> @ 1997-09-01 0:00 ` Patrick Doyle 0 siblings, 0 replies; 65+ messages in thread From: Patrick Doyle @ 1997-09-01 0:00 UTC (permalink / raw) In article <JSA.97Aug30145058@alexandria.organon.com>, Jon S Anthony <jsa@alexandria.organon.com> wrote: > >Generally speaking, opinion (mine included) is irrelevant and just >leads to the complete waste of bandwidth these sorts of silly threads >suck up. Ok, if you want to turn this place into an online technical manual, fine. I think I'll keep reading others' opinions ("irrelevant" and "waste of bandwidth" as they may be) just in case I might actually learn something. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-08-29 0:00 ` Jon S Anthony [not found] ` <EFqE8L.4Eq@ecf.toronto.edu> @ 1997-09-02 0:00 ` Don Harrison 1997-09-02 0:00 ` Jon S Anthony 1997-09-02 0:00 ` Joerg Rodemann 1 sibling, 2 replies; 65+ messages in thread From: Don Harrison @ 1997-09-02 0:00 UTC (permalink / raw) Jon S Anthony wrote: :In article <EFnoJv.1vx@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: : :> :Isn't that exactly the point? Why should a client be able to see the :> :actual structure, aka implementation???? :> :> No, the point is that there is no need to hide the structure of an attribute :> so long as it's read-only (look-but-don't-touch). These semantics allow you :> to query components of visible objects directly: : :I'm not convinced that is sufficient. Knowing the structure can lead :one into writing things that still depend on it (efficiency hacks come :quickly to mind). The thing is, though, that the designer of the supplier class *intends* the client to see the structure of attributes in just the same way as the author of an Ada interface *intends* clients to see the structure of a value returned by a function. Exporting happens on a need-to-know basis. If clients need attributes for any purpose (including efficiency tuning), then the supplier exports them. If they don't, then the supplier keeps them hidden. Note that in the extreme case of an attribute whose underlying class exports none of its attributes, you have the equivalent to an Ada private attribute. That is, the Ada package Some_Module is type My_type is tagged private; ... -- exported operations No_structure : My_type; private type My_type is tagged record ... -- hidden attributes end record; end; is roughly equivalent to the Eiffel class MY_CLASS feature ... -- exported operations feature {NONE} ... -- hidden attributes end class SOME_CLASS feature no_structure : MY_CLASS end So, if a supplier really needs to restrict what clients can see, for whatever reason, they're able to. However, the good thing about Eiffel is that it gives designers the flexibility of exposing as much or as little of an object's structure, in contrast with with Ada's you-see-it-all or you-see-nothing export policy. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-02 0:00 ` Don Harrison @ 1997-09-02 0:00 ` Jon S Anthony 1997-09-03 0:00 ` Don Harrison [not found] ` <JSA.97Sep3201329@alexandria.organon.com> 1997-09-02 0:00 ` Joerg Rodemann 1 sibling, 2 replies; 65+ messages in thread From: Jon S Anthony @ 1997-09-02 0:00 UTC (permalink / raw) In article <EFuuJK.GKu@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: > So, if a supplier really needs to restrict what clients can see, for > whatever reason, they're able to. Agreed. Never claimed otherwise. > However, the good thing about Eiffel is that it gives designers the > flexibility of exposing as much or as little of an object's > structure, in contrast with with Ada's you-see-it-all or > you-see-nothing export policy. First, whether or not this is "good" depends on many things. Second, you can play the same game in Ada anyway: package P is type T is limited private; type S1 is tagged record ... end record; type S2 is ... end record; type Whatever is private; function Op1 (X : T) return S1; -- Expose S1 substructure function Op2 (X : T) return S2; -- Expose S2 substructure function Op3 (X : T) return Whatever; -- Don't expose this bit ... private ... end P; Also, even here, you it is possible to get at the remaining hidden structure if it is in the private portion with child packages. So, per usual, at the end of the day there really isn't enough overall differences on which to waste energy... /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-02 0:00 ` Jon S Anthony @ 1997-09-03 0:00 ` Don Harrison [not found] ` <JSA.97Sep3201329@alexandria.organon.com> 1 sibling, 0 replies; 65+ messages in thread From: Don Harrison @ 1997-09-03 0:00 UTC (permalink / raw) Jon S Anthony wrote: :In article <EFuuJK.GKu@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: [..] :> However, the good thing about Eiffel is that it gives designers the :> flexibility of exposing as much or as little of an object's :> structure, in contrast with with Ada's you-see-it-all or :> you-see-nothing export policy. I realised after writing this that you can export as much or as little as you like in Ada. In terms of individual attributes, you can do this by supplying a function if you want to export an attribute and by not supplying one if you want to hide one. :Second, you can play the same game in Ada anyway: Agree. :package P is : : type T is limited private; : : type S1 is tagged record : ... : end record; : : type S2 is ... end record; : : type Whatever is private; : : function Op1 (X : T) return S1; -- Expose S1 substructure : : function Op2 (X : T) return S2; -- Expose S2 substructure : : function Op3 (X : T) return Whatever; -- Don't expose this bit : :.... :private :.... :end P; Presumably, T here is composed of S1 and S2 among other things. I agree it gives similar functionality to Eiffel. :Also, even here, you it is possible to get at the remaining hidden :structure if it is in the private portion with child packages. Agree. BTW, I've just re-read the stuff on child packages (public and private) in the Ada95 Rationale. It's making more sense and I can see a couple of places in our recently completed simulation where private child packages would have been useful. They would have been handy for decomposing a couple of large abstractions into components while not exposing the internal interfaces to outsiders. I still prefer the Eiffel mechanisms for a couple reasons: a) Simpler b) Views may be directed to specific clients but it does seem to hold together pretty well. Also, it appears you can acheive comparable export granualarity in Ada and Eiffel. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <JSA.97Sep3201329@alexandria.organon.com>]
[parent not found: <EFzLn7.481@ecf.toronto.edu>]
* Re: Design By Contract [not found] ` <EFzLn7.481@ecf.toronto.edu> @ 1997-09-04 0:00 ` Jon S Anthony 0 siblings, 0 replies; 65+ messages in thread From: Jon S Anthony @ 1997-09-04 0:00 UTC (permalink / raw) In article <EFzLn7.481@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes: > >mechanism is clearly "simpler". b) can be done at a certain level via > >appropriate combination of public/private children, but it is not as > >encompassing as selective export. Then again, I've never had the > >experience where this extra selectivity would have been useful. > > I had an experience where selective export was really useful. I was > writing a circuit simulator, and I was using the builder pattern to > decouple the representation of the circuit from its construction. I > created features to add components and join them with wires. > > Then there was a CIRCUIT_SIMULATOR class which managed the event > queue for a circuit. It needed the ability to cause the circuit to > enact events, but I didn't want the builder to be able to enact > events because a) the circuit is not complete and b) the output > channel for the results of the simulation is not yet ready. > > Thus, I exported the circuit's enact_event feature to CIRCUIT_SIMULATOR > and solved that problem in a very straightforward way. Yes, but this is a good example of something that private children are intended for and which is straightforward to achieve with them. It is not a counter example to the "extra selectivity" capability of selective export. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract [not found] ` <JSA.97Sep3201329@alexandria.organon.com> [not found] ` <EFzLn7.481@ecf.toronto.edu> @ 1997-09-04 0:00 ` Paul Johnson 1997-09-05 0:00 ` Jon S Anthony 1997-09-08 0:00 ` Nick Leaton [not found] ` <EFz0pD.E6n@syd.csa.com.au> 2 siblings, 2 replies; 65+ messages in thread From: Paul Johnson @ 1997-09-04 0:00 UTC (permalink / raw) In article <JSA.97Sep3201329@alexandria.organon.com>, jsa@alexandria.organon.com says... >I believe that it is possible to get a reasonable level of this >awareness without such "steeping" - as long as you are very careful >about not confusing explicit _features_ with the _expressivity_ of the >languages. One may have a specific feature for capability X while the >other achieves X by a nice little combination or particular >utilization of some other features or constructs. And, understanding >this is really the key to rational and (more or less) objective >language comparisons. These are wise words. On the other hand I would hold that a language with direct support for something is better for that thing than a language which requires some idiom. For example Eiffel has direct support for multiple inheritance (MI). Ada requires you to play games with generic parameters in order to achieve the same effect. Here are the reasons I dislike idiomatic programming: 1: Its harder to read. The reader must "reverse engineer" the design of the system by looking at the idiom and recognising it. This generally requires that the reader be familiar with the idiom in question. I recall being totally flumoxed when I was learning assembler and came across my first "JMP" instruction at the end of a routine. Later of course, I learned the trick and would now understand such code. 2: Its harder to optimise. I suspect that MI in Ada provides another good example here. In Eiffel the various jump tables needed for MI can be optimised, for example by eliminating duplication. As far as I can see you can't do that in Ada because the compiler does not have the necessary information about what the programmer is doing. (BTW, I would be very interested in more information about that last point). Of course, this on its own would be an argument for a very large and complex language with specific support for just about everything. This would be a bad thing: simplicity in language design is a Good Thing. OTOH learning an idiom is not really any different to learning a language feature. So the skill in language design and evaluation is in determining which constructs are so common or require such complex idioms that they should be supported directly by the language. IMNHO, MI is such a feature. Paul. -- Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | +44 1245 242244 +-----------+-----------------------------------------+ Work: <paul.johnson@gecm.com> | You are lost in a twisty maze of little Home: <Paul@treetop.demon.co.uk> | standards, all different. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-04 0:00 ` Paul Johnson @ 1997-09-05 0:00 ` Jon S Anthony 1997-09-08 0:00 ` Nick Leaton 1 sibling, 0 replies; 65+ messages in thread From: Jon S Anthony @ 1997-09-05 0:00 UTC (permalink / raw) In article <5ulurp$aj8$1@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes: > These are wise words. On the other hand I would hold that a > language with direct support for something is better for that thing > than a language which requires some idiom. I hope you realize how relative this is to the problem space. Those who _really_ believe this have pursued the path of Application Specific Languages (ASLs), often with automatic generation (so called "meta generators"). Another option is CL, where you can basically build your own ASLs via macros (I suppose this counts as a kind of "meta idiom" as it is very typical technique in CL programming). > 2: Its harder to optimise. I suspect that MI in Ada provides another > good example here. In Eiffel the various jump tables needed for MI > can be optimised, for example by eliminating duplication. As far as > I can see you can't do that in Ada because the compiler does not have > the necessary information about what the programmer is doing. > > (BTW, I would be very interested in more information about that last point). I see absolutely nothing to justify this position. The instantiations happen at compile time and full information is available about what is happening. > Of course, this on its own would be an argument for a very large and > complex language with specific support for just about everything. This Not necessarily. Again, take a look at CL. > feature. So the skill in language design and evaluation is in determining > which constructs are so common or require such complex idioms that they > should be supported directly by the language. This sounds right to me. > IMNHO, MI is such a feature. And in mine, it's clearly _not_. If you are going to run down this sort of road, multiple dispatch (ala' CLOS) seems _clearly_ more fundamental than MI. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-04 0:00 ` Paul Johnson 1997-09-05 0:00 ` Jon S Anthony @ 1997-09-08 0:00 ` Nick Leaton 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Paul Johnson 1 sibling, 2 replies; 65+ messages in thread From: Nick Leaton @ 1997-09-08 0:00 UTC (permalink / raw) > These are wise words. On the other hand I would hold that a language with > direct support for something is better for that thing than a language which > requires some idiom. There are some exceptions to this. I agree with you on MI for example, but if the idiom is particularly easy to express or occurs rarely, then there is no need to extend the language to cope. Having, somewhere in the language specification, a note on the idiom helps, because at least the solution is standard. > For example Eiffel has direct support for multiple inheritance (MI). Ada > requires you to play games with generic parameters in order to achieve > the same effect. > > Here are the reasons I dislike idiomatic programming: > > 1: Its harder to read. The reader must "reverse engineer" the design > of the system by looking at the idiom and recognising it. This > generally requires that the reader be familiar with the idiom in > question. I recall being totally flumoxed when I was learning > assembler and came across my first "JMP" instruction at the end of > a routine. Later of course, I learned the trick and would now understand > such code. Its like learning a spell which you must chant to protect yourself. .. Nick ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-08 0:00 ` Nick Leaton @ 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Paul Johnson 1 sibling, 0 replies; 65+ messages in thread From: Matthew Heaney @ 1997-09-08 0:00 UTC (permalink / raw) In article <VA.0000004d.486c7bde@nickle.compulink.co.uk>, nickle@compulink.co.uk wrote: >> For example Eiffel has direct support for multiple inheritance (MI). Ada >> requires you to play games with generic parameters in order to achieve >> the same effect. Thinking more about it, it really does make sense to implement mixin inheritance this way in Ada 95. The original poster probably wasn't "thinking in Ada." To declare an abstract data type in Ada, you do this: package P is type T is tagged private; ... end; Clients of type T with package P to get visibility to the type: with P; procedure Q is O : P.T; ... Now as far as clients of T are concerned, it doesn't matter whether P is a non-generic package, or the instantiation of a generic package. His manipulation of the type is the same. For example, we could have done this: generic ... package GP is type T is tagged ...; ... package P is new GP (...); My point is that from a client's point of view, it's exactly the same. He wants a type that has certain operations, so he withs a package containing that type. Now we have a certain abstraction into which we want to mix some other operations. What we're debating is how easy it is for the _mixer_ to do this. But who made this executive decision that MI is a better mechanism than genericity for combining abstractions? The key thing is that we're able to combine abstractions this way, _without_ an additional language feature. (This doesn't mean MI is bad, only that it's not needed.) Existing language mechanisms do _exactly_ what we want. The irony is that this isn't anying especially new: in Ada 83 we were _already_ combining abstractions this way (example: extending a list type with utility operations by importing the list type as a generic formal parameter). To say that MI is a "more elegant' mechanism of implementing mixin inheritance, or that Ada requires you to "play games" with generics (thus reducing the Ada mechanism to the status of a mere "idiom"), is a pretty impuissant argument. (Like my new word?) The generic technique is what Ada programmers have been doing all along (though not quite as simply as in Ada 95), so I'm not clear what you'd buy by using yet another mechanism whose superiority is only putative. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-08 0:00 ` Nick Leaton 1997-09-08 0:00 ` Matthew Heaney @ 1997-09-09 0:00 ` Paul Johnson 1 sibling, 0 replies; 65+ messages in thread From: Paul Johnson @ 1997-09-09 0:00 UTC (permalink / raw) In article <VA.0000004d.486c7bde@nickle.compulink.co.uk>, nickle@compulink.co.uk says... > >> These are wise words. On the other hand I would hold that a language with >> direct support for something is better for that thing than a language which >> requires some idiom. > >There are some exceptions to this. I agree with you on MI for example, but if the >idiom is particularly easy to express or occurs rarely, then there is no need >to extend the language to cope. Having, somewhere in the language specification, >a note on the idiom helps, because at least the solution is standard. Absolutely. I was careful in my original posting to say that direct support makes a language better *for that thing*. Of course an extra feature makes the language worse for other things. This is the balance that must be struck. Paul. -- Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | +44 1245 242244 +-----------+-----------------------------------------+ Work: <paul.johnson@gecm.com> | You are lost in a twisty maze of little Home: <Paul@treetop.demon.co.uk> | standards, all different. ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <EFz0pD.E6n@syd.csa.com.au>]
* Re: Design By Contract [not found] ` <EFz0pD.E6n@syd.csa.com.au> @ 1997-09-05 0:00 ` W. Wesley Groleau x4923 [not found] ` <JSA.97Sep4172912@alexandria.organon.com> 1 sibling, 0 replies; 65+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-05 0:00 UTC (permalink / raw) > :> I still prefer the Eiffel mechanisms for a couple reasons: > :> > :> a) Simpler > :> b) Views may be directed to specific clients > : > :Well, OK, but .... > :b) can be done at a certain level via > :appropriate combination of public/private children, but it is not as > :encompassing as selective export. I would say that public children allows selective import, and the "appropriate combination of public/private children" allows export to be selective, but only to the extent of choosing to export within the group or to everyone. > The sort of situations where it is handy is for tightly-knit > And in Ada a tightly-knit abstractions might be a collection of private children. -- ---------------------------------------------------------------------- Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA Senior Software Engineer - AFATDS Tool-smith Wanna-be wwgrol AT pseserv3.fw.hac.com Don't send advertisements to this domain unless asked! All disk space on fw.hac.com hosts belongs to either Hughes Defense Communications or the United States government. Using email to store YOUR advertising on them is trespassing! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <JSA.97Sep4172912@alexandria.organon.com>]
[parent not found: <EG0oz8.F6M@syd.csa.com.au>]
* Re: Design By Contract [not found] ` <EG0oz8.F6M@syd.csa.com.au> @ 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Nick Leaton 1997-09-06 0:00 ` Patrick Doyle [not found] ` <EG0rp7.GtL@syd.csa.com.au> 1 sibling, 2 replies; 65+ messages in thread From: Jon S Anthony @ 1997-09-05 0:00 UTC (permalink / raw) In article <EG0oz8.F6M@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: > Especially since you haven't shown how you think child packages can > give some of what selective export has to offer. It's a bit > difficult to give an example of what they *don't* offer if it's not > clear what they *do* offer. See Patrick's example. The point is, private children provide a level of "selective export" (exporting their interfaces only to their parent's body and certain parts of the private subtrees). IME, this has been quite sufficient. Eiffel's selective export is really much more like the granularity you get (and the attendant problems from) C++ friendship. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-05 0:00 ` Jon S Anthony @ 1997-09-05 0:00 ` Nick Leaton 1997-09-08 0:00 ` Jon S Anthony 1997-09-06 0:00 ` Patrick Doyle 1 sibling, 1 reply; 65+ messages in thread From: Nick Leaton @ 1997-09-05 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > In article <EG0oz8.F6M@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: > > > Especially since you haven't shown how you think child packages can > > give some of what selective export has to offer. It's a bit > > difficult to give an example of what they *don't* offer if it's not > > clear what they *do* offer. > > See Patrick's example. The point is, private children provide a level > of "selective export" (exporting their interfaces only to their > parent's body and certain parts of the private subtrees). IME, this > has been quite sufficient. > > Eiffel's selective export is really much more like the granularity you > get (and the attendant problems from) C++ friendship. Jon, What are the problems? I'm well aware with the issues that arise in C++, particularly with the all or nothing nature of C++ friendship. It is not as if you have to reveal your implementation. Selective revealing of interface I presume is OK, so what mechanism would you provide in its place? -- Nick Eiffel - Possibly the best language in the world - unless proven otherwise. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-05 0:00 ` Nick Leaton @ 1997-09-08 0:00 ` Jon S Anthony 1997-09-09 0:00 ` Nick Leaton 0 siblings, 1 reply; 65+ messages in thread From: Jon S Anthony @ 1997-09-08 0:00 UTC (permalink / raw) In article <341041A6.E45B6425@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes: > > Eiffel's selective export is really much more like the granularity you > > get (and the attendant problems from) C++ friendship. > > Jon, What are the problems? I'm well aware with the issues that > arise in C++, particularly with the all or nothing nature of C++ > friendship. It is not as if you have to reveal your > implementation. That's was not the issue I had in mind, it was more the "clairvoyance" problem of export for future clients. But really, Eiffel has a reasonable way around that which does not fall victim to the C++ problem. > Selective revealing of interface I presume is OK, so > what mechanism would you provide in its place? For something like Eiffel (where everything is defined via inheritance based classification), I think the solution provided is reasonable. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-08 0:00 ` Jon S Anthony @ 1997-09-09 0:00 ` Nick Leaton 1997-09-10 0:00 ` Paul Johnson 0 siblings, 1 reply; 65+ messages in thread From: Nick Leaton @ 1997-09-09 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > Selective revealing of interface I presume is OK, so > > what mechanism would you provide in its place? > > For something like Eiffel (where everything is defined via inheritance > based classification), I think the solution provided is reasonable. > I found things like Eiffel's use of inheritance for getting access to the facilities a little odd at first, but in practice it doesn't turn out to be a problem. Having good names for these classes help. One use is to get access to a set of constant objects in which case mostly we use _CONVENTION at the end of the class name. For functions such as sin and cos, then anthropromorphise (or the code equivalent ;-) ) the class, such as MATHEMATICIAN or STATISTICIAN. Some of are classes here end in _CALCULATOR fall into this category. It then makes it easy to identify or guess what the class is being used for. I would also put them at the end of the inheritance list if you are using MI. -- Nick Eiffel - Possibly the best language in the world - unless proven otherwise. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-09 0:00 ` Nick Leaton @ 1997-09-10 0:00 ` Paul Johnson 0 siblings, 0 replies; 65+ messages in thread From: Paul Johnson @ 1997-09-10 0:00 UTC (permalink / raw) In article <34150AE7.ABE4EDD6@calfp.co.uk>, nickle@calfp.co.uk says... >I found things like Eiffel's use of inheritance for getting access to >the facilities a little odd at first, but in practice it doesn't turn >out to be a problem. Having good names for these classes help. I agree. On the other hand, if you prefer not to pollute your namespace with all the stuff from the mixin class, you can do something like this: feature {NONE} math: expanded MATH; Now anywhere in your code you can write something like: a := math.sin (b) Its a bit like the use/with clauses in Ada. Paul. Paul -- Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | +44 1245 242244 +-----------+-----------------------------------------+ Work: <paul.johnson@gecm.com> | You are lost in a twisty maze of little Home: <Paul@treetop.demon.co.uk> | standards, all different. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Nick Leaton @ 1997-09-06 0:00 ` Patrick Doyle 1 sibling, 0 replies; 65+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) In article <JSA.97Sep5130913@alexandria.organon.com>, Jon S Anthony <jsa@alexandria.organon.com> wrote: > >Eiffel's selective export is really much more like the granularity you >get (and the attendant problems from) C++ friendship. Perhaps it's "more like" but it's certainly very, very different. C++ has no granularity in its selective exports: you're either a friend or you're not. Either you're breaking encapsulation or you're not. In Eiffel, it's a matter of presenting different interfaces to different classes, and the mechanism is precise enough that encapsulation is maintained in all cases--just *different* encapsulations. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <EG0rp7.GtL@syd.csa.com.au>]
* Re: Design By Contract [not found] ` <EG0rp7.GtL@syd.csa.com.au> @ 1997-09-05 0:00 ` Matthew Heaney 0 siblings, 0 replies; 65+ messages in thread From: Matthew Heaney @ 1997-09-05 0:00 UTC (permalink / raw) In article <EG0rp7.GtL@syd.csa.com.au>, nospam@thanks.com.au wrote: >One obvious weakness of Ada child packages compared with Eiffel selective >export is a lack of symmetry. With selective export, two modules can >selectively export to each other. It's difficult to imagine how you could do >this elegantly with child packages, if at all. > >It may be necessary in Ada to co-encapsulate under such circumstances. In >that case, you lose the ability to control how each object updates the other's >state. This issue is frequently debated on comp.lang.ada, but I'll mention it again. The _reason_ modules and types are orthogonal is precisely so you can co-encapsulate types in the same package; this is why no "friend" instruction is needed in Ada. If two types need access to each other's state, then they are highly cohesive abstractions, and _should_ go in the same package. The argument that by using this idiom one "loses the ability to control how each object updates each other's state" isn't an issue in real programs. If such control were an issue, then perhaps the reason is that the abstractions are too large or complex. See John Volan's discussion about Ada's with'ing problem: <http://bluemarble.net/~jvolan/WithingProblem/FAQ.html> -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract [not found] ` <JSA.97Sep4172912@alexandria.organon.com> [not found] ` <EG0oz8.F6M@syd.csa.com.au> @ 1997-09-09 0:00 ` Robert A Duff 1997-09-09 0:00 ` Matthew Heaney 1 sibling, 1 reply; 65+ messages in thread From: Robert A Duff @ 1997-09-09 0:00 UTC (permalink / raw) >In article <EFz0pD.E6n@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: > >> I know you'll probably disagree, (and this is getting into Matt >> Heaney territory), but I believe simplicity is innately, >> universally, and uniformly recognisable by everyone. ... Then how come not everyone in this thread seems to agree on what's simpler than what? - Bob ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-09 0:00 ` Robert A Duff @ 1997-09-09 0:00 ` Matthew Heaney 0 siblings, 0 replies; 65+ messages in thread From: Matthew Heaney @ 1997-09-09 0:00 UTC (permalink / raw) In article <EG9Eo4.318@world.std.com>, bobduff@world.std.com (Robert A Duff) wrote: >>In article <EFz0pD.E6n@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: >> >>> I know you'll probably disagree, (and this is getting into Matt >>> Heaney territory), but I believe simplicity is innately, >>> universally, and uniformly recognisable by everyone. ... > >Then how come not everyone in this thread seems to agree on what's >simpler than what? Exactly. Read my previous post about the difference between a neurophysiologist and a butcher: to the butcher, the brain is quite simple indeed! And that's precisely the issue. Complexity depends on things _and_ people, because everyone's interest is different. Read Dealing with Complexity, by Carson and Flood, for a good introduction to the concepts. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-02 0:00 ` Don Harrison 1997-09-02 0:00 ` Jon S Anthony @ 1997-09-02 0:00 ` Joerg Rodemann 1997-09-02 0:00 ` Jon S Anthony 1 sibling, 1 reply; 65+ messages in thread From: Joerg Rodemann @ 1997-09-02 0:00 UTC (permalink / raw) Don Harrison (nospam@thanks.com.au) wrote: > The thing is, though, that the designer of the supplier class *intends* the > client to see the structure of attributes in just the same way as the author > of an Ada interface *intends* clients to see the structure of a value > returned > by a function. > Exporting happens on a need-to-know basis. If clients need attributes for > any purpose (including efficiency tuning), then the supplier exports them. > If they don't, then the supplier keeps them hidden. Note that in the > extreme > case of an attribute whose underlying class exports none of its attributes, > you have the equivalent to an Ada private attribute. That is, the Ada I wonder what this is all about? In Ada as well as in Eiffel you have to decide if you grant a client read, read/write or none access to any member variables of an object. Certainly the syntax of the following implementations differ --- and in this case tend to need a few more characters in the Ada version. Although there is a slight difference: in Ada you arrange one or more 'class' definitions in a package whereas the feature mechanism of Eiffel reminds me a little bit of the friend declarations in C++. (Sorry if I got this wrong, I just had a short glance at Eiffel yet.) But at least I do not recognize any fundamental difference between the explicit declaration of a function and the possibility to use a member variable as if it was a function. (As far as I remember there is some construct in Ada where a similar interpretation is used. Perhaps someone else has a better memory than me...must have been digging up too many memory problems in C++ lately ;-> ) I occurs to me that the differences this thread is all about start from a slight difference in writing. (You use more words to say this, so mine is better. As in while ( cond ) { while cond loop ... vs. ... } end loop; Well, of course just my opinion Yours Joerg -- rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann Phone: ++49-(0)711-5090670 | Flurstrasse 21, D-70372 Stuttgart, Germany -------------------------------+--------------------------------------------- rodemann@rus.uni-stuttgart.de | University of Stuttgart, Computing Center Phone: ++49-(0)711-685-5815 | Visualization Department, Office: 0.304 Fax: ++49-(0)711-678-7626 | Allmandring 30a, D-70550 Stuttgart, Germany ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-09-02 0:00 ` Joerg Rodemann @ 1997-09-02 0:00 ` Jon S Anthony 0 siblings, 0 replies; 65+ messages in thread From: Jon S Anthony @ 1997-09-02 0:00 UTC (permalink / raw) In article <340bb873.0@news.uni-ulm.de> rodemann@mathematik.uni-ulm.de (Joerg Rodemann) writes: > I wonder what this is all about? In Ada as well as in Eiffel you have to > decide if you grant a client read, read/write or none access to any member > variables of an object. Exactly. > Certainly the syntax of the following implementations differ --- and > in this case tend to need a few more characters in the Ada > version. Although there is a slight difference: in Ada you arrange > one or more 'class' definitions in a package whereas the feature > mechanism of Eiffel reminds me a little bit of the friend > declarations in C++. (Sorry if I got this wrong, I just had a short > glance at Eiffel yet.) > Yes, this pretty much sounds on target as well. > But at least I do not recognize any fundamental difference between the > explicit declaration of a function and the possibility to use a member > variable as if it was a function. Agreed here too. > this thread is all about start from a slight difference in writing. (You > use more words to say this, so mine is better. As in You've just hit the nail on the head, IOW, "much ado about nothing"... /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-08-28 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Don Harrison @ 1997-08-29 0:00 ` Patrick Doyle 1997-08-29 0:00 ` Jon S Anthony 1 sibling, 1 reply; 65+ messages in thread From: Patrick Doyle @ 1997-08-29 0:00 UTC (permalink / raw) In article <JSA.97Aug28172900@alexandria.organon.com>, Jon S Anthony <jsa@alexandria.organon.com> wrote: >In article <EFM140.Fy9@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes: > >> - Strict enforcement of encapsulation while maximising visibility. Eiffel >> offers a look-but-don't-touch view of object attributes. In Ada83, >> an attribute and its type has to be declared in the visible interface in >> order for clients to see it's structure but then they can also update it >> directly. If you declare its type as private, clients can't update it >> directly but neither can they see its structure. > >Isn't that exactly the point? Why should a client be able to see the >actual structure, aka implementation???? If you mean that Eiffel is letting the structure leak out by providing access to data members, then that's not true. The Eiffel syntax for accessing a data member and calling a function with no parameters is identical. So consider what we'd do in C++ to encapsulate a data member: we'd provide an accessor function. In Eiffel, the syntax to do would look like this: class GOOBER feature {ANY} get_value : INTEGER is do Result := value end feature {NONE} value : INTEGER end Now, imagine if, for convenience, you could name the accessor function the same name as the variable--the added word "get" doesn't really add anything to the equation here. What you'd end up with is a class which would behave *exactly* like this one: class GOOBER feature {ANY} value : INTEGER end More importantly, consider the purpose of encapsulation: the representation can be changed while the interface remains the same. That can happen here, too. The above class could change to use a DOUBLE for the representation of value: class GOOBER feature {ANY} value : INTEGER is do Result := double_value end feature {NONE} double_value : DOUBLE end This new class would act just like the old one as far as clients are concerned. So in conclusion, no, revealing the data members in this way does not break encapsulation. Note, however, that this relies on the Eiffel syntax whereby functions with no parameters are syntactically the same as data members. To answer your question, the client may be able to see the data members, but the client can't possibly *know* that that's what's going on. As far as any client knows, it's dealing with an accessor function. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design By Contract 1997-08-29 0:00 ` Patrick Doyle @ 1997-08-29 0:00 ` Jon S Anthony [not found] ` <EFqDw0.3x7@ecf.toronto.edu> 0 siblings, 1 reply; 65+ messages in thread From: Jon S Anthony @ 1997-08-29 0:00 UTC (permalink / raw) In article <EFnK04.J43@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes: > >Isn't that exactly the point? Why should a client be able to see the > >actual structure, aka implementation???? > > If you mean that Eiffel is letting the structure leak out by > providing access to data members, then that's not true. The No. That's not what I'm saying. I'm not commenting about the Eiffel approach at all (which in any event has nothing much to offer over the Ada approach here anyway - beyond certain personal preferences that is). > So in conclusion, no, revealing the data members in this > way does not break encapsulation. Note, however, that this No one claimed otherwise. > To answer your question, the client may be able to see > the data members, but the client can't possibly *know* This at least touches on my point and IMO, this is problematic. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <EFqDw0.3x7@ecf.toronto.edu>]
[parent not found: <JSA.97Aug30145354@alexandria.organon.com>]
* Re: Design By Contract [not found] ` <JSA.97Aug30145354@alexandria.organon.com> @ 1997-09-01 0:00 ` Patrick Doyle 0 siblings, 0 replies; 65+ messages in thread From: Patrick Doyle @ 1997-09-01 0:00 UTC (permalink / raw) In article <JSA.97Aug30145354@alexandria.organon.com>, Jon S Anthony <jsa@alexandria.organon.com> wrote: >In article <EFqDw0.3x7@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes: > >> I'm afraid I don't know what your point is. But let me >> ask you this: Do you think providing accessor functions is >> OK? If so, what's the difference between accessors and the >> Eiffel approach? If not, why? > >Yes, (of course) providing accessor functions is OK. The differences >here are so trivial as to not be worth arguing about. Which is >probably the most important point here. Yes, but enlighten me. What are these trivial differences? I promise I won't laugh. :-) -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <349224633wnr@eiffel.demon.co.uk>]
* Re: Design by Contract [not found] ` <349224633wnr@eiffel.demon.co.uk> @ 1997-08-27 0:00 ` Robert Dewar 1997-08-29 0:00 ` Don Harrison 1 sibling, 0 replies; 65+ messages in thread From: Robert Dewar @ 1997-08-27 0:00 UTC (permalink / raw) Roger says <<Ada would benefit (for some applications) from Eiffel's garbage collection. Apart from that, Ada has quite satisfactory ways of doing what Eiffel has to offer. Although I prefer Eiffel's simple class-centric model and its more disciplined exception model, Ada is certainly very usable without these.>> As has been often pointed out, this is not a language issue, there is nothing in the design of Ada that prohibits garbage collection, and indeed some though has been given in the design to making sure nothing stands in its way (unlike the case with C or, to a somewhat lesser extent withy C++). Indeed there is at least one Ada implementation (the Intermetrics Ada-to_Java compiler) that provides garbage collection, and soon there will be at least one more. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract [not found] ` <349224633wnr@eiffel.demon.co.uk> 1997-08-27 0:00 ` Design by Contract Robert Dewar @ 1997-08-29 0:00 ` Don Harrison 1 sibling, 0 replies; 65+ messages in thread From: Don Harrison @ 1997-08-29 0:00 UTC (permalink / raw) Roger Browne wrote: :"W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com> writes: : :> Suppose Ada added Eiffel assertions and Eiffel added separate :> compilation of specs. Or even some sort of automated control that :> prevented changing contract without special privilege. : :No change is required to Eiffel to enable project managers to keep a hold of :the specs whilst letting programmers loose on the implementation. : :Simply code the spec as abstract classes in separate (locked) files and let :the programmers write the concrete implementation in child classes. I tend to think deferred classes are not the proper analogue of Ada package specifications. Ada package specs, unlike Eiffel deferred classes exist for every module, so a better analogue for this module concept may be the class short form. Deferred classes (specifically, the type aspects of them) are more analogous to Ada abstact types, IMO. Don. (Reverse to reply) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison au.com.csa.syd@donh ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel @ 1997-08-07 0:00 Ken Garlington 1997-08-12 0:00 ` Don Harrison 0 siblings, 1 reply; 65+ messages in thread From: Ken Garlington @ 1997-08-07 0:00 UTC (permalink / raw) Don Harrison wrote: > > Ken Garlington wrote: > > :Don Harrison wrote: > :> > :> Ken Garlington wrote: > :> > :> :Don Harrison wrote: > :> :> > :> :> What we want is a way to signal to the caller that they've made a mistake and > :> :> need to take corrective action. > :> : > :> :If they don't know to check that they might have made a mistake, > :> > :> They *do* know because they get an exception. > : > :Not when they're _writing_ the code, unfortunately. > > Yes, but we're not talking about writing the code. We're talking about execution. > Even Smalltalkers can't write and execute at the same time. :) Eiffel advocates need to decide: Is the primary value of assertions for documentation (as Meyer maintains) or to raise errors during execution (which has a number of drawbacks, including potentially postponing the detection of the problem until well after it is delivered). > > :> :how do they know what corrective action they should take? > :> > :> To determine the right corrective action, they determine which specific > :> (sub-)expression triggered the violation and work out the cause by conventional > :> means, namely logical deduction. > : > :This brings up the second point. Why would a methodology/language go to > :great lengths to _detect_ errors, but completely punt ("use conventional > :means") to determine what to do _afterwards_? > > DBC won't fix the errors for you. :) No, but other methodologies do discuss error recovery techniques, and how to apply them. This is particularly important if the error won't be uncovered until after it is delivered. > No tool can *think* for you. DBC does help identify and localise errors, but > you're the one who must solve them. > > :> :If the erroneous code is reused in another application, doesn't it carry > :> :its error along with it? > :> > :> Yes, that's why it's important to fix it. :) > : > :Doesn't this erode the argument of using Eiffel to support reuse, if > :errors > :are so easily ported between applications? > > No. If an error doesn't exist, it can't be ported. Consider the Ariane case. The error didn't exist in the original environment (Ariane IV). The error only occured during execution in the Ariane 5 environment (a little too late to fix, unfortunately). Basing your argument on execution means that any latent error in the system, which might be caught in other methodologies through the use of analysis and reviews, will be missed using DBC/Eiffel. > > :> :What if the mistake is in your code, not the calling code? > :> > :> The context we're dicussing is a precondition, so I assume you mean a mistake > :> in the precondition. This will be obvious from the fact that the call is valid. > : > :Your code thinks the call is invalid. Who decides otherwise? > > The developer running the program - by thinking. Which is completely contradicted by the abve statements of using assertions for execution purposes. The whole point of a methodology is to guide the thinking of an analyst. It doesn't sound like DBC/Eiffel has given you much in the way of guidance. > > :> This is what I mean about the code proper validating assertions. (See my previous > :> posts for details). > :> > :> :> What about case 2)? Here, we want to check that the work we delegated was > :> :> done properly and acheived what we set out to do. In this case, we can > :> :> perform some checks and raise and exception against ourselves to force us > :> :> to fix the problem (possibly by delegating).. > :> :> > :> :> procedure Assume_Control (Aircraft: Aircraft_Type) is > :> :> require not My_Aircraft.Mine (Aircraft) > :> :> begin > :> :> ... > :> :> My_Aircraft.Add (Aircraft); > :> :> ensure My_Aircraft.Mine (Aircraft) > :> :> end; > :> :> > :> :> which is our final solution. What we are now left with is a component of > :> :> software that we know can only be executed under the intended conditions and > :> :> can guarantee producing the required results. > :> : > :> :Assuming... > :> : > :> :1. My_Aircraft.Mine is correct. (How is this determined? > :> > :> Joachim has already mentioned code inspection. > : > :See my arguments related to manual inspection as the only safeguard > :against > :errors in large systems. > > I'm not suggesting it should be. More to the point, you haven't given any evidence that DBC/Eiffel has any particular advantage in this area. > :> Also, if Mine is called anywhere in the code proper of the system and it has > :> its own assertions, it will be validated by them. > : > :However, other posts have said that assertions shouldn't have > :assertions. > > We're talking about different things. See the OOSC-2 reference and my comments > following for details.. > > :> However, these lower-level > :> assertions won't be evaluated as part of higher-level assertion evaluation. > :> > :> (For details, see OOSC-2, Chapter 11 - "Design by Contract: Building Reliable > :> Software", Page 400 ff.) > :> > :> In this sense, I suppose you could say there are "assertions about assertions" (meta-assertions). They help where they're needed most - where assertions are > :> abstracted using boolean functions. > > :> :2. Assume_Control is not called again with the same aircraft between the > :> : pre-condition and My_Aircraft.Add. > :> : > :> :3. Release_Control (I propose this as the opposite of Assume_Control) is > :> : not called between My_Aircraft.Add and the post-condition. > :> > :> Neither of these concurrency issues exist under SCOOP because the runtime system > :> automatically locks objects on behalf of the thread using them. It's simply > :> impossible to have concurrent access to an object by multiple threads. > : > :So, if an object is referenced by a thread, no other operations > :associated with > :the object can be called (object-locking, as opposed to > :operation-locking)? > > In theory, yes. In practice, I would expect SCOOP implementations to provide > greater flexibility through optimisations (See below). > > :Doesn't this cause a few latency problems? For example, it's usually OK > :for > :multiple reads to occur concurrently, so long as no write is in process. > :SCOOP only permits sequential reads? > > Optimisations could allow multiple concurrent queries (reads). The important > is that exclusive access is *theoretically* guaranteed. What happens in practice > doesn't matter so long as it's safe. Has such automated optimization been done in practice? Isn't such an optimization on the same difficulty level as the toolset automatically generating the correct assertions for each interface? > > :> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 - > :> "Accessing separate objects", Page 982 ff.) > :> > :> Ada, in contrast, does allow this - for example, if tasking is used in isolation. > :> To overcome this deficiency, you have to either roll-your-own object protection > :> (using semaphores, for example) or use protected objects. Using Ada protected > :> objects is fine, but they lack the flexibility of Eiffel separate objects. > : > :Just the opposite! > > Incorrect. Eiffel separate objects always lock the object. Ada protected records can lock the object for a given operation or not (at the designer's preference), can requeue requests, etc. More choices for the designer usually means additional flexibility, I would think. > > :Protected objects, for example, would allow concurrent reads > :if no timing issues result! > > See above. You lose flexibility with protected types because they're not > inheritable and can't be used polymorphically. But you gain flexibility in their timing capabilities (which is what we were discussing, remember? :). Given that the purpose of a protected type is to define time-based aspects the system, isn't this the more valuiable flexibility for this type of object? > > :> :4. There are no errors from other sources (e.g. extraneous code, > :> :higher-tier > :> : documentation miscommunications). > :> > :> I've already covered the case of extraneous code in a previous post. > : > :Right - you said that you assume this won't happen. > > No, I said something else. You said that you did not provide exhaustive coverage via assertions. If that doesn't mean that you assume the condition will not occur, what does it mean? That you assume it will occur, but do not address it? > > :> WRT documentation-related problems, these are outside the scope of any runtime > :> error checking mechanism. DBC is *almost* a silver bullet but not quite. :) > : > :Is DBC a methodology, or a "runtime error checking mechanism"? > > Both. Then what does it matter what a "runtime error checking mechanism" does? The question remains: How does DBC address documentation-related problems? > > :I certainly know > :methodologies that will help uncover extraneous code, and > :requirements/design > :issues. In fact, some methodologies emphasize the ability to manage > :requirements > :and design, since that's where many of the really difficult errors > :emerge. > > I agree this is an important area. Given that, then if DBC does not address this area, it must be deficient. > > :Someone needs to decide if DBC is a coding guideline or a software > :development > :methodology. My concern is that it is touted as the former, but used as > :the latter. > > I don't see any problem with using it as both. However, there is a serious problem when practitioners use it (and discuss it) in terms of the former. Note the number of times in this post, for example, that DBC has been described in terms of concrete capabilities when the subject is code execution, but only vaguely (if at all) when described as a methodology. For example: 1. How, specifically, does DBC support error detection prior to execution? (Not writing down potential error sources, but actually determining if the error exists in the particular application.) 2. By extension, how does DBC support error detection after reuse? 3. For those errors not discovered (which will presumably cause run-time exceptions), how does DBC guide the designer to handle these exceptions (which were not expected to occur)? 4. How does DBC help detect inconsistencies between code and requirements, or for that matter internal consistencies within the requirements? Given that we both agree (as noted earlier in the post) that the key is for the designer to think, how does a coding convention support such thinking - not in terms of general OO concepts like polymorphism and inheritance (which other languages, including Ada, have) but in terms of error detection and correction? > > :> :Also: If the post-condition fails, who provides the corrective action? > :> > :> During development, you, the designer of the code (or your delegate) by fixing > :> the problem. Additionally, in the case of critical software, you can add a > :> rescue clause (exception handler) to keep the show on the road in production. > : > :So, the client has to figure out what to do if your code fails? > > Who said anything about clients? I said the designer of the code containing > the postcondition - that is, the *supplier* in Eiffel parlance. Wait a minute! Here's the possible scenarios: 1. The post-condition fails during initial development. In this case, the developer of the code fixes the problem (or changes the post-condition, as unfortunately sometimes happens). However, how often is the post-condition going to fail at this point? The developer writes both the code and the post-condition, so it's likely that they will match at that point. 2. The post-condition fails after delivery. The developer may no longer be around to fix the problem. Furthermore, if there is a rescue clause, what does it do? What guidance does DBC provide. 3. The post-condition fails during reuse development. Same outcome as #2. This is the most likely case for a post-condition failing - where the environment in which the module is used changes. Any methodology that postpones finding errors until the code is reused is going to be difficult to sell as "reuse-friendly". > > My original example, reinserted.. > > : procedure Assume_Control (Aircraft: Aircraft_Type) is > : require not My_Aircraft.Mine (Aircraft) > : begin > : ... > : My_Aircraft.Add (Aircraft); > : ensure My_Aircraft.Mine (Aircraft) > : end; > > :> :Also: If My_Aircraft.Add is provided by a different programmer/team than > :> :Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)? > :> > :> It doesn't matter. What's your point?.. > : > :It matters a lot! Again, if each team assumes the other does the call, > :this is bad news. > > Correct me if I have this wrong, but you seem to be worried about too few checks > and too many checks. > > WRT too few checks, it's always the responsibility of the client to make sure > the precondition is met. So, a check will always be made. Hasn't this whole discussion been in terms of how to detect errors in the code? Isn't it a little naive to assume that the code will be written correctly as a precondition for finding errors in the code? For that matter, if it's the client's responsibility, and it doesn't hurt if the assertion is not performed by the object being used, then doesn't this cut the legs out of an argument of Eiffel's power? Pretty much any language can provide assertions for the client to manually call prior to using an operation. > > WRT too many checks, an implementation may optimise out any redundant checks > - for example if a precondition check is already done by a caller. This minimises > the number of redundant checks. You're assuming a lot about automated optimizations across object interface boundaries. Is there evidence that Eiffel compilers do such optimizations successfully? Worse, you're again in the "proof by execution" mode. What does this extra code do in terms of readability, for example? > :If both teams do the call, this is not nice from a > :efficiency standpoint. > > See above. Ditto. Any methodology that says, "Write as much code as you want, the compiler will optimize it" doesn't seem to be a strong methodology, in my opinion. > > :> Other classes of error may be identified through other means that > :> you're already well acquanted with. > : > :Furthermore, the classes of error to which DBC is limited are > :well-covered > :through other means (beat to death, in fact). > > The difference is it does a better job of it. We'll just have to agree to disagree on this one. Again, I would rather have a methodology that helps me think about the issues vs. coding them. > > :So, I'm still at a loss to > :see what DBC brings to the table here. It doesn't address my main > :problem (requirements/design faults), > > Not entirely true. DBC can highlight specification/design inconsistencies. > (See my previous posts). Otherwise, I agree. I saw your previous posts. I quote from the line above: "WRT documentation-related problems, these are outside the scope of any runtime error checking mechanism. DBC is *almost* a silver bullet but not quite." Please summarize your arguments/evidence that DBC helps find documentation- related problems. > > :it has limitations with respect to implementation language, > > More accurate is to say that most languages provide limited support for it. Two responses: 1. I was discussing limitations in Eiffel, and 2. Other Eiffel experts disagree with you with regard to other languages: See the post on Internet newsgroup comp.lang.eiffel "Re: Papers on the Ariane-5 crash and Design by Contract," Jean-Marc Jezequel, 1997/03/18: "Ada's subtype declarations are a kind of contract, that could be documented as such. Design by contract is not specific to Eiffel. You can do it with any language, just because it is a way of designing!" > > :it's not clear that it scales well, > > Not true. Can you provide evidence to the contrary? See Internet newsgroup comp.lang.eiffel post "Re: Papers on the Ariane-5 crash and Design by Contract," Jean-Marc Jezequel, 1997/03/18: "...at least in the case of Ariane 501, simple assertions (a la Eiffel and other languages) would have been expressive enough to specify the fatal hidden assumption. Whether the last point scales up to a full sized mission critical system is still an open question. I'm quite confident it is so, but I've only my own experience with telco systems to back it up." > > :and it doesn't appear to be internally complete (big on error detection > :mechanisms, not much on how to derive the particular error sources, > > That's because they're typically blindingly obvious! Why? Because error detection > is more localised. But interface errors, by definition, are not localized. They are generated due to the interaction between objects (in some cases, a long thread of object interactions). The Ariane 5 case is a perfect example of this. Requirements/design mismatches, similarly, are not localized since the requirements are usually not written in terms of objects. One of the designer's jobs is to map the requirements to objects. Even for requirements that are object-oriented, they are usually a much higher level than the implementation. Again, you're thinking of run-time error detection. This is the worst place to detect errors. Consider, for example, the errors made in the Eiffel implementation of the scaling routine presented in their Ariane paper. If these errors were "blindingly obvious", why did it take a year for anyone to say anything about them? > > :and not much on what to do after the error is detected, for example). > > Again, this is usually blindingly obvious. Any time someone says something is obvious, without any evidence or argument to support it, I pretty much assume that the point is ceded. I will say that if error recovery is blindingly obvious, then there's a lot of work in the fault tolerance world that's apparently just a waste of money. :) > > All of these points have been made before. Unfortunately, I think you're right. It doesn't seem as though we're communicating very effectively. I'll concede the argument to you. > > Don. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Don Harrison donh@syd.csa.com.au ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-07 0:00 Safety-critical development in Ada and Eiffel Ken Garlington @ 1997-08-12 0:00 ` Don Harrison 1997-08-12 0:00 ` Jon S Anthony 0 siblings, 1 reply; 65+ messages in thread From: Don Harrison @ 1997-08-12 0:00 UTC (permalink / raw) Ken Garlington wrote (with deletions): :Don Harrison wrote: [...] :> No. If an error doesn't exist, it can't be ported. : :Consider the Ariane case. The error didn't exist in the original :environment :(Ariane IV). The error only occured during execution in the Ariane 5 :environment (a little too late to fix, unfortunately). Basing your :argument :on execution means that any latent error in the system, which might be :caught in other methodologies through the use of analysis and reviews, :will :be missed using DBC/Eiffel. I disagree. I'll explain below.. [...] :> :> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 - :> :> "Accessing separate objects", Page 982 ff.) :> :> :> :> Ada, in contrast, does allow this - for example, if tasking is used in isolation. :> :> To overcome this deficiency, you have to either roll-your-own object protection :> :> (using semaphores, for example) or use protected objects. Using Ada protected :> :> objects is fine, but they lack the flexibility of Eiffel separate objects. :> : :> :Just the opposite! :> :> Incorrect. : :Eiffel separate objects always lock the object. Ada protected records :can lock the :object for a given operation or not (at the designer's preference), IMO, this is something the designer is better off leaving to the compiler as it can be expected to do a better job of it. If Ada protected types allow the designer to explicitly leave objects unlocked (which doesn't appear to be supported by the Ada95 Rationale), then they are more permissive but in a detrimental way, IMO. :can requeue requests, IMO, the situations in which you would use "requeue" are better handled by designing differently - perhaps by using an additional class. If anything, "requeue" probably encourages poor design. :etc. What are these? More choices for the designer usually means additional :flexibility, I would think. Drawing some inspiration from Robert Dewar, "flexibility" and "permissiveness" have at their root the same meaning but differ wrt the user perceives a benefit or detriment respectively. [...] :> :Someone needs to decide if DBC is a coding guideline or a software :> :development :> :methodology. My concern is that it is touted as the former, but used as :> :the latter. :> :> I don't see any problem with using it as both. : :However, there is a serious problem when practitioners use it (and :discuss it) in terms of the former. Note the number of times in this :post, for example, that DBC has been described in terms of concrete :capabilities when the subject is code execution, but only vaguely :(if at all) when described as a methodology.. Your basic worry seems to be that DBC doesn't appear to be an all-embracing, formal software engineering methodology. At this stage, I think you're right. I think the reason why is that DBC probably hasn't been used in the context of *formal* software engineering. If it had, then it would have been integrated with other complementary reliability-enhancing techniques. IMO, a methodology centred on DBC, would also include stuff about systematic testing of components. In the Ariane case, this might involve bolting an IRS onto some test bench and stimulating it with Ariane 5 data. This may require simulating the surrounding environment. Then, any assertions assuming Ariane 4 inputs would be violated (as would the Ada constraint_error). In general, the extra checking afforded by DBC would mean more bugs would be identified than if it wasn't used. (Yes, I know there is no difference wrt the one that caused the failure.) [...] :> :So, I'm still at a loss to :> :see what DBC brings to the table here. It doesn't address my main :> :problem (requirements/design faults), :> :> Not entirely true. DBC can highlight specification/design inconsistencies. :> (See my previous posts). Otherwise, I agree. : :I saw your previous posts. I quote from the line above: : : "WRT documentation-related problems, these are outside the scope of : any runtime error checking mechanism. DBC is *almost* a silver bullet : but not quite." Right person, wrong quote and wrong context. If it's any help to you, the comments I'm referring to were about mutually validating requirements. I acknowledged not all documentation errors were covered. [...] :> :it's not clear that it scales well, :> :> Not true. : :Can you provide evidence to the contrary? I've already covered this. Nick's experience also endorses it. [...] :> :and not much on what to do after the error is detected, for example). :> :> Again, this is usually blindingly obvious. :> :Any time someone says something is obvious, without any evidence or :argument to support it, I pretty much assume that the point is ceded. No, it just means I'm just getting impatient. :( Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-12 0:00 ` Don Harrison @ 1997-08-12 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Ted Velkoff 0 siblings, 1 reply; 65+ messages in thread From: Jon S Anthony @ 1997-08-12 0:00 UTC (permalink / raw) In article <EEsF5y.F5H@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes: > it can be expected to do a better job of it. If Ada protected types allow > the designer to explicitly leave objects unlocked (which doesn't appear to > be supported by the Ada95 Rationale), then they are more permissive but > in a detrimental way, IMO. You're not twigging this stuff. The objects can be unlocked for _read_ access, but never for any update access. Now you can make a value judgement that this is worthless or misguided, but that's different. > :can requeue requests, > > IMO, the situations in which you would use "requeue" are better handled by > designing differently - perhaps by using an additional class. If anything, > "requeue" probably encourages poor design. Requeue is specifically there to eliminate in principle any timing errors. The way this works is somewhat subtle, so maybe you are not twigging this either. > simulating the surrounding environment. Then, any assertions > assuming Ariane 4 inputs would be violated (as would the Ada > constraint_error). In general, the extra checking afforded by DBC > would mean more bugs would be identified than if it wasn't > used. (Yes, I know there is no difference wrt the one that caused > the failure.) The problem with this is the simple observation of "why would the assertions be there in the first place?" After all, in the particular case at hand, they were _intentionally_ removed. And with perfectly sound engineering principles in mind. Assertions in the code _cannot_ capture the constraints presumed for the context of use. This has to come from somewhere else (external documentation, "instructions", "warrenty notes", whatever.) The odd thing here is that this point should be "blindingly obvious", to use one of your phrases. > :Any time someone says something is obvious, without any evidence or > :argument to support it, I pretty much assume that the point is ceded. > > No, it just means I'm just getting impatient. :( Same here - In SPADES. /Jon -- Jon Anthony OMI, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-12 0:00 ` Jon S Anthony @ 1997-08-13 0:00 ` Ted Velkoff 1997-08-13 0:00 ` Ken Garlington 0 siblings, 1 reply; 65+ messages in thread From: Ted Velkoff @ 1997-08-13 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > The problem with this is the simple observation of "why would the > assertions be there in the first place?" After all, in the particular > case at hand, they were _intentionally_ removed. And with perfectly > sound engineering principles in mind. Assertions in the code _cannot_ > capture the constraints presumed for the context of use. This has to > come from somewhere else (external documentation, "instructions", > "warrenty notes", whatever.) [...] > There is an important distinction between including/removing assertions and monitoring/not monitoring them during execution. One of the principal benefits of Eiffel is the fact that assertions remain in the code (where programmers will see them) even if they are not tested dynamically (this is controlled by a compile-time switch). Whether or not this would have saved Ariane V, the documentation and testing benefits of Eiffel's assertions would benefit many, many software projects. -- Ted Velkoff ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ted Velkoff @ 1997-08-13 0:00 ` Ken Garlington 1997-08-14 0:00 ` Nick Leaton 0 siblings, 1 reply; 65+ messages in thread From: Ken Garlington @ 1997-08-13 0:00 UTC (permalink / raw) Ted Velkoff wrote: > > There is an important distinction between including/removing assertions > and monitoring/not monitoring them during execution. One of the > principal benefits of Eiffel is the fact that assertions remain in the > code (where programmers will see them) even if they are not tested > dynamically (this is controlled by a compile-time switch). Whether or > not this would have saved Ariane V, the documentation and testing > benefits of Eiffel's assertions would benefit many, many software > projects. This is certainly reasonable. However, once the execution capabilities are removed, it seems fair to ask what Eiffel provides that comments (available in most langauges) don't provide. If there is not a significant difference, then Eiffel would not be any better (in this context) than any other language, so long as the DBC principles were followed. > > -- Ted Velkoff ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-13 0:00 ` Ken Garlington @ 1997-08-14 0:00 ` Nick Leaton 1997-08-18 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 65+ messages in thread From: Nick Leaton @ 1997-08-14 0:00 UTC (permalink / raw) Ken Garlington wrote: > > Ted Velkoff wrote: > > > > There is an important distinction between including/removing assertions > > and monitoring/not monitoring them during execution. One of the > > principal benefits of Eiffel is the fact that assertions remain in the > > code (where programmers will see them) even if they are not tested > > dynamically (this is controlled by a compile-time switch). Whether or > > not this would have saved Ariane V, the documentation and testing > > benefits of Eiffel's assertions would benefit many, many software > > projects. > > This is certainly reasonable. However, once the execution capabilities > are removed, it seems fair to ask what Eiffel provides that comments > (available in most langauges) don't provide. If there is not a > significant > difference, then Eiffel would not be any better (in this context) than > any other language, so long as the DBC principles were followed. There is one advantage. If your assertions are compiled, they must conform to a set restricted style. Comments are, on the other hand very free form. I think it is reasonable to say that the compiled assertions are less likely to be ambiguous than if they are just a comment. They are more likely to be correct if they have been executed and tested. -- Nick ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-14 0:00 ` Nick Leaton @ 1997-08-18 0:00 ` Joachim Durchholz 1997-08-19 0:00 ` Ken Garlington 0 siblings, 1 reply; 65+ messages in thread From: Joachim Durchholz @ 1997-08-18 0:00 UTC (permalink / raw) Ken Garlington wrote: > This is certainly reasonable. However, once the execution capabilities > are removed, it seems fair to ask what Eiffel provides that comments > (available in most langauges) don't provide. If there is not a > significant > difference, then Eiffel would not be any better (in this context) than > any other language, so long as the DBC principles were followed. Even if the assertions were ignored by the compiler there is a difference. There is a tool called "flat" that examines a class and its ancestors and produces an equivalent class without inheritance. In particular, it collects all assertions from all ancestors and lists them with the final routine. (There is even an option that gives just the signatures and assertions, leaving out the routine bodies.) This gives us full documentation about every routine of every class, without having to refer to ancestor classes. So even if assertions are comments, these comments get included in the flat form of any descendant class. > There is one advantage. If your assertions are compiled, they must > conform to a set restricted style. Comments are, on the other hand > very > free form. Actually it's not restricted style. It is just that comments that are in certain parts of the class text (namely, the assertion sections) automatically gets included in the flat form of descendants. Regards, Joachim -- Please don't send unsolicited ads. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-18 0:00 ` Joachim Durchholz @ 1997-08-19 0:00 ` Ken Garlington 1997-08-21 0:00 ` Joachim Durchholz 0 siblings, 1 reply; 65+ messages in thread From: Ken Garlington @ 1997-08-19 0:00 UTC (permalink / raw) Joachim Durchholz wrote: > > Ken Garlington wrote: > > This is certainly reasonable. However, once the execution capabilities > > are removed, it seems fair to ask what Eiffel provides that comments > > (available in most langauges) don't provide. If there is not a > > significant > > difference, then Eiffel would not be any better (in this context) than > > any other language, so long as the DBC principles were followed. > > Even if the assertions were ignored by the compiler there is a > difference. > There is a tool called "flat" that examines a class and its ancestors > and produces an equivalent class without inheritance. In particular, it > collects all assertions from all ancestors and lists them with the final > routine. (There is even an option that gives just the signatures and > assertions, leaving out the routine bodies.) > This gives us full documentation about every routine of every class, > without having to refer to ancestor classes. So even if assertions are > comments, these comments get included in the flat form of any descendant > class. Can't such an extra-language tool be equally valid with comments in any language (that has classes)? > > > There is one advantage. If your assertions are compiled, they must > > conform to a set restricted style. Comments are, on the other hand > > very > > free form. > > Actually it's not restricted style. It is just that comments that are in > certain parts of the class text (namely, the assertion sections) > automatically gets included in the flat form of descendants. This doesn't sound like Eiffel assertions, which are compiled. > > Regards, > Joachim > -- > Please don't send unsolicited ads. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-19 0:00 ` Ken Garlington @ 1997-08-21 0:00 ` Joachim Durchholz 1997-08-23 0:00 ` Ken Garlington 0 siblings, 1 reply; 65+ messages in thread From: Joachim Durchholz @ 1997-08-21 0:00 UTC (permalink / raw) Ken Garlington wrote: > > There is a tool called "flat" that ... collects all assertions > > from all ancestors and lists them with the final > > routine. (There is even an option that gives just the signatures and > > assertions, leaving out the routine bodies.) > > This gives us full documentation about every routine of every class, > > without having to refer to ancestor classes. So even if assertions > are > > comments, these comments get included in the flat form of any > descendant > > class. > > Can't such an extra-language tool be equally valid with comments in > any > language (that has classes)? Yes, and I'd advocate some tool of this type for every language. Something similar is done for the Java AWT, where each routine is documented via some comments with standardized keywords (the "keywords" being single letters, making the comment rather unreadable...); the HTML documentation for the AWT is obviously generated with a tool. Unfortunately, inheritance isn't considered by that tool. The advantage of this being part of the language definition is that a) the conventions are the same for every shop (a mere comment convention might be different, creating incompatibilities not with the executable code but with the development environments) b) Eiffel can make use of executable assertions and compile them as run-time checks. > > Actually it's not restricted style. It is just that comments that > are in > > certain parts of the class text (namely, the assertion sections) > > automatically gets included in the flat form of descendants. > > This doesn't sound like Eiffel assertions, which are compiled. Eiffel assertions are not compiled if they take the form of a comment. You can write something like feature sqrt (x: real): real is require nonnegative_argument: x >= 0 do ... (lots of code omitted) ensure nonnegative_result: Result >= 0 maximum_precision: -- Every mantissa bit except the last is correct end The short tool will report this routine as feature sqrt (x: real): real is require nonnegative_argument: x >= 0 ensure nonnegative_result: Result >= 0 maximum_precision: -- Every mantissa bit except the last is correct end so executable and non-executable assertions aren't handled any differently for documentation purposes. Regards, Joachim -- Please don't send unsolicited ads. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-21 0:00 ` Joachim Durchholz @ 1997-08-23 0:00 ` Ken Garlington [not found] ` <JSA.97Aug25181856@alexandria.organon.com> 0 siblings, 1 reply; 65+ messages in thread From: Ken Garlington @ 1997-08-23 0:00 UTC (permalink / raw) Joachim Durchholz wrote: > > The advantage of this being part of the language definition is that > a) the conventions are the same for every shop (a mere comment > convention might be different, creating incompatibilities not with the > executable code but with the development environments) > b) Eiffel can make use of executable assertions and compile them as > run-time checks. > > [snip] > > Eiffel assertions are not compiled if they take the form of a comment. Then they aren't Eiffel assertions, per the definition you gave in (a) and (b)! > You can write something like > > feature sqrt (x: real): real is > require > nonnegative_argument: x >= 0 > do > ... (lots of code omitted) > ensure > nonnegative_result: Result >= 0 > maximum_precision: -- Every mantissa bit except the last is correct > end > > The short tool will report this routine as > > feature sqrt (x: real): real is > require > nonnegative_argument: x >= 0 > ensure > nonnegative_result: Result >= 0 > maximum_precision: -- Every mantissa bit except the last is correct > end > > so executable and non-executable assertions aren't handled any > differently for documentation purposes. Nor would they be handled any differently in Ada, etc. To repeat: For those items in comments, what advantage does Eiffel provide? > > Regards, > Joachim > -- > Please don't send unsolicited ads. ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <JSA.97Aug25181856@alexandria.organon.com>]
[parent not found: <34023A1F.41C67EA6@eiffel.com>]
* Re: Design by Contract [not found] ` <34023A1F.41C67EA6@eiffel.com> @ 1997-08-25 0:00 ` Bertrand Meyer 1997-08-25 0:00 ` Steve Stringfellow 1997-08-26 0:00 ` Don Harrison 1997-08-25 0:00 ` Bertrand Meyer ` (2 subsequent siblings) 3 siblings, 2 replies; 65+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) on S Anthony writes: > Isn't this simply amazing? I mean, really - what do these people > think they are saying anyway? To me this has long since pushed my > "boggo-meter" off the scale and crossed into the mind-numbingly > fatuous. where "these people", if I understand properly, means advocates of Design by Contract. Insulting the other side is not a substitute for rational argument (but tends to suggest fragility of one's case). In a related message, W. Wesley Groleau writes > I say again: If [Design by Contract] > is defined as "Associating specifications > with software elements", then Eiffel indeed directly > supports a SUBSET of DBC. Ada directly supports another > subset of DBC. C++ (shudder) directly supports yet > another subset of DBC. And with a little extra work, > the user of any of these languages can handle a larger > subset. But none of them can completely support > the whole thing. And the intersection of the subsets > is not empty. which the 3 or 4 strident Ada advocates in this thread now repeat in all tunes to assert that, after all, Ada supports Design by Contract just as much as Eiffel, only differently. This is a sophism. Of course in any typed language you can express some specification elements; e.g. by declaring f (x: INTEGER) in Pascal or the equivalent in Fortran, C, Ada etc. you are placing some restrictions on what kind of argument f admits. But this is a far cry from what you need to express useful specifications: - Routine preconditions -- semantic conditions (not just type constraints). - Routine postconditions (how do you state that at the end of the procedure `withdraw' the balance must have been decreased by `sum'?). - Class invariants, expressing general integrity constraints. - The relationship with inheritance (precondition weakening and postcondition strengthening in redeclaration; invariant accumulation). - The relationship with documentation tools. - The relationship with exception handling. Common languages support at most a minute subset of the 1st and 3rd items. To use this observation to justify a Turing-tarpit kind of argument -- "all languages support Design by Contract, only in various ways" -- is a fallacy. So huge a "difference of degree" becomes a difference of nature. Just take any of the assertions of the classes of EiffelBase and try to express them in C, Ada, C++ or Java. You will be able to write almost nothing. What *is* true is that in such languages without assertions you can and should still apply Design by Contract purely as a methodological discipline. Although you won't get the language and tool support, you will still get some of the benefits. But, no, declaring variables with interval types as in Pascal or Ada is not Design by Contract. The rear-guard battle waged by a few people against Design by Contract on comp.lang.ada and comp.lang.eiffel -- oscillating between "it's useless", "it can all be done in Ada", "it's nothing new", "it's irrelevant to the real problems", "it's not enough", "it's snake oil" and other endless if often contradictory variations -- is saddening. Saddening because as soon as Design by Contract is applied systematically (whether as pure methodology, or better yet in a language like Eiffel that directly supports them) the benefits in reliability are immediate and huge. We constantly hear from our customers and our own work of major potential bugs that are caught before they have had time to strike, simply thanks to contracts. And bug avoidance is only one of the applications. The ability to do serious object-oriented analysis, for example, is just as important. All the rhetoric in the world fades away when assessed against the potential for dramatic improvements in software quality. That's what counts -- not who shouts louder. -- Bertrand Meyer, President, ISE Inc. ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> http://www.eiffel.com, with instructions for download ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-08-25 0:00 ` Design by Contract Bertrand Meyer @ 1997-08-25 0:00 ` Steve Stringfellow 1997-08-26 0:00 ` Don Harrison 1 sibling, 0 replies; 65+ messages in thread From: Steve Stringfellow @ 1997-08-25 0:00 UTC (permalink / raw) Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes: >All the rhetoric in the world fades away when assessed >against the potential for dramatic improvements in >software quality. That's what counts -- not who shouts >louder. As someone who likes Eiffel but is still learning OOP, I have two questions for Dr. Meyer: 1. There have been many assertions about the quality of programs turned out by DBC and Eiffel, where are the killer apps written in either Eiffel or Ada? It would seem that there would be at least some programs that just glow with how well they were done in Eiffel. And how they couldn't have been done in any other language. The language Forth in the realtime, small computer field is noted for stories of how it did things no other language could do. But the only language in OOP that seems like that is Smalltalk. Why? 2. Why not make Eiffel a framework that you can use for designing programs that are ultimately written in C, C++, or Java? By this I mean turning out readable rather than just executable code in these languages and keeping the snide comments about C programmers and language to a minimum. If Eiffel could turn out good code in C, C++, or Java the opportunities would be huge. If it were seen that these languages were the assembly languages of Eiffel and that you sometimes write routines in assembler then Eiffel would be the ultimate framework. The possibilities are enormous. Until there is a breakthrough in either area I am afraid that Eiffel is on the way to becoming either the Forth or the Pascal of the OOP world. And given the neat qualities of Eiffel I would hate to see it suffer either fate. Steve Stringfellow steves@mcs.com >-- >Bertrand Meyer, President, ISE Inc. >ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117 >805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> >http://www.eiffel.com, with instructions for download ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-08-25 0:00 ` Design by Contract Bertrand Meyer 1997-08-25 0:00 ` Steve Stringfellow @ 1997-08-26 0:00 ` Don Harrison 1 sibling, 0 replies; 65+ messages in thread From: Don Harrison @ 1997-08-26 0:00 UTC (permalink / raw) Bertrand Meyer wrote: :... Ada supports :Design by Contract just as much as Eiffel, only differently. : :This is a sophism. Of course in any typed language you can :express some specification elements; :e.g. by declaring f (x: INTEGER) in :Pascal or the equivalent in Fortran, C, Ada etc. you are :placing some restrictions on what kind of argument f admits. :But this is a far cry from what you need to express useful :specifications: : : - Routine preconditions -- semantic conditions : (not just type constraints). : : - Routine postconditions (how do you state that : at the end of the procedure `withdraw' the balance : must have been decreased by `sum'?). : : - Class invariants, expressing general integrity : constraints. : : - The relationship with inheritance (precondition weakening : and postcondition strengthening in redeclaration; : invariant accumulation). : : - The relationship with documentation tools. : : - The relationship with exception handling. : :Common languages support at most a minute subset of the 1st :and 3rd items. To use this observation to justify a Turing-tarpit :kind of argument -- "all languages support Design by Contract, :only in various ways" -- is a fallacy. So huge a "difference of :degree" becomes a difference of nature. Just take any of the :assertions of the classes of EiffelBase and try to express :them in C, Ada, C++ or Java. You will be able to write almost :nothing. : :What *is* true is that in such languages without assertions :you can and should still apply Design by Contract purely as :a methodological discipline. Although you won't get the :language and tool support, you will still get some of the benefits. :But, no, declaring variables with interval types as in Pascal :or Ada is not Design by Contract. : :The rear-guard battle waged by a few people against Design :by Contract on comp.lang.ada and comp.lang.eiffel -- :oscillating between "it's useless", "it can all be done in Ada", :"it's nothing new", "it's irrelevant to the real problems", :"it's not enough", "it's snake oil" and other endless :if often contradictory variations -- is saddening. :Saddening because as soon as Design by Contract is applied :systematically (whether as pure methodology, or better :yet in a language like Eiffel that directly supports them) :the benefits in reliability are immediate and huge. :We constantly hear from our customers and our own work :of major potential bugs that are caught before they :have had time to strike, simply thanks to contracts. :And bug avoidance is only one of the applications. :The ability to do serious object-oriented analysis, :for example, is just as important. : :All the rhetoric in the world fades away when assessed :against the potential for dramatic improvements in :software quality. That's what counts -- not who shouts :louder. Well said. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison nospam@thankyou.maam.com.au ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract [not found] ` <34023A1F.41C67EA6@eiffel.com> 1997-08-25 0:00 ` Design by Contract Bertrand Meyer @ 1997-08-25 0:00 ` Bertrand Meyer [not found] ` <JSA.97Aug26151833@alexandria.organon.com> 1997-08-25 0:00 ` Bertrand Meyer 1997-08-25 0:00 ` Bertrand Meyer 3 siblings, 1 reply; 65+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) on S Anthony writes: > Isn't this simply amazing? I mean, really - what do these people > think they are saying anyway? To me this has long since pushed my > "boggo-meter" off the scale and crossed into the mind-numbingly > fatuous. where "these people", if I understand properly, means advocates of Design by Contract. Insulting the other side is not a substitute for rational argument (but tends to suggest fragility of one's case). In a related message, W. Wesley Groleau writes > I say again: If [Design by Contract] > is defined as "Associating specifications > with software elements", then Eiffel indeed directly > supports a SUBSET of DBC. Ada directly supports another > subset of DBC. C++ (shudder) directly supports yet > another subset of DBC. And with a little extra work, > the user of any of these languages can handle a larger > subset. But none of them can completely support > the whole thing. And the intersection of the subsets > is not empty. which the 3 or 4 Ada advocates in this thread now repeat in all tunes to assert that, after all, Ada supports Design by Contract just as much as Eiffel, only differently. This is a sophism. Of course in any typed language you can express some specification elements; e.g. by declaring f (x: INTEGER) in Pascal or the equivalent in Fortran, C, Ada etc. you are placing some restrictions on what kind of argument f admits. But this is a far cry from what you need to express useful specifications: - Routine preconditions -- semantic conditions (not just type constraints). - Routine postconditions (how do you state that at the end of the procedure `withdraw' the balance must have been decreased by `sum'?). - Class invariants, expressing general integrity constraints. - The relationship with inheritance (precondition weakening and postcondition strengthening in redeclaration; invariant accumulation). - The relationship with documentation tools. - The relationship with exception handling. Common languages support at most a minute subset of the 1st and 3rd items. To use this observation to justify a Turing-tarpit kind of argument -- "all languages support Design by Contract, only in various ways" -- is a fallacy. So huge a "difference of degree" becomes a difference of nature. Just take any of the assertions of the classes of EiffelBase and try to express them in C, Ada, C++ or Java. You will be able to write almost nothing. What *is* true is that in such languages without assertions you can and should still apply Design by Contract purely as a methodological discipline. Although you won't get the language and tool support, you will still get some of the benefits. But, no, declaring variables with interval types as in Pascal or Ada is not Design by Contract. The rear-guard battle waged by a few people against Design by Contract on comp.lang.ada and comp.lang.eiffel -- oscillating between "it's useless", "it can all be done in Ada", "it's nothing new", "it's irrelevant to the real problems", "it's not enough", "it's snake oil" and other endless if often contradictory variations -- is saddening. Saddening because as soon as Design by Contract is applied systematically (whether as pure methodology, or better yet in a language like Eiffel that directly supports them) the benefits in reliability are immediate and huge. We constantly hear from our customers and our own work of major potential bugs that are caught before they have had time to strike, simply thanks to contracts. And bug avoidance is only one of the applications. The ability to do serious object-oriented analysis, for example, is just as important. All the rhetoric in the world fades away when assessed against the potential for dramatic improvements in software quality. That's what counts -- not who shouts louder. -- Bertrand Meyer, President, ISE Inc. ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> http://www.eiffel.com, with instructions for download ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <JSA.97Aug26151833@alexandria.organon.com>]
* Re: Design by Contract [not found] ` <JSA.97Aug26151833@alexandria.organon.com> @ 1997-08-27 0:00 ` Patrick Doyle 0 siblings, 0 replies; 65+ messages in thread From: Patrick Doyle @ 1997-08-27 0:00 UTC (permalink / raw) Hey, Jon, take a deep breath, relax, and have a look at what you said... In article <JSA.97Aug26151833@alexandria.organon.com>, Jon S Anthony <jsa@alexandria.organon.com> wrote: >In article <34023C68.794BDF32@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes: > >> Insulting the other side is not a substitute for rational argument >> (but tends to suggest fragility of one's case). > >This from someone who has offered not much beyond "because I say so" >as "substance" in this "debate". Go figure. > >> All the rhetoric in the world fades away when assessed against the >> potential for dramatic improvements in software quality. That's what >> counts -- not who shouts louder. > >With luck - so will yours. You're doing just what he's accusing you of doing. And it's just as pointless as he says it is. Ok, maybe he's doing it too, but if Bertrand Meyer jumped off a bridge... Why don't both you guys tell us once again exactly what your central points are, and we can get back on track. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract [not found] ` <34023A1F.41C67EA6@eiffel.com> 1997-08-25 0:00 ` Design by Contract Bertrand Meyer 1997-08-25 0:00 ` Bertrand Meyer @ 1997-08-25 0:00 ` Bertrand Meyer [not found] ` <3402d123.0@news.uni-ulm.de> [not found] ` <bengtk-2708972209500001@sl35.modempool.kth.se> 1997-08-25 0:00 ` Bertrand Meyer 3 siblings, 2 replies; 65+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) on S Anthony wrote: > Isn't this simply amazing? I mean, really - what do these people > think they are saying anyway? To me this has long since pushed my > "boggo-meter" off the scale and crossed into the mind-numbingly > fatuous. where "these people", if I understand properly, means advocates of Design by Contract. Insulting the other side is not a substitute for rational argument (but tends to suggest fragility of one's case). In a related message, W. Wesley Groleau writes > I say again: If [Design by Contract] > is defined as "Associating specifications > with software elements", then Eiffel indeed directly > supports a SUBSET of DBC. Ada directly supports another > subset of DBC. C++ (shudder) directly supports yet > another subset of DBC. And with a little extra work, > the user of any of these languages can handle a larger > subset. But none of them can completely support > the whole thing. And the intersection of the subsets > is not empty. which the 3 or 4 strident Ada advocates in this thread now repeat in all tunes to assert that, after all, Ada supports Design by Contract just as much as Eiffel, only differently. This is a sophism. Of course in any typed language you can express some specification elements; e.g. by declaring f (x: INTEGER) in Pascal or the equivalent in Fortran, C, Ada etc. you are placing some restrictions on what kind of argument f admits. But this is a far cry from what you need to express useful specifications: - Routine preconditions -- semantic conditions (not just type constraints). - Routine postconditions (how do you state that at the end of the procedure `withdraw' the balance must have been decreased by `sum'?). - Class invariants, expressing general integrity constraints. - The relationship with inheritance (precondition weakening and postcondition strengthening in redeclaration; invariant accumulation). - The relationship with documentation tools. - The relationship with exception handling. Common languages support at most a minute subset of the 1st and 3rd items. To use this observation to justify a Turing-tarpit kind of argument -- "all languages support Design by Contract, only in various ways" -- is a fallacy. So huge a "difference of degree" becomes a difference of nature. Just take any of the assertions of the classes of EiffelBase and try to express them in C, Ada, C++ or Java. You will be able to write almost nothing. What *is* true is that in such languages without assertions you can and should still apply Design by Contract purely as a methodological discipline. Although you won't get the language and tool support, you will still get some of the benefits. But, no, declaring variables with interval types as in Pascal or Ada is not Design by Contract. The rear-guard battle waged by a few people against Design by Contract on comp.lang.ada and comp.lang.eiffel -- oscillating between "it's useless", "it can all be done in Ada", "it's nothing new", "it's irrelevant to the real problems", "it's not enough", "it's snake oil" and other endless if often contradictory variations -- is saddening. Saddening because as soon as Design by Contract is applied systematically (whether as pure methodology, or better yet in a language like Eiffel that directly supports them) the benefits in reliability are immediate and huge. We constantly hear from our customers and our own work of major potential bugs that are caught before they have had time to strike, simply thanks to contracts. And bug avoidance is only one of the applications. The ability to do serious object-oriented analysis, for example, is just as important. All the rhetoric in the world fades away when assessed against the potential for dramatic improvements in software quality. That's what counts -- not who shouts louder. -- Bertrand Meyer, President, ISE Inc. ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> http://www.eiffel.com, with instructions for download ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <3402d123.0@news.uni-ulm.de>]
* Re: Design by Contract [not found] ` <3402d123.0@news.uni-ulm.de> @ 1997-08-26 0:00 ` Nick Leaton [not found] ` <3402e51d.0@news.uni-ulm.de> [not found] ` <340306E1.5FB64D70@XYZZYcalfp.com> 0 siblings, 2 replies; 65+ messages in thread From: Nick Leaton @ 1997-08-26 0:00 UTC (permalink / raw) To: Joerg Rodemann Joerg Rodemann wrote: > And exactly for that reason I would like to join the opinion that source > seperation of specification and implementation is very useful as well. > As far as I can tell this is a feature that Eiffel seems to be missing, as > many other language. E. g. I rather liked Oberon for quite a while for its > clean and simple concept. But the merging of definition and module files (as > spec and implementation are called there) I found somewhat annoying. Surely > I could see some benefits of this 'new' mechanism if Oberon is used within > that graphical Oberon System. But I used an implementation of Oberon > developped at the University of Ulm that simply sat on top of a Unix system. > I thinks this mixin of spec and body would have messed up things a lot. > > My experience with C++ and C supports this believe as well (note: this is > just MY experience.) for people often do not care about this seperation. > the craziest thing IMO is the inlining of methods within the class header > in C++. If the code is not very well structured you can spend hours and days > about just searching for the specifications. (And the debugger won't be of > much help either... *sigh*) > > As I see it a separation of spec and body is VERY useful and indeed some > kind of contract as well. If it has to be counted among the constructs for > DBC depends of this term's actual definition... There are different ways of approaching the separation. I suspect the majority of people agree that separation is a good thing, but there are more than one way of achieving the aim. Approach one is the C++ way, separate files. The problem here is keeping them in line, consistent names etc. The other approach is to have one file, but have the ability to view the files in different ways. Extract the spcification, view everything. I believe the second way to be the better way as it is simpler, and you use the machine for something it is good at doing. The drawbacks are if you want to publish a specification that won't compile. Why is my immediate response. You need a means to publish specifications for libraries where you only release the compiled code, thereby hiding the implementation. -- Nick ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <3402e51d.0@news.uni-ulm.de>]
[parent not found: <3402E8C9.3384D976@calfp.co.uk>]
[parent not found: <dewar.872631036@merv>]
* Re: Design by Contract [not found] ` <dewar.872631036@merv> @ 1997-08-27 0:00 ` Ted Velkoff 1997-08-27 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) [not found] ` <34050F3C.5A3A@invest.amp.com.au> 2 siblings, 0 replies; 65+ messages in thread From: Ted Velkoff @ 1997-08-27 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Nick said > > <<But if you are allowed to change the merged specification/implementation > and check > that you haven't caused problems else where you are ok. It is true that > with C++ > you have problems and have to be careful. Eiffel you don't, because > there is just one file. Modula II as you point out you don't. Give the > choice of the two different approaches, and having used both I would now > always go for spec and impl. in one file. > >> > > That's truly surprising. One of the things that virtually everone who > uses Ada agrees on is that the separation of spec and body is an invaluable aid > to system structuring. Of course there is no concern about incomaptibilities > in Ada, since everything is always checked for consistency -- I > see that in C++ this would be a prblem, but > going to a single file is a horrible way to solve the problem. Having used each of the languages cited, I vote for Eiffel's one file with extracted specification. When needing to change an interface, I've found it annoying to have to make the same change in two different places. Of course, Ada's compilable package specs are infinitely better than C++ header files. -- Ted Velkoff ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract [not found] ` <dewar.872631036@merv> 1997-08-27 0:00 ` Ted Velkoff @ 1997-08-27 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) [not found] ` <34050F3C.5A3A@invest.amp.com.au> 2 siblings, 0 replies; 65+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-08-27 0:00 UTC (permalink / raw) On 26 Aug 1997 17:33:11 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote: :That's truly surprising. One of the things that virtually everone who :uses Ada agrees on is that the separation of spec and body is an invaluable aid :to system structuring. Can you explain how that works exactly? Personally I would imagine that one can get approximately the same benefit by using abstract classes as specifications, with a nice conceptual simplification of the language. This is not a flame, btw, but I've always had the gut feeling that a Modula-2 like package spec vs. implementation separation was a good idea, but only in the days before a ''real'' complete OO language. If you're going from a generally ad-hoc procedural design, I can imagine it would feel nice, but in a language which already includes abstract interfaces for other reasons, it seems like it would be needless bureaucracy. -- * Matthew B. Kennel/Institute for Nonlinear Science, UCSD - * "People who send spam to Emperor Cartagia... vanish! _They say_ that * there's a room where he has their heads, lined up in a row on a desk... * _They say_ that late at night, he goes there, and talks to them... _they *- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'" ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <34050F3C.5A3A@invest.amp.com.au>]
* Re: Design by Contract [not found] ` <34050F3C.5A3A@invest.amp.com.au> @ 1997-08-28 0:00 ` Robert Dewar 1997-08-29 0:00 ` Paul Johnson 0 siblings, 1 reply; 65+ messages in thread From: Robert Dewar @ 1997-08-28 0:00 UTC (permalink / raw) <<Not at all. There would be better solutions possible, but the single file with good extraction tools works well. It's even possible in C if you can stand the pain.>> The reason I disagree is that it makes configuration management much more complex. Obviously changing a spec is a much different activity than changing a body. The set of people who are allowed to make the change will typically be different, and the procedures to be followed to allow the change to be made will most certainly be different. By having separate files, one can control CM at the file level, which is the natural way of doing things. I don't know Eiffel well enough to know how easy it would be to make the CM system aware of *what kind* of change you were making, from what I know of Eiffel, it sounds difficult. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-08-28 0:00 ` Robert Dewar @ 1997-08-29 0:00 ` Paul Johnson 1997-08-31 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) [not found] ` <dewar.872887402@merv> 0 siblings, 2 replies; 65+ messages in thread From: Paul Johnson @ 1997-08-29 0:00 UTC (permalink / raw) In article <dewar.872791797@merv>, dewar@merv.cs.nyu.edu says... >I don't know Eiffel well enough to know how easy it would be to make the >CM system aware of *what kind* of change you were making, from what I know >of Eiffel, it sounds difficult. No, its easy. Eiffel systems come with tools to extract class interfaces. You just put those interfaces under change control and then compare the stored versions with the newly generated versions. A combination of "diff" with a simple Perl script to distinguish between formatting or comment changes, and more significant interface changes would do the job nicely. Paul. -- Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | +44 1245 242244 +-----------+-----------------------------------------+ Work: <paul.johnson@gecm.com> | You are lost in a twisty maze of little Home: <Paul@treetop.demon.co.uk> | standards, all different. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-08-29 0:00 ` Paul Johnson @ 1997-08-31 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-01 0:00 ` John F. Bell III [not found] ` <dewar.872887402@merv> 1 sibling, 1 reply; 65+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-08-31 0:00 UTC (permalink / raw) On 29 Aug 1997 08:38:34 GMT, Paul Johnson <paul.johnson@gecm.com> wrote: :In article <dewar.872791797@merv>, dewar@merv.cs.nyu.edu says... : :>I don't know Eiffel well enough to know how easy it would be to make the :>CM system aware of *what kind* of change you were making, from what I know :>of Eiffel, it sounds difficult. : :No, its easy. Eiffel systems come with tools to extract class interfaces. :You just put those interfaces under change control and then compare the :stored versions with the newly generated versions. In truth, isn't the right management procedure for this situation to control abstract classes, and have programmers write concrete ones to that spec? :Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | * Matthew B. Kennel/Institute for Nonlinear Science, UCSD - * "People who send spam to Emperor Cartagia... vanish! _They say_ that * there's a room where he has their heads, lined up in a row on a desk... * _They say_ that late at night, he goes there, and talks to them... _they *- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'" ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-08-31 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-01 0:00 ` John F. Bell III 1997-09-02 0:00 ` Ken Garlington 0 siblings, 1 reply; 65+ messages in thread From: John F. Bell III @ 1997-09-01 0:00 UTC (permalink / raw) It seems to me that if you want to keep someone from changing the interface to a class, or anything else for that matter, you stand in front of the development staff and say in a clear voice "Don't change the interface.". If that doesn't work you might try "Don't change the interface or I'll fire you.". Jeez, doesn't anyone work with folks that follow directions anymore? John jfb3@pdq.net (A gun, but one that can follow directions.) ======================================================= >In article <slrn60himi.su2.kennel@lyapunov.ucsd.edu>, >kennel@NOSPAMlyapunov.ucsd.edu wrote: >On 29 Aug 1997 08:38:34 GMT, Paul Johnson <paul.johnson@gecm.com> wrote: >:In article <dewar.872791797@merv>, dewar@merv.cs.nyu.edu says... >: >:>I don't know Eiffel well enough to know how easy it would be to make the >:>CM system aware of *what kind* of change you were making, from what I know >:>of Eiffel, it sounds difficult. >: >:No, its easy. Eiffel systems come with tools to extract class interfaces. >:You just put those interfaces under change control and then compare the >:stored versions with the newly generated versions. > >In truth, isn't the right management procedure for this situation to control >abstract classes, and have programmers write concrete ones to that spec? > >:Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. > | > > >* Matthew B. Kennel/Institute for Nonlinear Science, UCSD - >* "People who send spam to Emperor Cartagia... vanish! _They say_ that >* there's a room where he has their heads, lined up in a row on a desk... >* _They say_ that late at night, he goes there, and talks to them... _they >*- say_ he asks them, 'Now tell me again, how _do_ you make money fast?'" ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-09-01 0:00 ` John F. Bell III @ 1997-09-02 0:00 ` Ken Garlington 1997-09-05 0:00 ` Robert Dewar 0 siblings, 1 reply; 65+ messages in thread From: Ken Garlington @ 1997-09-02 0:00 UTC (permalink / raw) John F. Bell III wrote: > > It seems to me that if you want to keep someone from changing the interface to > a class, or anything else for that matter, you stand in front of the > development staff and say in a clear voice "Don't change the interface.". > > If that doesn't work you might try "Don't change the interface or I'll fire > you.". > > Jeez, doesn't anyone work with folks that follow directions anymore? Put that with the direction, "Oh, and don't make any typos, either." If the engineer has direct access to the file containing the spec, (s)he might inadvertantly change the spec while attempting to change the body. There is also the issue of verification. If a file is modified, it requires extra effort to determine the exact nature of the modification. > > John > jfb3@pdq.net ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-09-02 0:00 ` Ken Garlington @ 1997-09-05 0:00 ` Robert Dewar 0 siblings, 0 replies; 65+ messages in thread From: Robert Dewar @ 1997-09-05 0:00 UTC (permalink / raw) John said <<> It seems to me that if you want to keep someone from changing the interface to > a class, or anything else for that matter, you stand in front of the > development staff and say in a clear voice "Don't change the interface.". > > If that doesn't work you might try "Don't change the interface or I'll fire > you.". > > Jeez, doesn't anyone work with folks that follow directions anymore?>> Hmmm! I do not think this will stand up as an ISO 9000 consistent documented procedure, but if it works, then we can augment Ken's suggestion, tell people in addition not to making typos to write efficient codfe and never introduce regressions -- that way you can do away with the nuisance of regression testing :-) ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <dewar.872887402@merv>]
* Re: Design by Contract [not found] ` <dewar.872887402@merv> @ 1997-09-02 0:00 ` Ken Garlington 1997-09-03 0:00 ` Thomas Beale 1997-09-05 0:00 ` Robert Dewar 0 siblings, 2 replies; 65+ messages in thread From: Ken Garlington @ 1997-09-02 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Can we hear from someone who has used Eiffel with, say, either Clearcase > or Continuus, and has cleanly solved the problem of giving different > access rights for spec and implementation changes. I can't speak for those cases, but with PCMS you can distinguish between files that represent a spec (either Eiffel or Ada) and those that represent a body. Furthermore, you can define different "life cycles" (who gets to do what to each file at a given time) for each type of object. Personally, given that you can (a) mimic Ada specs in Eiffel with deferred classes, (b) mimic Eiffel combined specs/bodies in Ada with a decent editor (and, in the case of GNAT, with gnatchop), and (c) mix and match deferred and concrete operations in both languages, I don't see a huge difference between the two languages in this area. Bad CM will defeat either language's approach... ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-09-02 0:00 ` Ken Garlington @ 1997-09-03 0:00 ` Thomas Beale [not found] ` <EFxx8q.2sw@ecf.toronto.edu> 1997-09-05 0:00 ` Robert Dewar 1 sibling, 1 reply; 65+ messages in thread From: Thomas Beale @ 1997-09-03 0:00 UTC (permalink / raw) Ken Garlington wrote: > > Robert Dewar wrote: > > > > Can we hear from someone who has used Eiffel with, say, either Clearcase > > or Continuus, and has cleanly solved the problem of giving different > > access rights for spec and implementation changes. > >.... > Personally, given that you can (a) mimic Ada specs in Eiffel with > deferred classes, (b) mimic Eiffel combined specs/bodies in Ada with > a decent editor (and, in the case of GNAT, with gnatchop), and > (c) mix and match deferred and concrete operations in both languages, > I don't see a huge difference between the two languages in this > area. Bad CM will defeat either language's approach... Unfortunately this approach equates to introducing SPECIFICATION v IMPLEM (or SPEC/DESIGN/IMPL, or more levels if you want) as one of the dimensions of inheritance. Eiffel for example has no problem with extensive MI; the problem is that the traits of SPEC v IMPL are orthogonal to all the rest of the things you are modelling - they are not (shouldn't be) in the model at all. To see this, just imagine an MI situation: C inherits A and B. You potentially want SPEC and IMPL versions of all these classes: SPEC_A SPEC_B ^ ^ | | SPEC_C ... now where to put the IMPL_A etc classes? You can't really do anything sensible, because denoting classes as "specification" or "implementation" is a process concept. Next week you may want to change it, but if it's in your inheritance model, you're in big trouble. Now, IMO, achieving the required result requires three things: - a repository representation of programming artifacts (normally classes, or patterns in e.g. beta), where representation is fine enough to allow syntactic elements to be controlled separately. E.g. method name, Result type, arg names and types etc etc. - a CM system which can be told to manipulate the contents of this repository in the same way files are manipulated by the (fairly pedestrian) CM systems of today. I.e., treat selected groups of programming artifacts as configurations in the CM sense. - The combined CM system/repository must be capable of understanding dependencies between artifacts so that a change to a specification-level artifact (e.g. a result type) reports the affected implementation-level artifacts. Conversely, an attempt to alter an artifact already constrained by anpther artifact must be stopped with a sensible indication of why. Such "understanding" requires a language tool e.g. an Eiffel or ADA compiler. This allows you to say that certain aspects of an individual class are "specification", and cannot be changed in that class (achieved by CM ownership, permissions etc), or in inheriting classes (achieved by the language tool). But since we are controlling parts of classes (not whole files), there is no problem with an implementor adding implementation details to a class containing "locked" specification details. Actually, in the case of inheritance, you can do something very nice. Let's say you have a class feature address:LIST[ADDRESS_ITEM] -- eiffel which you want to "lock" as specification. Inheritors should be allowed to do: address:LINKED_LIST[ADDRESS_ITEM] -- conformant redef but not (say): address:SET[ADDRESS_ITEM] -- non conformant The language processor in the repository will allow you to define such a constraint, by simply saying that the descendant class must compile. In summary: a repository whose elements are transparent (therefore processable) by language tools, and whose same elements are also transparent (therefore maniplatable) to CM or VC systems is required; further, the CM system must be able to use the language processing tool to define and test dependencies. A simple example of this would be a constraint that forces all descendants of class C to have the same short-form as that of C. - thomas beale ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <EFxx8q.2sw@ecf.toronto.edu>]
* Re: Design by Contract [not found] ` <EFxx8q.2sw@ecf.toronto.edu> @ 1997-09-04 0:00 ` Thomas Beale 0 siblings, 0 replies; 65+ messages in thread From: Thomas Beale @ 1997-09-04 0:00 UTC (permalink / raw) Patrick Doyle wrote: > > In article <340CDE84.6ACC@invest.amp.com.au>, > Thomas Beale <thomas_beale@invest.amp.com.au> wrote: > > > >... now where to put the IMPL_A etc classes? You can't really > >do anything sensible, because denoting classes as "specification" > >or "implementation" is a process concept. Next week you may want > >to change it, but if it's in your inheritance model, you're > >in big trouble. > > I think this is where the Bridge pattern somes in. (I hope that's > the right name.) You'd have a similar heirarchy for the IMPL_x > classes, and the SPEC_x classes would have a member of type IMPL_x. > > Would this solve the problem? This pattern is a similar idea, but it corresponds to the idea of interface/implementation - i.e. exported/hidden rather than different levels of access. It works (forgetting the problems of MI) as long as access restrictions (or change control levels) correspond exactly to interface v implmentation classes in the model. However, if the project wants to place any restrictions on say part of a design-level or implementation detail (a particular algorithm, for example), again it won't work. The point is that software engineering processes often do not correspond cleanly to the object model of the thing being engineered. - thomas beale ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-09-02 0:00 ` Ken Garlington 1997-09-03 0:00 ` Thomas Beale @ 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Ken Garlington 1 sibling, 1 reply; 65+ messages in thread From: Robert Dewar @ 1997-09-05 0:00 UTC (permalink / raw) Ken said <<I can't speak for those cases, but with PCMS you can distinguish between files that represent a spec (either Eiffel or Ada) and those that represent a body. Furthermore, you can define different "life cycles" (who gets to do what to each file at a given time) for each type of object. Personally, given that you can (a) mimic Ada specs in Eiffel with deferred classes, (b) mimic Eiffel combined specs/bodies in Ada with a decent editor (and, in the case of GNAT, with gnatchop), and (c) mix and match deferred and concrete operations in both languages, I don't see a huge difference between the two languages in this area. Bad CM will defeat either language's approach...>> Sure, but that's the whole point, PCMS is file based, and from your description will not easily handle a single file that is both the spec and body in Ada terms. If you want to think in Ada terms, think how you would handle a single file with spec and body in the same file, giving different permissions to people to modify the spec part or body part, sounds awkward to me using PCMS (or any other CM system I am familiar with). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract 1997-09-05 0:00 ` Robert Dewar @ 1997-09-05 0:00 ` Ken Garlington 0 siblings, 0 replies; 65+ messages in thread From: Ken Garlington @ 1997-09-05 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Ken said > > <<I can't speak for those cases, but with PCMS you can distinguish between > files > that represent a spec (either Eiffel or Ada) and those that represent a > body. > Furthermore, you can define different "life cycles" (who gets to do what > to each > file at a given time) for each type of object. > > Personally, given that you can (a) mimic Ada specs in Eiffel with > deferred classes, > (b) mimic Eiffel combined specs/bodies in Ada with a decent editor (and, > in the case > of GNAT, with gnatchop), and (c) mix and match deferred and concrete > operations > in both languages, I don't see a huge difference between the two > languages in this > area. Bad CM will defeat either language's approach...>> > > Sure, but that's the whole point, PCMS is file based, and from your > description will not easily handle a single file that is both the spec > and body in Ada terms. If you want to think in Ada terms, think how > you would handle a single file with spec and body in the same file, giving > different permissions to people to modify the spec part or body part, sounds > awkward to me using PCMS (or any other CM system I am familiar with). Understood - however, if I followed the thread correctly, I could in either Eiffel or Ada: (a) keep the spec and body separate [works better with file oriented CM, etc.] or (b) keep the spec and body together [easier to code for simple cases, etc.]. That was _my_ point. ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <340306E1.5FB64D70@XYZZYcalfp.com>]
* Re: Design by Contract [not found] ` <340306E1.5FB64D70@XYZZYcalfp.com> @ 1997-08-28 0:00 ` Mark Bennison 0 siblings, 0 replies; 65+ messages in thread From: Mark Bennison @ 1997-08-28 0:00 UTC (permalink / raw) Richie Bielak <richieb@XYZZYcalfp.com> wrote: <snip> >But you are making the assumption that a given module has only one interface. >This is not true in Eiffel, as a class can show a different interfaces to >different clients. Should all these interfaces be kept in separate files >(like in Java)? > >In presence of extraction tools, keeping a single file is easier. > Keeping a single file may well be 'easier' but it provides a configuration control nightmare. If you have anything but a small development team ( and by this I mean > 2 engineers ) then access to this single file becomes uncontrollable and there'll be several different versions of the same file that may ( or may not ) be divergent. At least by keeping things in separate files you can have allocated packages of work for engineers that do not directly affect the packages that other engineers are working on, even if they are the different interfaces to the same class. You also get engineers thinking about what the knock-on effects of changing the other interfaces would be rather than just doing it to solve their particular problem ( I would hope :-). Mark. (posted from comp.lang.ada) -- Mark Bennison, +-----------------------------------+ Technical Consultant, | All opinions expressed are my own | EASAMS Software Systems. +-----------------------------------+ "Death is a fickle hen, and random are her eggs" - Armando Iannucci Remove '.no.spam' to return e-mail ^ permalink raw reply [flat|nested] 65+ messages in thread
[parent not found: <bengtk-2708972209500001@sl35.modempool.kth.se>]
* Re: Design by Contract [not found] ` <bengtk-2708972209500001@sl35.modempool.kth.se> @ 1997-08-28 0:00 ` Nick Leaton 0 siblings, 0 replies; 65+ messages in thread From: Nick Leaton @ 1997-08-28 0:00 UTC (permalink / raw) Bengt Kleberg wrote: > > In article <34023BC4.2781E494@eiffel.com>, Bertrand Meyer > <Bertrand.Meyer@eiffel.com> wrote: > > ...deleted > > > > All the rhetoric in the world fades away when assessed > > against the potential for dramatic improvements in > > software quality. That's what counts -- not who shouts > > louder. > > I really wish this was true. Unfortunatly it does not seem to be correct. > My attempts get a chance to use Eiffel, in any project at all, fail. > Always with the counter argument that C++ is much more widely used/known > so that is what we must have. Lately a little Java has sneaked in, but it > is still mostly C++. > > So it seems as if the myriad of voices screaming C++ drowns the dramatic > improvements in software quality available elsewhere. Sadly true, but that is their problem. Personally I don't mind having the competitive advantage of using a clean, powerful language such as Eiffel. If they want the problems of C++ ... -- Nick ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Design by Contract [not found] ` <34023A1F.41C67EA6@eiffel.com> ` (2 preceding siblings ...) 1997-08-25 0:00 ` Bertrand Meyer @ 1997-08-25 0:00 ` Bertrand Meyer 3 siblings, 0 replies; 65+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) In my message on the "second historic mistake" I had written that, whereas Eiffel has successful commercial applications approaching the million lines of source code, there was no comparable experience in Java outside of applets and the Java tools themselves. A few weeks ago there was an interesting exchange: [Ken Garlington] !!! The discussion is interesting in that Meyer !!! (a) criticizes Java for not being used on large !!! projects (whatever happened to unfair criticism !!! of new languages? [Robert Dewar] > > Hmmm! I guess he does not consider the Corel office > > suite large. Or perhaps simply does not know about it. [Bertrand Meyer] > It would be difficult not to know about it, > as it gets hammered over and again by Java proponents > (along with Java tools themselves) as the example of > completed Java development, to the extent that one > may wonder whether there is any other. It's really fascinating to read this again a month later, with the recent announcements -- widely reported by the press -- that Corel is dropping its Java strategy altogether. So much for the showcase success... -- Bertrand Meyer, President, ISE Inc. ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> http://www.eiffel.com, with instructions for download ^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~1997-09-10 0:00 UTC | newest] Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <5u1627$1fak@info4.rus.uni-stuttgart.de> [not found] ` <EFM1Lx.GD2@syd.csa.com.au> 1997-08-28 0:00 ` Design by Contract Robert Dewar 1997-08-21 0:00 Critique of Ariane 5 paper (finally!) aek [not found] ` <33FC66AD.9A0799D4@calfp.co.uk> [not found] ` <33FFA4B1.3543@flash.net> 1997-08-26 0:00 ` Nick Leaton [not found] ` <3403940F.4154@pseserv3.fw.hac.com> 1997-08-27 0:00 ` Design By Contract Ted Velkoff [not found] ` <5u3c6v$gtf$2@miranda.gmrc.gecm.com> 1997-08-28 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Joachim Durchholz 1997-09-06 0:00 ` Patrick Doyle [not found] ` <34058808.3BF@pseserv3.fw.hac.com> 1997-08-28 0:00 ` Darren New [not found] ` <JSA.97Aug27180328@alexandria.organon.com> 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-09-03 0:00 ` Don Harrison 1997-09-03 0:00 ` Jon S Anthony 1997-09-04 0:00 ` Don Harrison [not found] ` <EFM140.Fy9@syd.csa.com.au> 1997-08-28 0:00 ` Robert Dewar 1997-08-29 0:00 ` Don Harrison 1997-08-28 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Don Harrison 1997-08-29 0:00 ` Jon S Anthony [not found] ` <EFqE8L.4Eq@ecf.toronto.edu> [not found] ` <JSA.97Aug30145058@alexandria.organon.com> 1997-09-01 0:00 ` Patrick Doyle 1997-09-02 0:00 ` Don Harrison 1997-09-02 0:00 ` Jon S Anthony 1997-09-03 0:00 ` Don Harrison [not found] ` <JSA.97Sep3201329@alexandria.organon.com> [not found] ` <EFzLn7.481@ecf.toronto.edu> 1997-09-04 0:00 ` Jon S Anthony 1997-09-04 0:00 ` Paul Johnson 1997-09-05 0:00 ` Jon S Anthony 1997-09-08 0:00 ` Nick Leaton 1997-09-08 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Paul Johnson [not found] ` <EFz0pD.E6n@syd.csa.com.au> 1997-09-05 0:00 ` W. Wesley Groleau x4923 [not found] ` <JSA.97Sep4172912@alexandria.organon.com> [not found] ` <EG0oz8.F6M@syd.csa.com.au> 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Nick Leaton 1997-09-08 0:00 ` Jon S Anthony 1997-09-09 0:00 ` Nick Leaton 1997-09-10 0:00 ` Paul Johnson 1997-09-06 0:00 ` Patrick Doyle [not found] ` <EG0rp7.GtL@syd.csa.com.au> 1997-09-05 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Robert A Duff 1997-09-09 0:00 ` Matthew Heaney 1997-09-02 0:00 ` Joerg Rodemann 1997-09-02 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Patrick Doyle 1997-08-29 0:00 ` Jon S Anthony [not found] ` <EFqDw0.3x7@ecf.toronto.edu> [not found] ` <JSA.97Aug30145354@alexandria.organon.com> 1997-09-01 0:00 ` Patrick Doyle [not found] ` <349224633wnr@eiffel.demon.co.uk> 1997-08-27 0:00 ` Design by Contract Robert Dewar 1997-08-29 0:00 ` Don Harrison -- strict thread matches above, loose matches on Subject: below -- 1997-08-07 0:00 Safety-critical development in Ada and Eiffel Ken Garlington 1997-08-12 0:00 ` Don Harrison 1997-08-12 0:00 ` Jon S Anthony 1997-08-13 0:00 ` Ted Velkoff 1997-08-13 0:00 ` Ken Garlington 1997-08-14 0:00 ` Nick Leaton 1997-08-18 0:00 ` Joachim Durchholz 1997-08-19 0:00 ` Ken Garlington 1997-08-21 0:00 ` Joachim Durchholz 1997-08-23 0:00 ` Ken Garlington [not found] ` <JSA.97Aug25181856@alexandria.organon.com> [not found] ` <34023A1F.41C67EA6@eiffel.com> 1997-08-25 0:00 ` Design by Contract Bertrand Meyer 1997-08-25 0:00 ` Steve Stringfellow 1997-08-26 0:00 ` Don Harrison 1997-08-25 0:00 ` Bertrand Meyer [not found] ` <JSA.97Aug26151833@alexandria.organon.com> 1997-08-27 0:00 ` Patrick Doyle 1997-08-25 0:00 ` Bertrand Meyer [not found] ` <3402d123.0@news.uni-ulm.de> 1997-08-26 0:00 ` Nick Leaton [not found] ` <3402e51d.0@news.uni-ulm.de> [not found] ` <3402E8C9.3384D976@calfp.co.uk> [not found] ` <dewar.872631036@merv> 1997-08-27 0:00 ` Ted Velkoff 1997-08-27 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) [not found] ` <34050F3C.5A3A@invest.amp.com.au> 1997-08-28 0:00 ` Robert Dewar 1997-08-29 0:00 ` Paul Johnson 1997-08-31 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-01 0:00 ` John F. Bell III 1997-09-02 0:00 ` Ken Garlington 1997-09-05 0:00 ` Robert Dewar [not found] ` <dewar.872887402@merv> 1997-09-02 0:00 ` Ken Garlington 1997-09-03 0:00 ` Thomas Beale [not found] ` <EFxx8q.2sw@ecf.toronto.edu> 1997-09-04 0:00 ` Thomas Beale 1997-09-05 0:00 ` Robert Dewar 1997-09-05 0:00 ` Ken Garlington [not found] ` <340306E1.5FB64D70@XYZZYcalfp.com> 1997-08-28 0:00 ` Mark Bennison [not found] ` <bengtk-2708972209500001@sl35.modempool.kth.se> 1997-08-28 0:00 ` Nick Leaton 1997-08-25 0:00 ` Bertrand Meyer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox