Re: Design By Contract

["W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com>]

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!
----------------------------------------------------------------------