From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: Ted Velkoff Subject: Re: Design By Contract Date: 1997/08/27 Message-ID: <3403C44F.2424@erols.com> X-Deja-AN: 268601794 References: <872172435.980@dejanews.com> <33FC66AD.9A0799D4@calfp.co.uk> <33FFA4B1.3543@flash.net> <3402A529.CCFDAC8C@calfp.co.uk> <3403940F.4154@pseserv3.fw.hac.com> Organization: Erol's Internet Services X-Received-On: 27 Aug 1997 06:05:01 GMT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-08-27T00:00:00+00:00 List-Id: 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