Re: Design by Contract

Re: Design by Contract

[Bertrand Meyer]

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

Re: Design by Contract

[Bertrand Meyer]

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

Re: Design by Contract

[Bertrand Meyer]

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

Re: Design by Contract

[Bertrand Meyer]

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

Re: Design by Contract

[Steve Stringfellow]

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

Re: Design by Contract

[Nick Leaton]

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

Re: Design by Contract

[Don Harrison]

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

Re: Design by Contract

[Patrick Doyle]

  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

Re: Design by Contract

[Ted Velkoff]

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

Re: Design By Contract

[Ted Velkoff]

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

Re: Design by Contract

[Matt Kennel (Remove 'NOSPAM' to reply)]

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?'"

Re: Design by Contract

[Robert Dewar]

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.

Re: Design by Contract

[Robert Dewar]

<<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 :-) :-)

Re: Design By Contract

[Jon S Anthony]

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

Re: Design by Contract

[Mark Bennison]

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

Re: Design by Contract

[Nick Leaton]

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

Re: Design By Contract

[W. Wesley Groleau x4923]

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

Re: Design By Contract

[Darren New]

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.

Re: Design By Contract

[Patrick Doyle]

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

Re: Design by Contract

[Robert Dewar]

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

Re: Design By Contract

[Robert Dewar]

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.

Re: Design By Contract

[Don Harrison]

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

Re: Design by Contract

[Don Harrison]

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

Re: Design by Contract

[Paul Johnson]

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.

Re: Design By Contract

[Patrick Doyle]

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

Re: Design By Contract

[Don Harrison]

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

Re: Design By Contract

[Jon S Anthony]

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

Re: Design By Contract

[Jon S Anthony]

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

Re: Design by Contract

[Matt Kennel (Remove 'NOSPAM' to reply)]

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?'"

Re: Design by Contract

[John F. Bell III]

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?'"

Re: Design By Contract

[Patrick Doyle]

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

Re: Design By Contract

[Patrick Doyle]

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

Re: Design By Contract

[Jon S Anthony]

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

Re: Design by Contract

[Ken Garlington]

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

Re: Design by Contract

[Ken Garlington]

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

Re: Design By Contract

[Joerg Rodemann]

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

Re: Design By Contract

[Jon S Anthony]

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

Re: Design By Contract

[Don Harrison]

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

Re: Design By Contract

[Don Harrison]

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

Re: Design By Contract

[Don Harrison]

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

Re: Design By Contract

[Jon S Anthony]

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

Re: Design by Contract

[Thomas Beale]

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

Re: Design by Contract

[Thomas Beale]

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

Re: Design By Contract

[Don Harrison]

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

Re: Design By Contract

[Paul Johnson]

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.

Re: Design By Contract

[Jon S Anthony]

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

Re: Design by Contract

[Ken Garlington]

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.

Re: Design By Contract

[Matthew Heaney]

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

Re: Design By Contract

[W. Wesley Groleau x4923]

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

Re: Design By Contract

[Jon S Anthony]

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

Re: Design By Contract

[Jon S Anthony]

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

Re: Design By Contract

[Nick Leaton]

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.

Re: Design by Contract

[Robert Dewar]

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). 

Re: Design by Contract

[Robert Dewar]

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 :-)

Re: Design By Contract

[Joachim Durchholz]

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.

Re: Design By Contract

[Patrick Doyle]

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

Re: Design By Contract

[Patrick Doyle]

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

Re: Design By Contract

[Jon S Anthony]

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

Re: Design By Contract

[Nick Leaton]

> 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

Re: Design By Contract

[Matthew Heaney]

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

Re: Design By Contract

[Matthew Heaney]

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

Re: Design By Contract

[Nick Leaton]

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.

Re: Design By Contract

[Paul Johnson]

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.

Re: Design By Contract

[Robert A Duff]

>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

Re: Design By Contract

[Paul Johnson]

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.