comp.lang.ada
 help / color / mirror / Atom feed
* Re: Interface/Implementation (was Re: Design by Contract)
@ 1997-09-15  0:00 Marc Wachowitz
  1997-09-16  0:00 ` Owen Fellows
  0 siblings, 1 reply; 185+ messages in thread
From: Marc Wachowitz @ 1997-09-15  0:00 UTC (permalink / raw)



Nick <nickle@calfp.co.uk> wrote via Owen Fellows <ofellows@calfp.co.uk>
about supposedly "pure" OO a la Eiffel vs. Ada-like modules and types as
different concepts and non-method procedures:
> But it it more likely that you just inherit MATHEMATICIAN somewhere in
> your heirarchy to save on typing.

I find that totally unacceptable, as it creates much too strong coupling
between library modules and their clients. Adding new features to a library
module shouldn't force even the smallest change in any previously existing
clients. The same applies to unavoidable visibility of every parent feature
in children - to avoid potential clashes, one is forced to revert to using
long_feature_names_saying_they_are_only_for_class_X_and_not_for_children,
which is a shame for a somewhat recent language like Eiffel (even in old
K&R C you had private - aka static - functions/variables), in my view. The
point isn't so much about children touching conceptually private features
of parents where they shouldn't do that (though that does get "interesting"
in large projects with say, 50 to 100 programmers of varying quality, and
I'd rather have that checked, too), but about clean separation of concerns
and minimal coupling.

> Having the same implementation as inherits is a hint that it probably is
> inherits!

No more than the implementation of loops via conditional goto is a hint to
drop explicit loops from the language and only provide conditional goto (and
perhaps call/return) as control structure. I expect most people wouldn't
follow the latter reasoning (nor do I), and likewise I disagree with your
above suggestion. In fact, I'd already use inheritance much less than what
seems to be usual in the Eiffel world (if Bertrand Meyer's books are a hint
about general usage): Even if it means more writing, I prefer having a mere
client for an object via a field over implementation inheritance: As long as
the representation type can be used unchanged via its abstract interface,
I'll do so. If it's mostly right, but still no proper "is-a" relation holds,
I'll also seriously consider a different subclass with some small changes
for the different need, and then using this adaption as client in that new
type which really isn't a proper subtype. I find this to be much better at
decoupling, more explicit about the essential relations between those types,
and more readable for my taste. The counter-argument about inefficiency due
to another indirection doesn't hold, as the above is only about source level
stuff: If performance is critical, make the compiler sufficiently clever to
inline the respective data and operations for such cases, which should be
quite trivial. The counter-argument about needing all the facilities which
are used for inheritance again for import doesn't really work either, since
the usage of library modules with qualified names for feature access doesn't
need things like renaming, redefinition, re-export or hiding; simply write
e.g. Math.Sin(X) and stop worrying about name space pollution. (Well, you
do have to think about module names, which should ideally be a hierarchical
name space, similar to Ada child packages or Java packages, but it reduces
the amount of relevant names dramatically.)

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>




^ permalink raw reply	[flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract)
@ 1997-09-12  0:00 Marc Wachowitz
  1997-09-12  0:00 ` Joachim Durchholz
  1997-09-12  0:00 ` Samuel T. Harris
  0 siblings, 2 replies; 185+ messages in thread
From: Marc Wachowitz @ 1997-09-12  0:00 UTC (permalink / raw)




Joachim Durchholz <joachim.durchholz@munich.netsurf.de> wrote:
> Ada, if we have a name clash, we're forced to
> type the full module name wherever a clashing name is used (at least
> that's what I remember, corrections welcome!).

If you merely import a package, by means of a "with" clause, you cannot
get any name clashes at all, no matter what's in the package, since every
reference is qualified with the package name.

If you don't like some name, e.g. of a package or a type or a variable or
a routine or an exception, you can introduce another name for it (which
may be local, but can also be exported by a package). This can as well be
used to introduce non-qualified names specifically for that imported stuff
which you want, without being bothered by whatever else the package exports,
or might export in the future.

Only if you really call for it, by means of a "use" clause, all the stuff
exported by an imported package will become visible in the client's scope,
and thus be a potential source for name clashes (for routines only where
overloading can't resolve the conflict). Many people don't like use-clauses,
and some projects don't allow them. They are never necessary at all, only a
way to reduce typing (i.e. on the keybord, this isn't about type checking).

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>




^ permalink raw reply	[flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract)
@ 1997-09-09  0:00 Marc Wachowitz
  1997-09-15  0:00 ` Owen Fellows
  0 siblings, 1 reply; 185+ messages in thread
From: Marc Wachowitz @ 1997-09-09  0:00 UTC (permalink / raw)



"John G. Volan" <johnv@ac3i.dseg.ti.com> wrote:
> Eiffel doesn't care about the order in which things are declared, but it
> also lacks this notion of elaboration order.  So how does it handle
> intializing classwide globals?  I seem to recall something about "once"
> methods -- routines that get executed just once, the first time they are
> called.  The results are cached, and all subsequent calls just return
> the cached results.  Supposedly you can initialize classwide globals
> inside such methods.  Do I have that right?

There aren't any classwide (or other) "global variables" in the usual sense,
only once-methods. The cached result of a once-method acts as a kind of global
object; i.e. if you want a true "variable" to which you can assign later, you
use a once-method containing (directly or indirectly) a field which acts as
your variable; if you do only need the initial value again and again, you can
use it directly as result of the once-method. Note that a once-method, as any
other method in Eiffel, has to be invoked on some instance of its class, or
any of its subclasses.

This is based on the Eiffel philosophy that every computation must be based
on a method invocation for some object, and that independent variables or
routines would be bad. Even the creation methods must be called in relation
to an already created instance. The work-around (in my view - Eiffel fans
might praise it as something logical) for library-functions is to have clients
inherit from some class (or use other quite absurd tricks, based on classes
without fields) to get at something like mathematical functions which do in
fact only depend on their arguments, not on any "receiver". Thus the use of a
routine library tends to be modeled as inheriting from a class providing them.

(To Eiffel fans: Yes, I've read Bertrand Meyer's arguments for a "pure" object
oriented view, where classes are the only modules and where there aren't any
non-instance-related routines. Having pondered these things for some time now,
I don't agree at all, and prefer having non-class modules and some routines
which aren't related to any instances.)

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>




^ permalink raw reply	[flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract)
@ 1997-09-06  0:00 Ell
  1997-09-06  0:00 ` Samuel Mize
  0 siblings, 1 reply; 185+ messages in thread
From: Ell @ 1997-09-06  0:00 UTC (permalink / raw)




W. Wesley Groleau x4923 (wwgrol@pseserv3.fw.hac.com) wrote:
: 
: ... I was responding
: to those who want to deny that a good feature language X is not
: an advantage because language Y can accomplish the same thing by
: an unintended use of features it DOES have.  Those are the folks 
: that first brought up the idea.
: 
: It happens on the Ada side, too.  "Multiple inheritance is not
: important because we can simulate it this way."  What the Ada advocate
: should say is one of (1) "We think MI is bad because"  OR (2) "We
: looked at the _goal_ of multiple inheritance and decided that _goal_
: could be better acheived by..." OR (3) "OK, we'll let you have that 
: as an advantage of your language."

What's invalid about saying not saying (1), (2), or (3) and leaving things
"equal".  Certainly that situation _does_ exist.

Elliott
-- 
"The domain object model is the foundation of OOD."
"We should seek out proven optimal practices and use them."
See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell






^ permalink raw reply	[flat|nested] 185+ messages in thread
[parent not found: <EForKz.FJ7@ecf.toronto.edu>]
* Re: Safety-critical development in Ada and Eiffel
@ 1997-08-07  0:00 Ken Garlington
  1997-08-12  0:00 ` Don Harrison
  0 siblings, 1 reply; 185+ messages in thread
From: Ken Garlington @ 1997-08-07  0:00 UTC (permalink / raw)



Don Harrison wrote:
> 
> Ken Garlington wrote:
> 
> :Don Harrison wrote:
> :>
> :> Ken Garlington wrote:
> :>
> :> :Don Harrison wrote:
> :> :>
> :> :> What we want is a way to signal to the caller that they've made a mistake and
> :> :> need to take corrective action.
> :> :
> :> :If they don't know to check that they might have made a mistake,
> :>
> :> They *do* know because they get an exception.
> :
> :Not when they're _writing_ the code, unfortunately.
> 
> Yes, but we're not talking about writing the code. We're talking about execution.
> Even Smalltalkers can't write and execute at the same time. :)

Eiffel advocates need to decide: Is the primary value of assertions for
documentation
(as Meyer maintains) or to raise errors during execution (which has a
number of
drawbacks, including potentially postponing the detection of the problem
until well
after it is delivered).

> 
> :> :how do they know what corrective action they should take?
> :>
> :> To determine the right corrective action, they determine which specific
> :> (sub-)expression triggered the violation and work out the cause by conventional
> :> means, namely logical deduction.
> :
> :This brings up the second point. Why would a methodology/language go to
> :great lengths to _detect_ errors, but completely punt ("use conventional
> :means") to determine what to do _afterwards_?
> 
> DBC won't fix the errors for you. :)

No, but other methodologies do discuss error recovery techniques, and
how to
apply them. This is particularly important if the error won't be
uncovered
until after it is delivered.

> No tool can *think* for you. DBC does help identify and localise errors, but
> you're the one who must solve them.
> 
> :> :If the erroneous code is reused in another application, doesn't it carry
> :> :its error along with it?
> :>
> :> Yes, that's why it's important to fix it. :)
> :
> :Doesn't this erode the argument of using Eiffel to support reuse, if
> :errors
> :are so easily ported between applications?
> 
> No. If an error doesn't exist, it can't be ported.

Consider the Ariane case. The error didn't exist in the original
environment
(Ariane IV). The error only occured during execution in the Ariane 5
environment (a little too late to fix, unfortunately). Basing your
argument
on execution means that any latent error in the system, which might be
caught in other methodologies through the use of analysis and reviews,
will
be missed using DBC/Eiffel.

> 
> :> :What if the mistake is in your code, not the calling code?
> :>
> :> The context we're dicussing is a precondition, so I assume you mean a mistake
> :> in the precondition.  This will be obvious from the fact that the call is valid.
> :
> :Your code thinks the call is invalid. Who decides otherwise?
> 
> The developer running the program - by thinking.

Which is completely contradicted by the abve statements of using
assertions
for execution purposes.

The whole point of a methodology is to guide the thinking of an analyst.
It
doesn't sound like DBC/Eiffel has given you much in the way of guidance.

> 
> :> This is what I mean about the code proper validating assertions. (See my previous
> :> posts for details).
> :>
> :> :> What about case 2)? Here, we want to check that the work we delegated was
> :> :> done properly and acheived what we set out to do. In this case, we can
> :> :> perform some checks and raise and exception against ourselves to force us
> :> :> to fix the problem (possibly by delegating)..
> :> :>
> :> :>   procedure Assume_Control (Aircraft: Aircraft_Type) is
> :> :>   require not My_Aircraft.Mine (Aircraft)
> :> :>   begin
> :> :>     ...
> :> :>     My_Aircraft.Add (Aircraft);
> :> :>   ensure My_Aircraft.Mine (Aircraft)
> :> :>   end;
> :> :>
> :> :> which is our final solution. What we are now left with is a component of
> :> :> software that we know can only be executed under the intended conditions and
> :> :> can guarantee producing the required results.
> :> :
> :> :Assuming...
> :> :
> :> :1. My_Aircraft.Mine is correct. (How is this determined?
> :>
> :> Joachim has already mentioned code inspection.
> :
> :See my arguments related to manual inspection as the only safeguard
> :against
> :errors in large systems.
> 
> I'm not suggesting it should be.

More to the point, you haven't given any evidence that DBC/Eiffel has
any
particular advantage in this area.

> :> Also, if Mine is called anywhere in the code proper of the system and it has
> :> its own assertions, it will be validated by them.
> :
> :However, other posts have said that assertions shouldn't have
> :assertions.
> 
> We're talking about different things. See the OOSC-2 reference and my comments
> following for details..
> 
> :> However, these lower-level
> :> assertions won't be evaluated as part of higher-level assertion evaluation.
> :>
> :> (For details, see OOSC-2, Chapter 11 - "Design by Contract: Building Reliable
> :> Software", Page 400 ff.)
> :>
> :> In this sense, I suppose you could say there are "assertions about assertions" (meta-assertions). They help where they're needed most - where assertions are
> :> abstracted using boolean functions.
> 
> :> :2. Assume_Control is not called again with the same aircraft between the
> :> :   pre-condition and My_Aircraft.Add.
> :> :
> :> :3. Release_Control (I propose this as the opposite of Assume_Control) is
> :> :   not called between My_Aircraft.Add and the post-condition.
> :>
> :> Neither of these concurrency issues exist under SCOOP because the runtime system
> :> automatically locks objects on behalf of the thread using them. It's simply
> :> impossible to have concurrent access to an object by multiple threads.
> :
> :So, if an object is referenced by a thread, no other operations
> :associated with
> :the object can be called (object-locking, as opposed to
> :operation-locking)?
> 
> In theory, yes. In practice, I would expect SCOOP implementations to provide
> greater flexibility through optimisations (See below).
> 
> :Doesn't this cause a few latency problems? For example, it's usually OK
> :for
> :multiple reads to occur concurrently, so long as no write is in process.
> :SCOOP only permits sequential reads?
> 
> Optimisations could allow multiple concurrent queries (reads). The important
> is that exclusive access is *theoretically* guaranteed. What happens in practice
> doesn't matter so long as it's safe.

Has such automated optimization been done in practice? Isn't such an
optimization
on the same difficulty level as the toolset automatically generating the
correct assertions for each interface?

> 
> :> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 -
> :> "Accessing separate objects", Page 982 ff.)
> :>
> :> Ada, in contrast, does allow this - for example, if tasking is used in isolation.
> :> To overcome this deficiency, you have to either roll-your-own object protection
> :> (using semaphores, for example) or use protected objects. Using Ada protected
> :> objects is fine, but they lack the flexibility of Eiffel separate objects.
> :
> :Just the opposite!
> 
> Incorrect.

Eiffel separate objects always lock the object. Ada protected records
can lock the
object for a given operation or not (at the designer's preference), can
requeue
requests, etc. More choices for the designer usually means additional
flexibility, I would think.

> 
> :Protected objects, for example, would allow concurrent reads
> :if no timing issues result!
> 
> See above. You lose flexibility with protected types because they're not
> inheritable and can't be used polymorphically.

But you gain flexibility in their timing capabilities (which is what we
were
discussing, remember? :). Given that the purpose of a protected type is
to
define time-based aspects the system, isn't this the more valuiable
flexibility
for this type of object?

> 
> :> :4. There are no errors from other sources (e.g. extraneous code,
> :> :higher-tier
> :> :   documentation miscommunications).
> :>
> :> I've already covered the case of extraneous code in a previous post.
> :
> :Right - you said that you assume this won't happen.
> 
> No, I said something else.

You said that you did not provide exhaustive coverage via assertions. If
that
doesn't mean that you assume the condition will not occur, what does it
mean?
That you assume it will occur, but do not address it?

> 
> :> WRT documentation-related problems, these are outside the scope of any runtime
> :> error checking mechanism. DBC is *almost* a silver bullet but not quite. :)
> :
> :Is DBC a methodology, or a "runtime error checking mechanism"?
> 
> Both.

Then what does it matter what a "runtime error checking mechanism" does?
The question remains: How does DBC address documentation-related
problems?

> 
> :I certainly know
> :methodologies that will help uncover extraneous code, and
> :requirements/design
> :issues. In fact, some methodologies emphasize the ability to manage
> :requirements
> :and design, since that's where many of the really difficult errors
> :emerge.
> 
> I agree this is an important area.

Given that, then if DBC does not address this area, it must be
deficient.

> 
> :Someone needs to decide if DBC is a coding guideline or a software
> :development
> :methodology. My concern is that it is touted as the former, but used as
> :the latter.
> 
> I don't see any problem with using it as both.

However, there is a serious problem when practitioners use it (and
discuss it) in terms of the former. Note the number of times in this
post, for example, that DBC has been described in terms of concrete
capabilities when the subject is code execution, but only vaguely
(if at all) when described as a methodology. For example:

1. How, specifically, does DBC support error detection prior to
execution?
(Not writing down potential error sources, but actually determining if
the
error exists in the particular application.)

2. By extension, how does DBC support error detection after reuse?

3. For those errors not discovered (which will presumably cause run-time
exceptions), how does DBC guide the designer to handle these exceptions
(which were not expected to occur)?

4. How does DBC help detect inconsistencies between code and
requirements,
or for that matter internal consistencies within the requirements?

Given that we both agree (as noted earlier in the post) that the key is
for the designer to think, how does a coding convention support such
thinking - not in terms of general OO concepts like polymorphism and
inheritance (which other languages, including Ada, have) but in terms of
error detection and correction?

> 
> :> :Also: If the post-condition fails, who provides the corrective action?
> :>
> :> During development, you, the designer of the code (or your delegate) by fixing
> :> the problem. Additionally, in the case of critical software, you can add a
> :> rescue clause (exception handler) to keep the show on the road in production.
> :
> :So, the client has to figure out what to do if your code fails?
> 
> Who said anything about clients? I said the designer of the code containing
> the postcondition - that is, the *supplier* in Eiffel parlance.

Wait a minute! Here's the possible scenarios:

1. The post-condition fails during initial development. In this case,
the
developer of the code fixes the problem (or changes the post-condition,
as unfortunately sometimes happens). However, how often is the
post-condition
going to fail at this point? The developer writes both the code and the
post-condition, so it's likely that they will match at that point.

2. The post-condition fails after delivery. The developer may no longer
be around
to fix the problem. Furthermore, if there is a rescue clause, what does
it do?
What guidance does DBC provide.

3. The post-condition fails during reuse development. Same outcome as
#2. This
is the most likely case for a post-condition failing - where the
environment
in which the module is used changes.

Any methodology that postpones finding errors until the code is reused
is going
to be difficult to sell as "reuse-friendly".

> 
> My original example, reinserted..
> 
> :  procedure Assume_Control (Aircraft: Aircraft_Type) is
> :  require not My_Aircraft.Mine (Aircraft)
> :  begin
> :    ...
> :    My_Aircraft.Add (Aircraft);
> :  ensure My_Aircraft.Mine (Aircraft)
> :  end;
> 
> :> :Also: If My_Aircraft.Add is provided by a different programmer/team than
> :> :Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)?
> :>
> :> It doesn't matter. What's your point?..
> :
> :It matters a lot! Again, if each team assumes the other does the call,
> :this is bad news.
> 
> Correct me if I have this wrong, but you seem to be worried about too few checks
> and too many checks.
> 
> WRT too few checks, it's always the responsibility of the client to make sure
> the precondition is met. So, a check will always be made.

Hasn't this whole discussion been in terms of how to detect errors in
the code?
Isn't it a little naive to assume that the code will be written
correctly as a
precondition for finding errors in the code?

For that matter, if it's the client's responsibility, and it doesn't
hurt if
the assertion is not performed by the object being used, then doesn't
this
cut the legs out of an argument of Eiffel's power? Pretty much any
language
can provide assertions for the client to manually call prior to using an
operation.

> 
> WRT too many checks, an implementation may optimise out any redundant checks
> - for example if a precondition check is already done by a caller. This minimises
> the number of redundant checks.

You're assuming a lot about automated optimizations across object
interface
boundaries. Is there evidence that Eiffel compilers do such
optimizations
successfully? Worse, you're again in the "proof by execution" mode. What
does
this extra code do in terms of readability, for example?

> :If both teams do the call, this is not nice from a
> :efficiency standpoint.
> 
> See above.

Ditto. Any methodology that says, "Write as much code as you want, the
compiler will optimize it" doesn't seem to be a strong methodology, in
my opinion.

> 
> :> Other classes of error may be identified through other means that
> :> you're already well acquanted with.
> :
> :Furthermore, the classes of error to which DBC is limited are
> :well-covered
> :through other means (beat to death, in fact).
> 
> The difference is it does a better job of it.

We'll just have to agree to disagree on this one. Again, I would rather
have a methodology that helps me think about the issues vs. coding them.

> 
> :So, I'm still at a loss to
> :see what DBC brings to the table here. It doesn't address my main
> :problem (requirements/design faults),
> 
> Not entirely true. DBC can highlight specification/design inconsistencies.
> (See my previous posts). Otherwise, I agree.

I saw your previous posts. I quote from the line above:

  "WRT documentation-related problems, these are outside the scope of
  any runtime error checking mechanism. DBC is *almost* a silver bullet
  but not quite."

Please summarize your arguments/evidence that DBC helps find
documentation-
related problems.

> 
> :it has limitations with respect to implementation language,
> 
> More accurate is to say that most languages provide limited support for it.

Two responses:

1. I was discussing limitations in Eiffel, and

2. Other Eiffel experts disagree with you with regard to other
languages:

See the post on Internet newsgroup comp.lang.eiffel "Re: Papers on the
Ariane-5
crash and Design by Contract," Jean-Marc Jezequel, 1997/03/18: "Ada's
subtype
declarations are a kind of contract, that could be documented as such.
Design
by contract is not specific to Eiffel. You can do it with any language,
just
because it is a way of designing!"

> 
> :it's not clear that it scales well,
> 
> Not true.

Can you provide evidence to the contrary?

See Internet newsgroup comp.lang.eiffel post "Re: Papers on the
Ariane-5 crash and Design by Contract," Jean-Marc Jezequel,
1997/03/18: "...at least in the case of Ariane 501, simple assertions
(a la Eiffel and other languages) would have been expressive enough to
specify the fatal hidden assumption. Whether the last point scales up
to a full sized mission critical system is still an open question.
I'm quite confident it is so, but I've only my own experience with telco
systems to back it up."

> 
> :and it doesn't appear to be internally complete (big on error detection
> :mechanisms, not much on how to derive the particular error sources,
> 
> That's because they're typically blindingly obvious! Why? Because error detection
> is more localised.

But interface errors, by definition, are not localized. They are
generated
due to the interaction between objects (in some cases, a long thread of
object interactions). The Ariane 5 case is a perfect example of this.

Requirements/design mismatches, similarly, are not localized since the
requirements are usually not written in terms of objects. One of the
designer's jobs is to map the requirements to objects. Even for
requirements that are object-oriented, they are usually a much higher
level than the implementation.

Again, you're thinking of run-time error detection. This is the worst
place
to detect errors. Consider, for example, the errors made in the Eiffel
implementation of the scaling routine presented in their Ariane paper.
If these errors were "blindingly obvious", why did it take a year for
anyone to say anything about them?

> 
> :and not much on what to do after the error is detected, for example).
> 
> Again, this is usually blindingly obvious.

Any time someone says something is obvious, without any evidence or
argument to support it, I pretty much assume that the point is ceded.
I will say that if error recovery is blindingly obvious, then there's
a lot of work in the fault tolerance world that's apparently just a
waste of money. :)

> 
> All of these points have been made before.

Unfortunately, I think you're right. It doesn't seem as though we're
communicating very effectively. I'll concede the argument to you.

> 
> Don.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Don Harrison             donh@syd.csa.com.au




^ permalink raw reply	[flat|nested] 185+ messages in thread
end of thread, other threads:[~1997-10-13  0:00 UTC | newest]

Thread overview: 185+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <01bcb389$24f579d0$1c10d30a@ntwneil>
1997-08-28  0:00 ` Interface/Implementation (was Re: Design by Contract) Tucker Taft
1997-08-29  0:00   ` Paul Johnson
1997-08-29  0:00     ` Jon S Anthony
     [not found]       ` <EFqDC8.342@ecf.toronto.edu>
1997-09-02  0:00         ` Samuel Mize
1997-09-03  0:00           ` Patrick Doyle
1997-09-03  0:00             ` Samuel Mize
1997-09-03  0:00           ` Paul Johnson
1997-09-04  0:00           ` Erik Ernst
1997-09-05  0:00           ` Robert Dewar
     [not found]           ` <EFyrH2.7z2@syd.csa.com.au>
1997-09-04  0:00             ` W. Wesley Groleau x4923
1997-09-05  0:00               ` Jon S Anthony
1997-09-06  0:00                 ` Patrick Doyle
1997-09-06  0:00                   ` Jon S Anthony
1997-09-05  0:00               ` Patrick Doyle
1997-09-05  0:00                 ` W. Wesley Groleau x4923
1997-09-06  0:00                   ` Patrick Doyle
1997-09-05  0:00               ` Don Harrison
1997-09-05  0:00                 ` W. Wesley Groleau x4923
1997-09-06  0:00                   ` Joachim Durchholz
1997-09-09  0:00                   ` Robert Dewar
1997-09-09  0:00                     ` Richard Kenner
1997-09-10  0:00                     ` Tucker Taft
1997-09-10  0:00                       ` Nick Leaton
1997-09-10  0:00                         ` W. Wesley Groleau x4923
1997-09-11  0:00                         ` Code ordering Steve Furlong
1997-09-12  0:00                         ` Interface/Implementation (was Re: Design by Contract) Robert Dewar
1997-09-12  0:00                           ` Nick Leaton
1997-09-10  0:00                       ` Joachim Durchholz
1997-09-10  0:00                       ` One pass compilation? W. Wesley Groleau x4923
1997-09-11  0:00                       ` Interface/Implementation (was Re: Design by Contract) Robert Dewar
1997-09-05  0:00                 ` Jon S Anthony
1997-09-06  0:00                   ` Fergus Henderson
1997-09-06  0:00                     ` Jon S Anthony
1997-09-08  0:00                 ` Robert Dewar
1997-09-11  0:00                   ` Don Harrison
1997-09-12  0:00                     ` Robert Dewar
1997-09-08  0:00                 ` Robert Dewar
1997-09-11  0:00                   ` Don Harrison
1997-09-04  0:00             ` Joerg Rodemann
1997-09-05  0:00               ` Don Harrison
     [not found]                 ` <340fdb9f.0@news.uni-ulm.de>
1997-09-06  0:00                   ` Joachim Durchholz
1997-09-06  0:00               ` Joachim Durchholz
1997-09-05  0:00             ` Matthew Heaney
1997-09-06  0:00               ` Joachim Durchholz
1997-09-06  0:00               ` Patrick Doyle
1997-09-06  0:00                 ` Matthew Heaney
1997-09-06  0:00                 ` Matthew Heaney
1997-09-07  0:00                   ` Patrick Doyle
1997-09-07  0:00                     ` Matthew Heaney
1997-09-10  0:00                       ` Don Harrison
1997-09-10  0:00                         ` Matthew Heaney
1997-09-10  0:00                         ` Samuel Mize
1997-09-10  0:00                           ` Samuel Mize
1997-09-11  0:00                           ` Don Harrison
1997-09-11  0:00                           ` Robert Dewar
1997-09-12  0:00                             ` Samuel T. Harris
1997-09-12  0:00                             ` Samuel Mize
1997-09-13  0:00                               ` Tucker Taft
1997-09-17  0:00                             ` Don Harrison
1997-09-18  0:00                               ` Robert Dewar
1997-09-10  0:00                         ` Patrick Doyle
1997-09-16  0:00                           ` Don Harrison
1997-09-18  0:00                             ` Robert Dewar
1997-09-18  0:00                               ` Shmuel (Seymour J.) Metz
1997-09-20  0:00                                 ` Robert Dewar
1997-09-10  0:00                         ` Tucker Taft
1997-09-10  0:00                           ` Matthew Heaney
1997-09-10  0:00                             ` Patrick Doyle
1997-09-12  0:00                               ` Robert Dewar
1997-09-13  0:00                                 ` Patrick Doyle
1997-09-11  0:00                             ` Lee Webber
1997-09-15  0:00                               ` W. Wesley Groleau x4923
1997-09-12  0:00                             ` Don Harrison
1997-09-10  0:00                           ` Don Harrison
1997-09-12  0:00                             ` Robert Dewar
1997-09-16  0:00                               ` Don Harrison
1997-09-17  0:00                                 ` Robert Dewar
1997-09-11  0:00                         ` Robert Dewar
1997-09-10  0:00                     ` Robert Dewar
1997-09-10  0:00                       ` Nick Leaton
1997-09-16  0:00                       ` Frederic Guerin
1997-09-06  0:00               ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-06  0:00                 ` Jon S Anthony
1997-09-08  0:00               ` John G. Volan
1997-09-09  0:00                 ` Nick Leaton
1997-09-09  0:00                   ` John G. Volan
1997-09-10  0:00                     ` Nick Leaton
1997-09-10  0:00                       ` Samuel Mize
1997-09-09  0:00                 ` Paul Johnson
     [not found]               ` <dewar.873826570@merv>
1997-09-09  0:00                 ` Matthew Heaney
1997-09-11  0:00                   ` Robert Dewar
1997-09-07  0:00             ` Robert Dewar
1997-09-08  0:00               ` Patrick Doyle
1997-09-09  0:00               ` Don Harrison
1997-09-09  0:00                 ` W. Wesley Groleau x4923
1997-09-10  0:00                 ` Robert Dewar
1997-09-11  0:00                   ` Don Harrison
1997-09-12  0:00                     ` Robert Dewar
1997-09-16  0:00                       ` Don Harrison
1997-09-17  0:00                         ` Robert Dewar
1997-09-01  0:00   ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-02  0:00     ` Nick Leaton
1997-09-03  0:00       ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-15  0:00 Marc Wachowitz
1997-09-16  0:00 ` Owen Fellows
  -- strict thread matches above, loose matches on Subject: below --
1997-09-12  0:00 Marc Wachowitz
1997-09-12  0:00 ` Joachim Durchholz
1997-09-12  0:00 ` Samuel T. Harris
1997-09-12  0:00   ` Jon S Anthony
1997-09-15  0:00     ` Samuel T. Harris
1997-09-16  0:00       ` Jon S Anthony
1997-09-09  0:00 Marc Wachowitz
1997-09-15  0:00 ` Owen Fellows
1997-10-13  0:00   ` Bill Foote
1997-09-06  0:00 Ell
1997-09-06  0:00 ` Samuel Mize
     [not found] <EForKz.FJ7@ecf.toronto.edu>
1997-09-01  0:00 ` Don Harrison
1997-09-02  0:00   ` Don Harrison
1997-08-07  0:00 Safety-critical development in Ada and Eiffel Ken Garlington
1997-08-12  0:00 ` Don Harrison
1997-08-25  0:00   ` Design by Contract Bertrand Meyer
     [not found]     ` <3402d123.0@news.uni-ulm.de>
1997-08-26  0:00       ` Nick Leaton
     [not found]         ` <3402e51d.0@news.uni-ulm.de>
     [not found]           ` <3402E8C9.3384D976@calfp.co.uk>
     [not found]             ` <dewar.872631036@merv>
     [not found]               ` <3403F668.F6B57D97@calfp.co.uk>
     [not found]                 ` <34041331.0@news.uni-ulm.de>
     [not found]                   ` <3404696D.4487EB71@eiffel.com>
1997-08-27  0:00                     ` Interface/Implementation (was Re: Design by Contract) Bertrand Meyer
     [not found]                       ` <34048FDC.13728473@eiffel.com>
1997-08-27  0:00                         ` Bertrand Meyer
1997-08-28  0:00                           ` Jon S Anthony
1997-08-29  0:00                             ` Robert Dewar
     [not found]                             ` <EForsv.Fqo@ecf.toronto.edu>
     [not found]                               ` <JSA.97Aug29191413@alexandria.organon.com>
     [not found]                                 ` <EFqDAG.2zn@ecf.toronto.edu>
1997-08-30  0:00                                   ` Jon S Anthony
1997-09-02  0:00                                   ` Don Harrison
1997-09-02  0:00                                     ` Jon S Anthony
1997-09-03  0:00                                       ` Don Harrison
     [not found]                                     ` <EFwuzD.BxE@ecf.toronto.edu>
1997-09-04  0:00                                       ` John G. Volan
1997-09-04  0:00                                         ` W. Wesley Groleau x4923
1997-09-05  0:00                                           ` Patrick Doyle
1997-09-05  0:00                                             ` W. Wesley Groleau x4923
1997-09-06  0:00                                               ` Patrick Doyle
1997-09-08  0:00                                               ` Paul Johnson
1997-09-06  0:00                                             ` Jon S Anthony
1997-09-08  0:00                                           ` Robert Dewar
1997-09-09  0:00                                             ` Robert S. White
1997-09-09  0:00                                             ` Paul Johnson
1997-09-11  0:00                                               ` Robert Dewar
1997-09-11  0:00                                                 ` Veli-Pekka Nousiainen
1997-09-12  0:00                                                 ` Paul Johnson
1997-09-14  0:00                                                   ` Ken Garlington
1997-09-09  0:00                                             ` Patrick Doyle
1997-09-09  0:00                                               ` Matthew Heaney
1997-09-10  0:00                                                 ` Patrick Doyle
1997-09-09  0:00                                           ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-10  0:00                                             ` John Viega
1997-09-10  0:00                                               ` Matt Kennel (Remove 'NOSPAM' to reply)
1997-09-05  0:00                                         ` Franck Arnaud
1997-09-05  0:00                                         ` Patrick Doyle
1997-09-04  0:00                                       ` Don Harrison
1997-09-05  0:00                                         ` Patrick Doyle
1997-09-09  0:00                                           ` Don Harrison
1997-09-09  0:00                                             ` W. Wesley Groleau x4923
1997-09-10  0:00                                               ` Veli-Pekka Nousiainen
1997-09-10  0:00                                                 ` Samuel Mize
1997-09-12  0:00                                               ` Don Harrison
1997-09-10  0:00                                             ` Patrick Doyle
1997-09-10  0:00                                               ` Joerg Rodemann
1997-09-10  0:00                                                 ` Joachim Durchholz
1997-09-12  0:00                                                   ` Joerg Rodemann
1997-09-10  0:00                                                 ` Patrick Doyle
1997-09-11  0:00                                                   ` Matt Austern
1997-09-12  0:00                                                     ` Jon S Anthony
1997-09-13  0:00                                                     ` Patrick Doyle
1997-09-11  0:00                                               ` Robert S. White
1997-09-11  0:00                                                 ` Don Harrison
1997-09-12  0:00                                                 ` Robert Dewar
1997-09-13  0:00                                                 ` Patrick Doyle
1997-09-12  0:00                                               ` Jon S Anthony
1997-09-13  0:00                                                 ` Patrick Doyle
1997-09-16  0:00                                                   ` Brian Rogoff
1997-08-28  0:00                           ` Patrick Doyle
1997-08-28  0:00                             ` W. Wesley Groleau x4923
1997-08-28  0:00                       ` Tucker Taft
1997-08-28  0:00                         ` W. Wesley Groleau x4923
1997-08-28  0:00                           ` Jon S Anthony
1997-08-29  0:00                             ` Suzanne Zampella
1997-08-29  0:00                               ` Jon S Anthony
     [not found]                             ` <EFnK8D.Lsv@ecf.toronto.edu>
1997-08-29  0:00                               ` Jon S Anthony
1997-08-30  0:00                                 ` Patrick Doyle
1997-08-30  0:00                                   ` Jon S Anthony
1997-09-01  0:00                                     ` Patrick Doyle
     [not found]                             ` <340E9BA2.32B3@rbgg252.rbg1.siemens.de>
1997-09-07  0:00                               ` Robert Dewar
     [not found]                         ` <3406A707.787D@dmu.ac.uk>
1997-08-29  0:00                           ` Joerg Rodemann
1997-08-29  0:00                             ` Ralph Paul
1997-09-01  0:00                           ` Don Harrison

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox