Re: Interface/Implementation (was Re: Design by Contract)

Re: Interface/Implementation (was Re: Design by Contract)

[Bertrand Meyer]

Here is the reasoning behind the Eiffel approach to
separating interface from implementation. It was designed
in full knowledge of the Modula-2/Ada-83 mechanisms, in an
attempt to draw the lessons of both their advantages and
limitations, taking advantage of newer software technology
and of O-O principles.

The goals are clear:

        G1. Allow people to consider separately the
            interface and the implementation of a module
            -- class in Eiffel, module in Modula, package
            in Ada.

        G2.(Closely related to G1.) Allow a developer
            to write a client class of a class C without
            knowing what C's implementation is, or even
            prior to the existence of such an implementation,
            as long as C's interface is known.

	G3 (Closely related to G2.) Allow a project leader
	   to restrict the list of who can access the
	   implementation of a module, allowing others access
	   to the interface only. This is also of interest
	   to vendors of reusable components, who may want
	   to make source not available to their customers
	   in some or all cases. (Whether this is good or
	   bad is another topic; it is a fact that some
	   vendors want this possibility.)

        G4. Allow multiple implementations of a given
            interface, including the possibility for
            clients to switch easily and implicitly
            between various implementations at run time
            (not possible, at least not possible simply,
            in Modula/Ada). This of course will take advantage
            of polymorphism and dynamic binding.

        G5. Minimize the programmer's work. In particular
            it is crucial to avoid forcing the programmer
            to duplicate text. Duplication is almost always
            bad, especially with respect to ease of maintenance,
            one of the central goals of software engineering.
            It also hampers reuse, reliability (when you
            duplicate code, you duplicate its bugs, and
            the more software you write the more likely
            it is that it will include bugs), and ease
            of change.

        G6. Favor seamlessness: the Eiffel method emphasizes
            the notion of a "single product" around which
            all software development activities revolve.
            This is in opposition to the traditional
            multi-product view ("the analysis", "the
            design",  "the documentation", "the code"
            -- including ,for the latter,
            "the interface", "the implementation").
            We may not always succeed in putting
            everything into one place (i.e. we will probably
            retain the need for some external documentation)
            but will try to get as close as possible to this
            goal; the benefits for the software process
            are enormous.

The Eiffel policy is a result of these considerations:

        E1. If a class has a single implementation, write
            everything at the same place: interface and
            implementation. This directly addresses 
            requirements G5 and G6 and differs markedly
            from the Modula, Ada etc. practice of
            writing the interface twice (once in the
            interface part, once in the body), which in
            my opinion is a nuisance, not just because
            of the initial duplication of work but because
            of the added maintenance burden.

        E2. Provide tools in the environment to produce
            the interface of a class, automatically from
            the class text. In Eiffel environments this is the
            role of the short and flat-short tools, which
            reconstruct the interface from the class.
            In ISE Eiffel you click on the "short" or
            "flat-short" icons of a Class Tool and the
            contents change to show the interface,
            pretty-printed, or in HTML format (with
	    references to other classes turned into
	    hyperlinks), RTF, FrameMaker etc.

        E3. A generalization of E2 follows from the
            observation that instead of just
            "implementation" and "interface" we should be
            talking about various *views* of a class, and
            rely on the power of the *computer* to produce
            these views as we need them.
            The implementation is one such view; the interface
            is another; but there are more. Short and flat-short
            are indeed examples of different abstract views
            (short considers only the features introduced
            in the class; flat-short integrates inherited
            features too). An environment can also provide
            many intermediate views, such as "the features
            available to a client class C" (i.e. the interface
            of the class as viewed by the author of C),
            "the interface as available to a descendant
            class", etc. This is only possible because we
            do NOT require the class author to write the
            interface separately; generalized, this idea
            would become absurd since it would mean that
            you have to write lots of different interfaces
            (views) for each class. Instead, the Eiffel view
            is that you should write the class -- the single
            product, see goal G6 -- and concentrate on
            equipping it with everything that it needs:
            useful features, complete preconditions,
            expressive postconditions, insightful class
            invariants, efficient implementations. You don't
            want to be bothered by e.g. having to write
            routine interfaces twice.
            Then if you or one of your client authors needs
            information about apecific properties of the
            class you will rely on tools to get it.

            Like many other differences with common languages,
            this Eiffel policy results from a difference of
            appreciation as to what should be done by humans
            and what by the computer. We want to let humans
            concentrate on creative, insightful work (e.g.
            designing a class), and rely on the computer
            for automatable and potentially tedious tasks.
            It is the same spirit that explains Eiffel's
            policy (in contrast variously with Ada, C++
            etc.) with respect to dynamic binding, garbage
            collection, routine inlining (in the ISE
            implementation), etc.

        E4. There remains the case in which you do want to
            write the interface as a separate module, because
            it can have several implementations. The technique
            then is easy: write it as a deferred class; then
            the various implementations can inherit from it.
            But then it will truly deserve to be called a
            "specification" (the Ada term) because, unlike
            other languages, Eiffel makes it possible to
            attach true semantic properties to the components
            of a deferred class: routine preconditions, routine
            postconditions, class invariants. (This is missing
            from Ada "specifications" and Java "interfaces"
            and, in my opinion, regrettably limits their 
            usefulness.) These specification elements
            are binding on all redeclarations in descendant
            classes ("effectings" in Eiffel terminology,
            i.e. a descendant providing an actual implementation
            for a feature that in the parent was deferred,
            i.e. specified but not implemented).

        E5. In case E4, it is of course possible to switch
            at run time between the various alternative
            implementations provided, thanks to polymorphism
            and dynamic binding. If I have t: TABLE [SOME_TYPE]
            where TABLE has various descendants providing
            alternative table implementations, I can write

                  t.search (some element)
        
            without knowing what kind of table `t' denotes
            (although I know it can only be a table, thanks
            to the type rules). Then various executions of the
            call, including during the same session of the system,
            can refer to different implementations and
            consequently use different versions of `search',
            automatically selected by the dynamic binding
            mechanism so that they will always be the appropriate
            one in each case.

        E5. Sometimes you may start out with a concrete
            class of which you consider only one possible
            implementation (case E1), and hence not bother
            to write a separate deferred class. Then later
            you may realize that you need other implementations
            too. Then the switch to case E4 is easy: just
            use a "short"-like tool to produce a deferred class
            from the original and rewrite that original to
            inherit from the deferred class. This is an
            easy change and in particular is painless for
            the existing client classes, since they only
            relied on the interface (as produced by short
            or flat-short) and hence will not be affected
            at all by the change; they may not even have
            to be recompiled. This is a direct implementation
            of information hiding principles.

	E6. An Eiffel implementation may permit the author of
	    a class library to make it available precompiled,
	    without giving access to the source. (This is
	    the case with ISE Eiffel 4.) The short and
	    flat-short forms are of course available through
	    the tools of the environment. This directly
	    addresses goal G3.
        
In short, the Eiffel approach proceeds from the same general
ideas as the technique of "separating interface from
implementation" but goes further; it considers the
whole software engineering picture, takes into account
the problems encountered with the Modula-Ada approach,
and of course takes advantage of object technology.

These issues are discussed in more detail in "Object-Oriented
Software Construction, 2nd edition" (Prentice Hall);
see in particular chapter 23, "Principles of Class Design",
pages 747-808.


-- 
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: Interface/Implementation (was Re: Design by Contract)

[Bertrand Meyer]

(This is a revised version as I had forgotten point E8.)

Here is the reasoning behind the Eiffel approach to
separating interface from implementation. It was designed
in full knowledge of the Modula-2/Ada-83 mechanisms, in an
attempt to draw the lessons of both their advantages and
limitations, taking advantage of newer software technology
and of O-O principles.

The goals are clear:

        G1. Allow people to consider separately the
            interface and the implementation of a module
            -- class in Eiffel, module in Modula, package
            in Ada.

        G2.(Closely related to G1.) Allow a developer
            to write a client class of a class C without
            knowing what C's implementation is, or even
            prior to the existence of such an implementation,
            as long as C's interface is known.

        G3 (Closely related to G2.) Allow a project leader
           to restrict the list of who can access the
           implementation of a module, allowing others access
           to the interface only. This is also of interest
           to vendors of reusable components, who may want
           to make source not available to their customers
           in some or all cases. (Whether this is good or
           bad is another topic; it is a fact that some
           vendors want this possibility.)

        G4. Allow multiple implementations of a given
            interface, including the possibility for
            clients to switch easily and implicitly
            between various implementations at run time
            (not possible, at least not possible simply,
            in Modula/Ada). This of course will take advantage
            of polymorphism and dynamic binding.

        G5. Minimize the programmer's work. In particular
            it is crucial to avoid forcing the programmer
            to duplicate text. Duplication is almost always
            bad, especially with respect to ease of maintenance,
            one of the central goals of software engineering.
            It also hampers reuse, reliability (when you
            duplicate code, you duplicate its bugs, and
            the more software you write the more likely
            it is that it will include bugs), and ease
            of change.

        G6. Favor seamlessness: the Eiffel method emphasizes
            the notion of a "single product" around which
            all software development activities revolve.
            This is in opposition to the traditional
            multi-product view ("the analysis", "the
            design",  "the documentation", "the code"
            -- including ,for the latter,
            "the interface", "the implementation").
            We may not always succeed in putting
            everything into one place (i.e. we will probably
            retain the need for some external documentation)
            but will try to get as close as possible to this
            goal; the benefits for the software process
            are enormous.

The Eiffel policy is a result of these considerations:

        E1. If a class has a single implementation, write
            everything at the same place: interface and
            implementation. This directly addresses 
            requirements G5 and G6 and differs markedly
            from the Modula, Ada etc. practice of
            writing the interface twice (once in the
            interface part, once in the body), which in
            my opinion is a nuisance, not just because
            of the initial duplication of work but because
            of the added maintenance burden.

        E2. Provide tools in the environment to produce
            the interface of a class, automatically from
            the class text. In Eiffel environments this is the
            role of the short and flat-short tools, which
            reconstruct the interface from the class.
            In ISE Eiffel you click on the "short" or
            "flat-short" icons of a Class Tool and the
            contents change to show the interface,
            pretty-printed, or in HTML format (with
            references to other classes turned into
            hyperlinks), RTF, FrameMaker etc.

        E3. A generalization of E2 follows from the
            observation that instead of just
            "implementation" and "interface" we should be
            talking about various *views* of a class, and
            rely on the power of the *computer* to produce
            these views as we need them.
            The implementation is one such view; the interface
            is another; but there are more. Short and flat-short
            are indeed examples of different abstract views
            (short considers only the features introduced
            in the class; flat-short integrates inherited
            features too). An environment can also provide
            many intermediate views, such as "the features
            available to a client class C" (i.e. the interface
            of the class as viewed by the author of C),
            "the interface as available to a descendant
            class", etc. This is only possible because we
            do NOT require the class author to write the
            interface separately; generalized, this idea
            would become absurd since it would mean that
            you have to write lots of different interfaces
            (views) for each class. Instead, the Eiffel view
            is that you should write the class -- the single
            product, see goal G6 -- and concentrate on
            equipping it with everything that it needs:
            useful features, complete preconditions,
            expressive postconditions, insightful class
            invariants, efficient implementations. You don't
            want to be bothered by e.g. having to write
            routine interfaces twice.
            Then if you or one of your client authors needs
            information about apecific properties of the
            class you will rely on tools to get it.

            Like many other differences with common languages,
            this Eiffel policy results from a difference of
            appreciation as to what should be done by humans
            and what by the computer. We want to let humans
            concentrate on creative, insightful work (e.g.
            designing a class), and rely on the computer
            for automatable and potentially tedious tasks.
            It is the same spirit that explains Eiffel's
            policy (in contrast variously with Ada, C++
            etc.) with respect to dynamic binding, garbage
            collection, routine inlining (in the ISE
            implementation), etc.

        E4. There remains the case in which you do want to
            write the interface as a separate module, because
            it can have several implementations. The technique
            then is easy: write it as a deferred class; then
            the various implementations can inherit from it.
            But then it will truly deserve to be called a
            "specification" (the Ada term) because, unlike
            other languages, Eiffel makes it possible to
            attach true semantic properties to the components
            of a deferred class: routine preconditions, routine
            postconditions, class invariants. (This is missing
            from Ada "specifications" and Java "interfaces"
            and, in my opinion, regrettably limits their 
            usefulness.) These specification elements
            are binding on all redeclarations in descendant
            classes ("effectings" in Eiffel terminology,
            i.e. a descendant providing an actual implementation
            for a feature that in the parent was deferred,
            i.e. specified but not implemented).

        E5. In case E4, it is of course possible to switch
            at run time between the various alternative
            implementations provided, thanks to polymorphism
            and dynamic binding. If I have t: TABLE [SOME_TYPE]
            where TABLE has various descendants providing
            alternative table implementations, I can write

                  t.search (some element)
        
            without knowing what kind of table `t' denotes
            (although I know it can only be a table, thanks
            to the type rules). Then various executions of the
            call, including during the same session of the system,
            can refer to different implementations and
            consequently use different versions of `search',
            automatically selected by the dynamic binding
            mechanism so that they will always be the appropriate
            one in each case.

        E6. Sometimes you may start out with a concrete
            class of which you consider only one possible
            implementation (case E1), and hence not bother
            to write a separate deferred class. Then later
            you may realize that you need other implementations
            too. Then the switch to case E4 is easy: just
            use a "short"-like tool to produce a deferred class
            from the original and rewrite that original to
            inherit from the deferred class. This is an
            easy change and in particular is painless for
            the existing client classes, since they only
            relied on the interface (as produced by short
            or flat-short) and hence will not be affected
            at all by the change; they may not even have
            to be recompiled. This is a direct implementation
            of information hiding principles.

        E7. An Eiffel implementation may permit the author of
            a class library to make it available precompiled,
            without giving access to the source. (This is
            the case with ISE Eiffel 4.) The short and
            flat-short forms are of course available through
            the tools of the environment. This directly
            addresses goal G3.
       

        E8. An interface-implementation separation a la
            Modula or Java gives you only two kinds of
            modules: fully implemented versions (the bodies
            of packages) and headers without any implementation
            at all (package specifications; also Java
            "interfaces"). This is too restrictive. With
            Eiffel's deferred classes you have the whole
            spectrum: fully implemented (a class with no
            deferred features), fully abstract (a class
            with only deferred features), but also partially
            implemented. This is one of the key mechanisms
            of object technology, and without it one is
            severely constrained. A typical example is class
            COMPARABLE from the Eiffel Library Kernel Standard
            (ELKS) which describes order relations. Feature
            infix "<" is deferred; but the others, such as
            ">", "<=", ">=" are not, and they should not be,
            since they can be defined in terms of "<" and
            equality (for example a > b is defined as b < a).
            You can't do that with pure interfaces.

In short, the Eiffel approach proceeds from the same general
ideas as the technique of "separating interface from
implementation" but goes further; it considers the
whole software engineering picture, takes into account
the problems encountered with the Modula-Ada approach,
and of course takes advantage of object technology.

These issues are discussed in more detail in "Object-Oriented
Software Construction, 2nd edition" (Prentice Hall);
see in particular chapter 23, "Principles of Class Design",
pages 747-808.
 
-- 
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: Interface/Implementation (was Re: Design by Contract)

[Tucker Taft]

Neil Wilson (nobody@nobody.com) wrote:

: Tucker Taft <stt@houdini.camb.inmet.com> wrote in article
: <EFLp4n.HJC.0.-s@inmet.camb.inmet.com>...
: > In my experience, separating the spec and body physically is
: > extremely advantageous, and the need to have redundancy between
: > the spec and body is an important feature in a multi-person
: > project, not an "inconvenience."  In Ada (and to some extent in C/C++

: Then do it. This is what fully deferred (or even partially deferred)
: classes do in Eiffel. You can even lock down the specification by providing
: only the Precompiled version to your implementors (or more simply lock out
: the deferred class file using file permissions).

One can always argue both sides of an issue like this.  

   1) Our language forces you to separate spec and body, and
      that is good.

   2) Our language allows you to separate spec and body, but
      doesn't force you to, so that is good.

Perhaps a more relevant question is what style "real" programmers
adopt when they use the language, and how this affects the
productivity, maintainability, readability, etc., of code
built in that language.

Note that the Eiffel folks argue exactly the opposite when they
talk about "purity" of OO languages, saying that Eiffel *forces*
you to put everything in a class, and that is good, whereas the
Ada folks say that Ada *allows* you to only use tagged types,
but doesn't force you to, so that is good.

Similarly, Eiffel forces you to only have exception handlers
at the top-level of an operation (which never seemed "good"
to me, but perhaps because I don't understand the full argument
in favor of this requirement), whereas Ada allows you to place
exception handlers as locally or globally as appropriate.

In general, language designers have to choose carefully between
where they "force" something on the programmer, and where they
simply support something.  Furthermore, when more than one approach
is supported, they have to choose whether one is made significantly
easier or more convenient than the other.  This is because the 
rules of the language have a subtle effect on the style adopted by 
the programmers.  It is certainly not zero effect, but it of course 
is not overwhelming, in that design approaches, past history, etc., 
all have an effect as well.

However, as far as separation of spec and body, I believe many
people who have used Ada over the past 15 years believe that this
separation "enforced" by Ada was perhaps its most fundamental
contribution to programming style.  Given that belief, it is very 
surprising (at least to me) to see some languages moving away from this
separation, and only "allowing" it (and sometimes requiring you to
work a bit harder and restructure a bit to do it).  

It is possible that the time for "forcing" this separation is past, but 
based on my recent use of Java in a multi-person project, I don't
think so.  The Java "interface" type and "abstract" classes are nice, 
but the fact that spec and body are merged in most Java classes,
even given tools like "javap" and "javadoc" to extract the interface, doesn't
substitute for separate spec and body.  

The hand-written Ada package spec (or even C header) remains a far 
superior interface document for a given abstraction than is anything 
I have seen extracted by a tool.  The result of extraction by a tool 
typically ends up getting some but not all of the comments, and the 
various operations are not presented in necessarily a helpful order, 
or with any useful higher-level organization.

Basically, the extraction tool tends to tell you what an abstraction
"is" or "does", rather than what it is supposed to do, and why.
When trying to decide whether a given implementation is correct, 
without that separate human-written spec, it is much harder to evaluate.
One is simply stuck trying to evaluate internal consistency, rather
than consistency against a separate human-written spec.  

As an example, look at the "javadoc" produced for the Java 
standard API.  It gives you the facts, but almost nothing more.  
I suspect that if someone had been "forced" to write a 
separate spec for each of these classes, there would be something 
more "specification"-ish there (i.e. what the routines are 
supposed to do, in words).

: Neil Wilson (neil at aldur dot demon dot co dot uk)
: Aldur Systems Ltd, UK 

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <3404909F.2C67412E@eiffel.com> Bertrand Meyer <Bertrand.Meyer@eiffel.com> writes:

>         G4. Allow multiple implementations of a given
>             interface, including the possibility for
>             clients to switch easily and implicitly
>             between various implementations at run time
>             (not possible, at least not possible simply,
>             in Modula/Ada). This of course will take advantage
>             of polymorphism and dynamic binding.

More to the point: not _relevant_ in the Ada case as this is handled
by a different orthogonal capability (instead of conflating it with
module as in Eiffel).

/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: Interface/Implementation (was Re: Design by Contract)

[Tucker Taft]

Bertrand Meyer (Bertrand.Meyer@eiffel.com) wrote:

: Here is the reasoning behind the Eiffel approach to
: separating interface from implementation. It was designed
: in full knowledge of the Modula-2/Ada-83 mechanisms, in an
: attempt to draw the lessons of both their advantages and
: limitations, taking advantage of newer software technology
: and of O-O principles...

In my experience, separating the spec and body physically is
extremely advantageous, and the need to have redundancy between
the spec and body is an important feature in a multi-person
project, not an "inconvenience."  In Ada (and to some extent in C/C++
when you use header files in a disciplined way), changing the interface
to a public routine, or adding a new public routine, or removing
one, is a fundamentally different kind of operation, and *intentionally* 
requires more effort and care.


: ...
:         G5. Minimize the programmer's work. In particular
:             it is crucial to avoid forcing the programmer
:             to duplicate text. Duplication is almost always
:             bad, especially with respect to ease of maintenance,
:             one of the central goals of software engineering.
:             It also hampers reuse, reliability (when you
:             duplicate code, you duplicate its bugs, and
:             the more software you write the more likely
:             it is that it will include bugs), and ease
:             of change.

Basically, this is the paragraph I don't agree with, since the
"duplication" one is talking about is duplication of the
parameter/result/constraint profile in the spec and body of 
a package/class.  The compiler checks for conformance, so the issue
of forgetting to fix bugs in all copies doesn't arise.  The compiler
catches such gaffes.  On the other hand, duplicating a chunk of
algorithmic code in two places is undeniably bad news.  But we
aren't talking about that here.

The programmer's work spent duplicating the interface in the
spec and body is truly trivial, whereas the advantages of having
a physically separate interface are profound in a multi-person
(or just long-lived) project.

I can believe this is somewhat just a matter of personal taste,
and where one believes programmers should put their energy.
However, there are some interesting anecdotes about programmers
who go from a language like Fortran or old-style C where there
is often no separate spec, to a language like Ada or Modula with
physical separation.  They suddenly realize that the spec is itself
an important design object, something for potential users and
implementors of an abstraction to work on together early in a project,
and something which will allow users and implementors of the abstraction
to go off and work relatively independently once agreement on the spec
is reached.  It becomes very clear that the spec is not "owned" by
either the users or the implementors, but is rather the contract between
them which will thereafter change only through collaborative renegotiation.

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

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <3404909F.2C67412E@eiffel.com>,
Bertrand Meyer  <Bertrand.Meyer@eiffel.com> wrote:
>
>The goals are clear:

  I agree with most of these goals, but I have an issue with one
of them:

>        G5. Minimize the programmer's work. In particular
>            it is crucial to avoid forcing the programmer
>            to duplicate text. Duplication is almost always
>            bad, especially with respect to ease of maintenance,
>            one of the central goals of software engineering.
>            It also hampers reuse, reliability (when you
>            duplicate code, you duplicate its bugs, and
>            the more software you write the more likely
>            it is that it will include bugs), and ease
>            of change.

  Of course duplication is bad, but this is a special case which
is not nearly so bad.  These, if I understand, are your reasons
for disliking code duplication:

 1. Too much typing
 2. Duplicate code duplicates bugs
 3. More code means more bugs
 4. Too hard to change

  Here's why I don't think any of these are serious problems here:

 1. The same tools which provide interface files for documentation
   in Eiffel could provide them for compiler usage in another
   language, so there is no more typing than in the Eiffel approach.

 2. This is true, but is no more a problem than a single bug in this
   case because if the bug is fixed in one place, the compiler will
   force us to fix it in the other place.

 3. Certainly, given two independent code fragments, the total
   expected number of bugs would be greater than that of a single
   fragment.  But in this case, the fragments are not independent:
   if the implementation (which includes the interface) is bug-free,
   then so is the interface.  If the interface has a bug, then so
   does the implementation; but this is really one bug as argued
   in #2.  So by adding an interface file, we haven't added any
   extra potential for bugs.

 4. The interface of a class is the part that the rest of the
   system relies on.  Perhaps it should be hard to change.  I
   think there is merit in making a programmer aware that certain
   changes could have repercussions outside the module in
   question.  So, while true, point #4 may not be a problem at all.

Having said all that, I'm not particularly in favour of one method
over the other.  To me, it seems like a very minor issue compared
with the complexities programmers have to deal with.  I don't
think the one-file-versus-two issue has any real lasting effects
on the development process.

One last argument...

In Eiffel, a short form can be produced for documentation.  Why not
give the compiler the capability to ensure that the short form
matches the code being compiled?  And if we do that, aren't we
back to the separate-interface-file model again?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

Tucker Taft wrote:
> In my experience, separating the spec and body physically is
> extremely advantageous, and the need to have redundancy between
> the spec and body is an important feature in a multi-person
> project, not an "inconvenience."  

The redundancy itself is not needed.  A language _like_ C or Ada
could be defined where the compiler uses the spec/prototype
of a function _from_ the other file in compiling the body of the
function.  But it would certainly be a productivity hit if the coder
had to do extra work to _see_ the interface while coding the
implementation.

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

Patrick Doyle wrote:
> Bertrand Meyer  <Bertrand.Meyer@eiffel.com> wrote:
> >The goals are clear:
> 
>   I agree with most of these goals, but I have an issue with one
> of them:

I'm still looking at them (actually, waiting for enough free time)
but I also disagree for similar reasons with this one:

> >        G5. Minimize the programmer's work. .....
>              ..... Duplication is almost always
> >            bad, especially with respect to ease of maintenance,
> >            one of the central goals of software engineering.
> >            It also hampers reuse, reliability (when you
> >            duplicate code, you duplicate its bugs, and
> >            the more software you write the more likely
> >            it is that it will include bugs), and ease
> >            of change.

>  1. Too much typing
>  4. Too hard to change

This is what a C bigot would say.  An Ada bigot (indeed, everyone
on the Ada side of the average) would say, "Absolutely not an issue"
(1) & (4) are almost the same, but discouraging change (4) in a SPEC 
(interface) is a Good Thing.

>  2. Duplicate code duplicates bugs
>  3. More code means more bugs

Both of these are incorrect in this case.  A bug that is repeated
is still only one bug  IF  it is repeated in the parts of the 
spec/body that are required to conform by the language.

I could add another argument that others have already offered:

5. A corollary of Murphy's law is that duplicate information
   will inevitably become non-duplicate.

This argument is applicable in C, where header files can easily
not match the implementation, yet still compile.  It does not
apply to Ada specs and bodies, since duplication that is required
is compiler-enforced to be a perfect match.  You can't even 
deviate as much as

  spec:

      Proc ( X : Pkg.X_Type );

  body:

      package P renames Pkg;

      Proc ( X : P.X_Type ) is ...

And duplication that is not required is not allowed (such as
redeclared variables).
-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <34059557.37C0@pseserv3.fw.hac.com> "W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com> writes:

> Tucker Taft wrote:
> > In my experience, separating the spec and body physically is
> > extremely advantageous, and the need to have redundancy between
> > the spec and body is an important feature in a multi-person
> > project, not an "inconvenience."  
> 
> The redundancy itself is not needed.  A language _like_ C or Ada
> could be defined where the compiler uses the spec/prototype
> of a function _from_ the other file in compiling the body of the
> function.  But it would certainly be a productivity hit if the coder
> had to do extra work to _see_ the interface while coding the
> implementation.

Another thing to note here; as (since) people are bandying about
automated tool support for extracting spec or whatever, they need to
realize the dual of this is also readily available: automated support
for generating the operation signatures and stubs for the body from
the spec.

IMO, the spec. is much more important for design than the body and so
having automated support spec.->implementation is much more
appropriate than having automated support implementation->spec.

/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: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <EFMpCv.8uv.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com 
says...

>The hand-written Ada package spec (or even C header) remains a far 
>superior interface document for a given abstraction than is anything 
>I have seen extracted by a tool.

Then I very strongly recommend that you take a look at the short-flat form of 
Eiffel.

>The result of extraction by a tool 
>typically ends up getting some but not all of the comments,

The significance of Eiffel comments in various positions is well defined.  
Header comments for classes and routines are picked up.  Basically the class 
author can decide which comments will be visible and which will not.

> and the 
>various operations are not presented in necessarily a helpful order, 
>or with any useful higher-level organization.

Eiffel classes can have multiple "feature" clauses, which serves this purpose 
(amongst others).

>Basically, the extraction tool tends to tell you what an abstraction
>"is" or "does", rather than what it is supposed to do, and why.

That is what Eiffel assertions are about.  They are extracted by the
"short-flat" tool of Eiffel environments.

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: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <5u62es$e23$7@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes:

> In article <EFMpCv.8uv.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com 
> says...
> 
> >The hand-written Ada package spec (or even C header) remains a far 
> >superior interface document for a given abstraction than is anything 
> >I have seen extracted by a tool.
> 
> Then I very strongly recommend that you take a look at the
> short-flat form of Eiffel.

Been there, done that.  And I'm with Tucker on this one.

/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: Interface/Implementation (was Re: Design by Contract)

[Joerg Rodemann]

Graham Perkins (gperkins@dmu.ac.uk) wrote:
> But really, this whole discussion indicates to me that we are still in
> the stone
> age with our tools.  Why are we still talking about "files"?!! 
> Presumably stored
> in DOS or Unix directories ?!!  Uggghhhh!!!!

Well, perhaps the reason is somewhat called the least common denominator?
I'd love to have powerful tools that keep me from caring about my 'files'
a lot and give me lots of other support. But(!) the more tools you have the
more work is needed to port these tools to different platforms. Have a look
at GNAT or gcc: that is really good work and it is available on many 
platforms.  Yet there are a lot more platforms that are not covered that
well.  And here we are talking only about the compiler. Not any additional
tools that 'make life easy'. 

To keep this short: When will Eiffel be available for the Cray T3E? Or the
NEC SX-4? :-) Maybe I should try a gcc/GNAT port first instead of waiting...

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: Interface/Implementation (was Re: Design by Contract)

[Suzanne Zampella]

Jon S Anthony wrote:

> In article <34059557.37C0@pseserv3.fw.hac.com> "W. Wesley Groleau
> x4923" <wwgrol@pseserv3.fw.hac.com> writes:
>
> > Tucker Taft wrote:
> > > In my experience, separating the spec and body physically is
> > > extremely advantageous, and the need to have redundancy between
> > > the spec and body is an important feature in a multi-person
> > > project, not an "inconvenience."
> >
> > The redundancy itself is not needed.  A language _like_ C or Ada
> > could be defined where the compiler uses the spec/prototype
> > of a function _from_ the other file in compiling the body of the
> > function.  But it would certainly be a productivity hit if the coder
>
> > had to do extra work to _see_ the interface while coding the
> > implementation.
>
> Another thing to note here; as (since) people are bandying about
> automated tool support for extracting spec or whatever, they need to
> realize the dual of this is also readily available: automated support
> for generating the operation signatures and stubs for the body from
> the spec.
>

   Oh, to be back on the Rat.....  We had this way back in '87, 10 years
ago... .. code the specification for detailed design -- baseline it in
the environment so everyone who interfaced had a stable target, then the
CASE generated the body stub and you could change the body till it
worked while your fellow team members coded and compiled against your
<baselined> specification.  If you wanted to see the specification of
something you just put your cursor on it and pressed a function key and
up popped a window showing the definition of the item (procedure,
variable, whatever).  If you didn't remember the parameters of a
procedure call, with the a press of a function key the CASE would prompt
you for them.

Separate bodies and specification are NOT the problem.  They are
incredibly helpful from a firewall (coding changes stop here without
approval) point of view and from the point of view of producing designs
that stay with the code. They are also great if you have to have
separate bodies on different platforms. What you need is a good CASE.


Suzanne Zampella
{include STD-Disclaimer}

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EFnK8D.Lsv@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >
> >IMO, the spec. is much more important for design than the body and so
> >having automated support spec.->implementation is much more
> >appropriate than having automated support implementation->spec.
> 
>   I don't know if spec is more important than implementation, but
> that's another debate...

No it is not "another debate" - it is simply my opinion, as noted.
That's part of the problem here - I've (and probably loads of others)
already thought these issues through and have made up my mind after
carefully weighing the various options.  Overall, my view is that the
Eiffel way is significantly less expressive and capable than the Ada
way.  Period.  End of story for me.  I'm more than willing to discuss
the various characteristics of each and the various tradeoffs in
objective fashion - but for "value judgements", I've already
deliberated and made them.


>   As for your comment above, for Eiffel in particular one would put
> spec and implementation in the same file, and to be able to extract
> spec at will.  Thus, it's not a case of implementation -> spec so
> much as implementation+spec -> spec.

A rose by any other name Patrick.


>   In other words, don't think that Eiffel encourages the
> implementation to drive the specification (which would indeed be a
> bad thing).  It simple mixes the two into the same file and provides
> tools to separate them again.

Fine.  And I do.  And IMO, the evidence is there with enough authority
to convince me of 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: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <3406CF60.11A867C4@trcinc.com> Suzanne Zampella <suzanne.zampella@trcinc.com> writes:

> > Another thing to note here; as (since) people are bandying about
> > automated tool support for extracting spec or whatever, they need to
> > realize the dual of this is also readily available: automated support
> > for generating the operation signatures and stubs for the body from
> > the spec.
>
>    Oh, to be back on the Rat.....  We had this way back in '87, 10 years
> ago... .. code the specification for detailed design -- baseline it in
> the environment so everyone who interfaced had a stable target, then the
> CASE generated the body stub and you could change the body till it
> worked while your fellow team members coded and compiled against your
> <baselined> specification.  If you wanted to see the specification of
> something you just put your cursor on it and pressed a function key and
> up popped a window showing the definition of the item (procedure,
> variable, whatever).  If you didn't remember the parameters of a
> procedure call, with the a press of a function key the CASE would prompt
> you for them.

Never fear, Emacs is here!  Seriously, Emacs ada-mode does all of this
for you now.  What's more, it's completely open and you have complete
control over it (can change it if you wish, etc.)  And it is much
easier to integrate it with other things.

Emacs is KING! :-) :-)
[yes, Robert, I know I probably shouldn't have said that!]

/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: Interface/Implementation (was Re: Design by Contract)

[Ralph Paul]

Joerg Rodemann wrote:
> 
> To keep this short: When will Eiffel be available for the Cray T3E? Or the
> NEC SX-4? :-) Maybe I should try a gcc/GNAT port first instead of waiting...

You did forget the mighty little Intel Paragon ? (:-).

Ralph Paul

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Jon Anthony says

<<More to the point: not _relevant_ in the Ada case as this is handled
by a different orthogonal capability (instead of conflating it with
module as in Eiffel).>>


Nice word (conflate) :-)
I often point out that unify and confuse mean the same thing (join
together), but express a different point of view about the desirability
of doing so -- conflate is nicely neutral.

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <JSA.97Aug29152222@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFnK8D.Lsv@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> Jon S Anthony <jsa@alexandria.organon.com> wrote:
>> >
>> >IMO, the spec. is much more important for design than the body and so
>> >having automated support spec.->implementation is much more
>> >appropriate than having automated support implementation->spec.
>> 
>>   I don't know if spec is more important than implementation, but
>> that's another debate...
>
>No it is not "another debate" - it is simply my opinion, as noted.

  That's funny, I thought these newsgroups were for discussion.

>That's part of the problem here - I've (and probably loads of others)
>already thought these issues through and have made up my mind after
>carefully weighing the various options.  Overall, my view is that the
>Eiffel way is significantly less expressive and capable than the Ada
>way.  Period.  End of story for me.  I'm more than willing to discuss
>the various characteristics of each and the various tradeoffs in
>objective fashion - but for "value judgements", I've already
>deliberated and made them.

  And this means we can't debate things any more?

>>   As for your comment above, for Eiffel in particular one would put
>> spec and implementation in the same file, and to be able to extract
>> spec at will.  Thus, it's not a case of implementation -> spec so
>> much as implementation+spec -> spec.
>
>A rose by any other name Patrick.

  Not at all.  Having a tool which "guesses" the spec from the
implementation is dangerous.  But simply extracting the existing
spec from a spec+implementation document is a trivial process
which it easily automated.

>>   In other words, don't think that Eiffel encourages the
>> implementation to drive the specification (which would indeed be a
>> bad thing).  It simple mixes the two into the same file and provides
>> tools to separate them again.
>
>Fine.  And I do.  And IMO, the evidence is there with enough authority
>to convince me of this.

  And you'll make no effort to convince me I'm wrong?  Then why
to you participate in newsgroups?

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EFqDLs.3FL@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >>   I don't know if spec is more important than implementation, but
> >> that's another debate...
> >
> >No it is not "another debate" - it is simply my opinion, as noted.
> 
>   That's funny, I thought these newsgroups were for discussion.

Firing loaded opinions around back and forth is not my idea of
"discussion".  Especially given the lack of nuances capable in NG
text.  If it's yours - have at it.  Of course, you should expect to
encounter all the worthless flames and inflammatory rhetoric that goes
with it.


>   And this means we can't debate things any more?

I don't see these "yes it is!  no it isn't!" or (even worse) "you're a
FOOL for not using X because _I_ think it's COOL (BETTER, SUPERIOR,
whatever)" exchanges as particularly insightful or useful.


> >A rose by any other name Patrick.
> 
>   Not at all.  Having a tool which "guesses" the spec from the
> implementation is dangerous.  But simply extracting the existing
> spec from a spec+implementation document is a trivial process
> which it easily automated.

Whatever.


> >Fine.  And I do.  And IMO, the evidence is there with enough authority
> >to convince me of this.
> 
>   And you'll make no effort to convince me I'm wrong?  Then why
> to you participate in newsgroups?

Because every once in a while (less lately due to a certain someone's
series of heavily x-posted inflammatory rhetoric) there are real
technical exchanges with real content that have real use.  Trying to
convince someone simply for the sake of convincing or ramming your
view down their throats with the zeal of a religous fanatic is lame
and useless.  Wanna do that?  Go be a lawyer or politician.  Best
thing is to simply present as much of the facts as you can in the best
light you can and let people make up their own minds.  If at the end
of the day they want to use C++ and VB or Eiffel or Ada, or Lisp or
..., so be it.

/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: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EFqDAG.2zn@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> >> >More to the point: not _relevant_ in the Ada case as this is handled
> >> >by a different orthogonal capability (instead of conflating it with
> >> >module as in Eiffel).
> >> 
> >>   I think this is a case of Ada hairsplitting, where something
> >> which is really a single concept is split into two "orthogonal"
> >> concepts for no particular benefit.  Specifying an interface
> >
> >Irrelevant.  Given the case being discussed, the point about
> >polymorphism not being available on Ada modules (packages) is just
> >plain irrelevant as that is not what they are for.  You might as well
> >complain about the lack of feathers on mammals for crying out loud.
> 
>   Hey, read my quote; I never even *hinted* at polymorphism on
> Ada modules.

Hey - follow the thread.  BM _explicitly stated_ this as a flaw in Ada
modules and was the very thing I responded to as irrelevant.


>  You might as well bash me for complaining about
> the lack of feathers on mammals.

No, now I'm wondering why you even replied to my first post which was
a direct reply to the "polymorphism" aspect as noted above.  Sheesh!


> >For boatloads of reasons that have been gone over in painstaking
> >detail in the past.  If you don't like them, use Eiffel or C++ or
> >something.  If you like the Ada way, use it or CLOS (which treats
> >module (actually called "packages" similarly) or some such.
> 
>   Hey, Jon, easy boy. 

I see no "shouting" there.  This paragraph should be read as a
"*sigh*" and one big shoulder shrug.


>   Jon, why do you insist on these personal attacks?  I thought it

I don't see these as "personal attacks".  For crying out loud...


> bothered, and just want to refer me to Deja News, fine, but
> lets keep these shots above the belt.

Believe me - there are no shots being fired here.  This is another
good example how the inexpressive medium of news can set entire
threads into flames simply because someone took a simple statement as
a "shot".

/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: Interface/Implementation (was Re: Design by Contract)

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

On Thu, 28 Aug 1997 14:53:19 GMT, Tucker Taft 
:The hand-written Ada package spec (or even C header) remains a far 
:superior interface document for a given abstraction than is anything 
:I have seen extracted by a tool.  The result of extraction by a tool 
:typically ends up getting some but not all of the comments, and the 
:various operations are not presented in necessarily a helpful order, 
:or with any useful higher-level organization.
:
:Basically, the extraction tool tends to tell you what an abstraction
:"is" or "does", rather than what it is supposed to do, and why.
:When trying to decide whether a given implementation is correct, 
:without that separate human-written spec, it is much harder to evaluate.
:One is simply stuck trying to evaluate internal consistency, rather
:than consistency against a separate human-written spec.

I agree that these are important, but I don't see how Eiffel abstract
classes are inadequate for this purpose.

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Patrick Doyle wrote:

:In article <EFnrot.3K9@syd.csa.com.au>,
:Don Harrison <nospam@thanks.com.au> wrote:
:>Neil Wilson wrote:
:>
:>:Darren New <dnew@zloty.fv.com> wrote in article
:>:<5u2fhb$4t7@newshub.atmnet.net>...
:>:> I think people are complaining that one of the missed goals is 
:>:> "the ability to administratively freeze the interface while 
:>:> allowing editing/completion/bugfixing the implementation."
:>:
:>:This is acheived using deferred classes.. 
:>
:>I disagree. Deferred classes are more like Ada abstract types, IMO; short forms
:>are more like Ada interfaces.

BTW, I meant flat-short form here.

:  The point is not how analogous they are.  

Sorry, I disagree. If we're to compare Eiffel and Ada in any meaningful 
way, finding analogues *is* the point. In particular, we're after the mechanisms 
in each language that deliver the same functionality.

:The point is that freezing interface while altering the implementation can be
:achieved using deferred classes.

Sure, you *could* use it that way in some specific circumstances but it would
be misusing the mechanism, IMO, because they fulfil different roles.

The *purpose* of deferred classes is to capture high level abstract design 
which is made progressively more concrete *through inheritance* by replacing 
deferred features with effective ones. An additional role is to facilitate 
polymorphism. This *design* role is mirrored pretty much exactly (minus 
the encapsulation) by Ada's abstract tagged types.

In comparison, the purpose of Eiffel flat-short forms and Ada package specs 
is to provide a client's *view* of the exported features of a class. This view 
exists irrespective of whether or not the class's features came about through 
inheritance and irrespective of whether polymorphism is possible. 

Something which may help to see the different roles is to consider the 
situation of an effective (concrete) class inheriting from another effective 
class (and no deferred classes). Where's the interface? Clearly, it exists 
only in the flat-short form.


BTW, I've taken "completion" in Darren's post to mean actually implementing,
as opposed to stubbing. It's true that on the design side, deferred features
get effected but I assume that's not what Darren meant. 

The issue of stubbing highlights an advantage of the Eiffel approach.
If an Eiffel system is compilable, it is also executable because all effective
features will at least have a stubbed body. Due to the fact that Ada's 
interfaces are separately compilable, it's not uncommon, early in development, 
to have to create temporary (usually stubbed) implementations for other 
developer's packages in order to produce an executable. Although it's fairly
mechanical to do so, it's still an inconvenience. The same can be said of the
maintenance aspect of redundancy in Ada specs and bodies. I, personally, find
it a pain to have to keep the two in synch.

Also, if the client produces the stubbed body, as is often the case (because 
the owner is busy doing something else), the stub is less likely to reflect 
the semantic properties of the module - for example, by returning 
non-representative values.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Graham Perkins wrote:

:Tucker Taft wrote:
:> In my experience, separating the spec and body physically is
:> extremely advantageous, and the need to have redundancy between
:
:Personally I prefer the single file approach as with Eiffel..

Thought you might. :)

:But really, this whole discussion indicates to me that we are still in
:the stone age with our tools..

[lots of good stuff about how a software repository ought to work]

:Now where is that repository with all that power I want ... 
:  [if you're setting up a team to develop such a beast, please
:   count me in]

.. and me!  :)

:maybe Eiffel vendors are further down that road than many (or Unisys UREP might
:be the right track to follow) but we still seem a long way from open repositories
:than support full process

Agree.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <JSA.97Aug30150959@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFqDLs.3FL@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> >>   I don't know if spec is more important than implementation, but
>> >> that's another debate...
>> >
>> >No it is not "another debate" - it is simply my opinion, as noted.
>> 
>>   That's funny, I thought these newsgroups were for discussion.
>
>Firing loaded opinions around back and forth is not my idea of
>"discussion".  Especially given the lack of nuances capable in NG
>text.  If it's yours - have at it.  Of course, you should expect to
>encounter all the worthless flames and inflammatory rhetoric that goes
>with it.

  Here's what I see: I stated an opinion and invited a debate.  You
put a stop to that, saying it is your opinion and not a debate.  Yet
in another thread, you said that simply stating opinion was a
"waste of bandwidth".

  I can't for the life of me see why you're here at all, so I 
guess we'll have to agree to disagree and spare others from our
diatribes.

>>   And this means we can't debate things any more?
>
>I don't see these "yes it is!  no it isn't!" or (even worse) "you're a
>FOOL for not using X because _I_ think it's COOL (BETTER, SUPERIOR,
>whatever)" exchanges as particularly insightful or useful.

  It's only useless when opinions are not backed up by thoughtful
arguments, as in your case above regarding the importance of
interface versus implementation.  To me, that's the waste of
time.

>> >Fine.  And I do.  And IMO, the evidence is there with enough authority
>> >to convince me of this.
>> 
>>   And you'll make no effort to convince me I'm wrong?  Then why
>> to you participate in newsgroups?
>
>Because every once in a while (less lately due to a certain someone's
>series of heavily x-posted inflammatory rhetoric) there are real
>technical exchanges with real content that have real use.  Trying to
>convince someone simply for the sake of convincing or ramming your
>view down their throats with the zeal of a religous fanatic is lame
>and useless.  

  But I'm here to have people try to convince me of their views.
I think that's the best part.  You learn the most from that sort
of thing--not just mere information, but different ways to think.
If you don't want to do me that favour, I can't possibly hold
a grudge, but I still wonder why you're here.

>Wanna do that?  Go be a lawyer or politician.  Best
>thing is to simply present as much of the facts as you can in the best
>light you can and let people make up their own minds.  If at the end
>of the day they want to use C++ and VB or Eiffel or Ada, or Lisp or
>..., so be it.

  I agree completely.  I've been asking you to back up your opinions
(ie. "present the facts as you can in the best light you can"), and
you don't want to.  And that's fine.  Just so we understand each other.

  So, in the hopes of sparing others from more wasted bandwidth,
perhaps we should be more selective from now on as to which of
each others' comments we respond to.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

Patrick Doyle wrote:
> 
> In article <JSA.97Aug29152347@alexandria.organon.com>,
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >In article <5u62es$e23$7@miranda.gmrc.gecm.com> paul.johnson@gecm.com (Paul Johnson) writes:
> >
> >> In article <EFMpCv.8uv.0.-s@inmet.camb.inmet.com>, stt@houdini.camb.inmet.com
> >> says...
> >>
> >> >The hand-written Ada package spec (or even C header) remains a far
> >> >superior interface document for a given abstraction than is anything
> >> >I have seen extracted by a tool.
> >>
> >> Then I very strongly recommend that you take a look at the
> >> short-flat form of Eiffel.
> >
> >Been there, done that.  And I'm with Tucker on this one.
> 
>   What can you do with a hand-written package spec that you can't
> do with the Eiffel tools?

I'm not familiar with Eiffel.  Let me tell you a few things we
do in Ada, and you can tell me if the tools support it or not.
I'd be quite interested to know how the short-flat extraction tool,
or the deferred class approach, address these.  NOTE: I'M NOT
SAYING THEY CAN'T, I'M ASKING HOW THEY DO IT.  Please don't
assume this is an attack; it isn't.  I'ts a request for info.

Please specify whether the practice you suggest is commonly
done.  I've listed things that I've seen done several times for
real production code.  I'm especially curious if the deferred-class
approach that Patrick Doyle suggests is a common idiom in Eiffel.

Some capabilities that are provided by Ada's separate spec/body
approach are:

* Different order of subprograms -- one order or grouping may be
  most meaningful for the interface, another for implementation.

* Unexported (local to the package) subprograms and declarations.

* Different comments -- the Ada spec usually contains comments that
  describe what facility a subprogram provides and how to use it,
  the package contains a description of its implementation details.

* Interface control and verification -- the Ada spec can be written
  and published, and other groups can code against it.  If the
  implementation or the client changes, the compiler can verify that
  they are still consistent without having to reprocess both.

* Multiple interfaces -- you can have several sub-packages that
  export subsets of a package's functionality.  In Ada 83, if
  visibility into the body (implementation) is required, these
  must all be contained in the main package's spec; in Ada 95,
  they can be separate child packages.  In either case, if you
  just want to re-package existing functionality to provide
  different views, you can provide "view" packages that rename
  elements from the main ("full-view") package.

* Multiple implementations, global, compile time -- you can have
  many implementations of your package spec, and select the best
  one for your application at compile time.  Thus, your "list"
  could have a hash table for faster lookup, or store its contents
  to disk to allow long lists of huge data items (just one in
  memory at a time), or whatever -- as long as the spec stays the
  same, the client code doesn't need to be recompiled.

* Multiple implementations, item-specific, compile time --
  Ada generics can provide a unified interface for several
  implementations of a facility.  Any logic that is common across
  all the implementations is written into the generic, while any
  code that is implementation-specific is provides as subprograms
  that are parameters to the generic.  In the worst case, the
  generic only provides a "template" that instantiations must
  follow.  For example:

    generic
      type Item is private;
      type Stack is private;
      with procedure Push (S: in out Stack; I: in out Item);
      with procedure Pop (S: in out Stack; I: in out Item);
    package Generic_Stack is
      -- exports the procedures imported
      procedure Push (S: in out Stack; I: in out Item);
      procedure Pop (S: in out Stack; I: in out Item);
    end Generic_Stack;

  This generic just encapsulates an interface.  If you write clients
  that instantiate it, and implementation packages that can be used
  to instantiate it, then you know any client can switch to any
  implementation with a simple, compile-time change to the client
  code (where it instantiates the generic).

* Multiple implementations, run time -- these are best supported in
  Ada by dispatching subprograms and tagged types, not by packaging.

Best,
Samuel Mize

Re: Interface/Implementation (was Re: Design by Contract)

[Nick Leaton]

Matt Kennel (Remove 'NOSPAM' to reply) wrote:
> 
> On Thu, 28 Aug 1997 14:53:19 GMT, Tucker Taft
> :The hand-written Ada package spec (or even C header) remains a far
> :superior interface document for a given abstraction than is anything
> :I have seen extracted by a tool.  The result of extraction by a tool
> :typically ends up getting some but not all of the comments, and the
> :various operations are not presented in necessarily a helpful order,
> :or with any useful higher-level organization.
> :
> :Basically, the extraction tool tends to tell you what an abstraction
> :"is" or "does", rather than what it is supposed to do, and why.
> :When trying to decide whether a given implementation is correct,
> :without that separate human-written spec, it is much harder to evaluate.
> :One is simply stuck trying to evaluate internal consistency, rather
> :than consistency against a separate human-written spec.
> 
> I agree that these are important, but I don't see how Eiffel abstract
> classes are inadequate for this purpose.

The reason lies with how Eiffel handles comments and its support for
pre and post conditions and class invariants.

In Eiffel not all comments are equal. If you look at the syntax of the
language although all comments have the same appearance '--' and all
characters to the
end of the line, comments appear in the syntax. Comments appearing in
certain places in the code, for example, just after the class name are
documentation comments and appear in the 'short form'. (The spec). You
also have assertions that closely correspond to the spec, saying what
the feature will do for you if you satisfy the precondition. In other
words a lot of your spec ends up in you classes.

As to ordering, well you should be ordering your code, as you should be
ordering your spec.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EFv7yL.yr@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

> Try thinking along the lines of
> 
>   a) Ada interfaces correspond to Eiffel short forms, and
>   b) Ada abstract types correspond to Eiffel deferred classes.

Agreed.


> In terms of b), the Ada (corrections welcome):
> 
> package P is
>   type T is abstract tagged private;
>   procedure Do_Something (X: T) is abstract;      -- deferred/abstract
> private
>   type T is tagged record 
>     Y: Integer;
>   end record;
> end;
> 
> 
> is basically equivalent to the Eiffel:
> 
> deferred class T
>   feature
>     do_something is deferred end                  -- deferred/abstract
>   feature {NONE}
>     y: INTEGER
> end.

This looks right to me.

> Deriving effective (concrete) descendants from these, we might have the Ada: 
> 
> with P;
> package Q is
>   type New_T is new P.T;
>   procedure Do_Something (X: T);
> end;
> 
> package body Q is
>   procedure Do_Something (X: T) is begin .. end;      -- effective
> end;

Actually, the body has nothing to do with it.  The concrete
declaration in the spec. is the "effective" one (there could be many
[completely different] bodies implementing it)


> and the corresponding Eiffel:
> 
> deferred class NEW_T
>   inherit T
>   feature
>     do_something is do .. end                         -- effective
> end.

Agreed.


> :>Tons.  See DejaNews...  
> 
> Whether or not they convinced anyone is another matter, however.

Convincing has nothing to do with it.

/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: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

I wrote:

.. Deferred classes are more like Ada abstract types, IMO; short forms
::>are more like Ada interfaces.
:
:BTW, I meant flat-short form here.

Sorry, I *do* mean "short form". Sorry for the confusion.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Patrick Doyle wrote:

:In article <JSA.97Aug29191413@alexandria.organon.com>,
:Jon S Anthony <jsa@alexandria.organon.com> wrote:
:>In article <EForsv.Fqo@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
:>
:>> >More to the point: not _relevant_ in the Ada case as this is handled
:>> >by a different orthogonal capability 

Agree. Multiple, polymorphic implementations are provided by deferred classes
and abstract types in Eiffel and Ada respectively. As Jon says, this is an 
orthogonal concept to interfaces.

:>> >(instead of conflating it with module as in Eiffel).

This is a different issue.


:>> using a deferred class is more powerful than a simple interface
:>> file, and can accomplish all the same things, so why split
:>> this into two concepts?

Because they serve different purposes. (See my previous post).

:  The Deja News suggestion is a good idea.  I'll take a look there
:when I get a moment.

You could, but you may get more confused. :(

Try thinking along the lines of

  a) Ada interfaces correspond to Eiffel short forms, and
  b) Ada abstract types correspond to Eiffel deferred classes.

In terms of b), the Ada (corrections welcome):

package P is
  type T is abstract tagged private;
  procedure Do_Something (X: T) is abstract;      -- deferred/abstract
private
  type T is tagged record 
    Y: Integer;
  end record;
end;


is basically equivalent to the Eiffel:

deferred class T
  feature
    do_something is deferred end                  -- deferred/abstract
  feature {NONE}
    y: INTEGER
end.


Deriving effective (concrete) descendants from these, we might have the Ada: 

with P;
package Q is
  type New_T is new P.T;
  procedure Do_Something (X: T);
end;

package body Q is
  procedure Do_Something (X: T) is begin .. end;      -- effective
end;


and the corresponding Eiffel:

deferred class NEW_T
  inherit T
  feature
    do_something is do .. end                         -- effective
end.


:>>   And, as far as the class-as-module approach in Eiffel goes, I
:>> once thought this was a bad idea too, but I'm not so sure any
:>> more.  Do you have some arguments against it?
:>
:>Tons.  See DejaNews...  

Whether or not they convinced anyone is another matter, however.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

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

On Tue, 02 Sep 1997 09:09:04 +0100, Nick Leaton <nickle@calfp.co.uk> wrote:
:Matt Kennel (Remove 'NOSPAM' to reply) wrote:
:> 
:> On Thu, 28 Aug 1997 14:53:19 GMT, Tucker Taft
:> :The hand-written Ada package spec (or even C header) remains a far
:> :superior interface document for a given abstraction than is anything
:> :I have seen extracted by a tool. 
:> : <et cetera>

:> I agree that these are important, but I don't see how Eiffel abstract
:> classes are inadequate for this purpose.
:
:The reason lies with how Eiffel handles comments and its support for
:pre and post conditions and class invariants.
:
:In Eiffel not all comments are equal. If you look at the syntax of the
:language although all comments have the same appearance '--' and all
:characters to the
:end of the line, comments appear in the syntax. Comments appearing in
:certain places in the code, for example, just after the class name are
:documentation comments and appear in the 'short form'. (The spec). You
:also have assertions that closely correspond to the spec, saying what
:the feature will do for you if you satisfy the precondition. In other
:words a lot of your spec ends up in you classes.

Huh?

I'm asking, "what is wrong with considering a hand-written abstract class,
not extracted from anything, as a specification?"

I think there may be some minor flaws in the edges, (how to make a spec
for many classes simultaneously) but it's awfully close to a very capable
solution it seems to me.

:Nick

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

Ok, I've never used the "short" tool, but here's how I understand it...


In article <340C85CE.6F42@link.com>, Samuel Mize  <smize@link.com> wrote:
>
>Some capabilities that are provided by Ada's separate spec/body
>approach are:
>
>* Different order of subprograms -- one order or grouping may be
>  most meaningful for the interface, another for implementation.

Short can't do this.

>* Unexported (local to the package) subprograms and declarations.

Short filters out unexported features, and even aspects of assertions
which refer to unexported features.

>* Different comments -- the Ada spec usually contains comments that
>  describe what facility a subprogram provides and how to use it,
>  the package contains a description of its implementation details.

The Eiffel class definition would contain all comments, written
in certain standard ways which allow Short to filter out the
implementation comments and retain the interface comments.

>* Interface control and verification -- the Ada spec can be written
>  and published, and other groups can code against it.  If the
>  implementation or the client changes, the compiler can verify that
>  they are still consistent without having to reprocess both.

Short won't help much here, but IMO abstract (deferred) classes
can do this anyway.  (However, the debate is raging in another
thread...  :-)

>* Multiple interfaces -- you can have several sub-packages that
>  export subsets of a package's functionality.  In Ada 83, if
>  visibility into the body (implementation) is required, these
>  must all be contained in the main package's spec; in Ada 95,
>  they can be separate child packages.  In either case, if you
>  just want to re-package existing functionality to provide
>  different views, you can provide "view" packages that rename
>  elements from the main ("full-view") package.

Eiffel has selective export which allows a class to export
features to specific clients.  Eiffel also has multiple
inheritance, which allows a class to support different
interfaces which are expressed as abstract classes.  The
"view" packages are really nothing more than the GoF
"adapter" pattern which can be accomplished in any
OOP language.

>* Multiple implementations, global, compile time -- you can have
>  many implementations of your package spec, and select the best
>  one for your application at compile time.  Thus, your "list"
>  could have a hash table for faster lookup, or store its contents
>  to disk to allow long lists of huge data items (just one in
>  memory at a time), or whatever -- as long as the spec stays the
>  same, the client code doesn't need to be recompiled.

There are design patterns which deal with this nicely (eg. Factory
Method) without having to add this functionality explicitly to
the language.

>* Multiple implementations, item-specific, compile time --
>  Ada generics can provide a unified interface for several
>  implementations of a facility.  Any logic that is common across
>  all the implementations is written into the generic, while any
>  code that is implementation-specific is provides as subprograms
>  that are parameters to the generic.  In the worst case, the
>  generic only provides a "template" that instantiations must
>  follow.  For example:
>
> [example]
>
>  This generic just encapsulates an interface.  If you write clients
>  that instantiate it, and implementation packages that can be used
>  to instantiate it, then you know any client can switch to any
>  implementation with a simple, compile-time change to the client
>  code (where it instantiates the generic).

Again, these are design patterns (eg. Template Method) which can
be done in any OOPL with polymorphism.

>* Multiple implementations, run time -- these are best supported in
>  Ada by dispatching subprograms and tagged types, not by packaging.

More design patterns (eg. State).

In the cases where I simply said that what you were talking about
is a design pattern, this means that special language features
are not necessary to do these things.  Perhaps it's nicer to have
the language help you out with these design patterns?  I don't
know.  But I think there's a lot of value to Eiffel's simplicity
and orthogonality which allows you to put together constructs
in an intuitive manner which can achieve these things.

A matter of opinion, I suppose.

 -PD


-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <340C85CE.6F42@link.com>, smize@link.com says...

>I'm not familiar with Eiffel.  Let me tell you a few things we
>do in Ada, and you can tell me if the [Eiffel] tools support it or not.

>Some capabilities that are provided by Ada's separate spec/body
>approach are:

>* Different order of subprograms -- one order or grouping may be
>  most meaningful for the interface, another for implementation.

First, I'm not convinced that this *is* all that good a practice.  Given a
big package body in Ada, I'd expect to use the spec as a table of contents.
Having things in a different order would be confusing and difficult.  However
I suppose a good browsing editor would solve this.

Eiffel allows you to group features in 1 or more "feature" clauses.  Partly 
this is done to specify export restrictions (features in each clause are 
exported as a group), and partly for ordering.  The "short-flat" interface 
extractor keeps each "feature" clause together, but sorts the contents into 
alphabetical order.  I think the "flat" part (ancestor importation) merges 
feature clauses with matching comments as well.  So if I have a class and
descendant which both contain

   feature -- Attributes

Then these two feature clauses will be merged.  Of course all this is
implementation dependent, and any short-flat filter could support a 
gazillion options for tuning it.  (My experience is mostly with the ISE
environment).

>* Unexported (local to the package) subprograms and declarations.

Mixed.  Any Eiffel class can have private routines and attributes, and 
most do.  However there is no way that a class can be rendered "private"
to the cluster, because "cluster" is much more an implementation issue
than a language issue.

Also, a descendant class can access all of its ancestor's features,
including the private ones.  Whether this is a Good Thing is debated.
For a defence of this position, see OOSC2 by Bertrand Meyer.  The objection
is that if a class implementation is changed it might break unknown
descendants.  Design rules can help solve this problem.  See Dejanews for
a fairly recent discussion of this problem on c.l.e.

>* Different comments -- the Ada spec usually contains comments that
>  describe what facility a subprogram provides and how to use it,
>  the package contains a description of its implementation details.

Not a problem.  Here is a feature declaration that does this:

   foo is
      -- This is the public comment for the short-flat interface.
   do
      -- Here is some private commentary about the implementation.
   end;

And of course the comments on private features will not be included in
the short-flat interface anyway.

>* Interface control and verification -- the Ada spec can be written
>  and published, and other groups can code against it.  If the
>  implementation or the client changes, the compiler can verify that
>  they are still consistent without having to reprocess both.

This really asks two questions.  One is about configuration management,
and the other about incremental compilation.

From the configuration POV, the short-flat form can be generated and put
under change control.  If a class is modified then the short-flat form can
be regenerated and compared with the controlled version.  Also most
of the environments (all?) can generate the short-flat form in HTML, which
makes a very neat publication format.

Incremental compilation is another matter, which I'm not going to address
here because I don't know enough.

>* Multiple interfaces -- you can have several sub-packages that
>  export subsets of a package's functionality.  In Ada 83, if
>  visibility into the body (implementation) is required, these
>  must all be contained in the main package's spec; in Ada 95,
>  they can be separate child packages.  In either case, if you
>  just want to re-package existing functionality to provide
>  different views, you can provide "view" packages that rename
>  elements from the main ("full-view") package.

You can do this in Eiffel by using inheritance.  The most common idiom
is to create several "deferred" classes and then inherit these in
various combinations to create the right interfaces.  You can also
inherit from an existing class and export a subset of its interface,
but this is a rather dirty approach.  Better (if possible) to make the
new class a "sibling" which shares some of the same deferred ancestors.

>* Multiple implementations, global, compile time -- you can have
>  many implementations of your package spec, and select the best
>  one for your application at compile time.  Thus, your "list"
>  could have a hash table for faster lookup, or store its contents
>  to disk to allow long lists of huge data items (just one in
>  memory at a time), or whatever -- as long as the spec stays the
>  same, the client code doesn't need to be recompiled.

Yup.  Eiffel does this in the "ACE" file, which is implementation
dependant.

>* Multiple implementations, item-specific, compile time --
>  Ada generics can provide a unified interface for several
>  implementations of a facility.  Any logic that is common across
>  all the implementations is written into the generic, while any
>  code that is implementation-specific is provides as subprograms
>  that are parameters to the generic.  In the worst case, the
>  generic only provides a "template" that instantiations must
>  follow.  For example:
>
>    generic
>      type Item is private;
>      type Stack is private;
>      with procedure Push (S: in out Stack; I: in out Item);
>      with procedure Pop (S: in out Stack; I: in out Item);
>    package Generic_Stack is
>      -- exports the procedures imported
>      procedure Push (S: in out Stack; I: in out Item);
>      procedure Pop (S: in out Stack; I: in out Item);
>    end Generic_Stack;

Eiffel does this with inheritance.  "STACK [T]" would be a deferred
class with T as the type of the contents.  "push" and "pop" would be
routines which are deferred.  Descendants of STACK will implement them.
You chose between implementations at compile time by deciding which
version of stack to create.  Everything else just manipulates instances
of STACK.


>* Multiple implementations, run time -- these are best supported in
>  Ada by dispatching subprograms and tagged types, not by packaging.

Tagged types are the Ada equivalent of Eiffel classes.

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: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

Patrick Doyle wrote:

> In the cases where I simply said that what you were talking about
> is a design pattern, this means that special language features
> are not necessary to do these things.

Agreed.  In Ada, the design patterns you referred to are built up
from three very general facilities:
- the "package" (a programmer-defined grouping, not limited to the
  object-oriented concept of "class");
- the "generic" (loosely, a type-safe "template" facility);
- separation of package specification from implementation.

Eiffel has a different set of basic blocks, including (it appears
to me) more features directly supporting these patterns
(selective export, multiple inheritance from abstract classes).

The hidden agenda of my posting was to respond to some people
saying "we can do X in Eiffel, so it's better than Ada."  I
listed how to do all those X's, and more.  I certainly expected
Eiffel to support them, and I was interested to read how.  Thanks.


> Perhaps it's nicer to have
> the language help you out with these design patterns?  I don't
> know.

I think it's more a question of WHICH design patterns are directly
supported.  One can consider object-oriented programming a design
pattern.  Any language directly supports a set of design approaches,
and (if well designed) supports others with programmer discipline.

Ada pretty well supports building large, reliable software, to be
maintained over time, with a big team of developers, using
traditional methods (which now includes object-oriented methods,
but didn't in 1983).


> But I think there's a lot of value to Eiffel's simplicity
> and orthogonality which allows you to put together constructs
> in an intuitive manner which can achieve these things.

I would agree, and make exactly the same statement about Ada.

Note that programming can be divided orthogonally in various ways.
If you look at a basic capability supported by Eiffel, and see how
it's implemented using Ada, you may have to combine a number of
orthogonal Ada facilities.  The reverse is also true.

Ada does include more functionality in the language, and
represents a different design point.  However, the philosophy
of providing a set of orthogonal "building blocks" is the
same.  Indeed, maintaining this approach was one of Tucker
Taft's primary guidelines as he led the Ada 9X design.

Samuel Mize

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Jon S Anthony wrote:

:In article <EFv7yL.yr@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

[..]

:> package body Q is
:>   procedure Do_Something (X: T) is begin .. end;      -- effective
:> end;
:
:Actually, the body has nothing to do with it.  

It's there for completeness.

:The concrete declaration in the spec. is the "effective" one (there could be many
:[completely different] bodies implementing it)

True, just as you could have different versions of an Eiffel class that match 
the same short form (possibly previously generated by another version and 
frozen in CM).


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Erik Ernst]

Samuel Mize <smize@link.com> writes:
> Patrick Doyle wrote:
> > [..]
> >   What can you do with a hand-written package spec that you can't
> > do with the Eiffel tools?

I can't resist the temptation to mention that there are other
possibilities;  you are comparing the two approaches:

  (1) Writing a complex entity [e.g. a class] in one modular unit
      [e.g. file]; possibly using tool support to extract aspects.
      This is the Eiffel way.

  (2) Splitting a complex entity into an external and an internal
      aspect [e.g. interface and implementation] by a language
      mechanism which requires repeating the skeleton in order to 
      recombine the two separated aspects [e.g. routine signatures 
      are duplicated].  This is the Ada way.

(1) is said to be good because it avoids code duplication, giving
better consistency and less tedium when writing/updating/managing.
(2) is said to be good because it protects the interface from
accidental or insignificant changes, probably leading to fewer
unnecessary recompilations, and because programmers understand the
role of an interface better when it exists separately.  The itemized
list by Samuel Mize quoted at the end of this posting give more
examples of attractive possibilities. 

An obvious third approach (obvious because I'm using it every day ;-)
uses a _separate_ (mini)language to handle modularization:

  (3) Using an orthogonal physical-organization language which allows
      splitting a complex entity expressed in the main language in
      many different ways, and which supports flexible visibility
      management among these modular units.  The recombination of the
      separate code fragments has minimal duplication: each code
      fragment has a name, and the place where it belongs is marked
      with that name.

Eiffel does not support physical separation of different aspects of
the source code (such as interface/implementation).  Assuming that
such a physical separation is actually valuable, we could make the
experiment of putting it in!  From now on I use the word "file" to
refer to whatever modular unit the language environments uses.  

The class: 

  ----------------------------------------
    class PERSON2 feature
      name: STRING
      loved_one,landlord: PERSON2

      set_loved(l: PERSON2) is
	  -- attach the loved_one field of current object to l.
	do
	  loved_one := l
	end
    end
  ----------------------------------------

could be fragmented into an interface part and an implementation part: 

  ----------------------------------------
    class PERSON2 feature
      <<PlaceHolder(Feature_declaration_list):person2_attributes>>

      set_loved(l: PERSON2) is
	  -- attach the loved_one field of current object to l.
	<<PlaceHolder(Effective):set_loved>>
	end
    end
  ----------------------------------------
    <<Fragment:person2_attributes>>
    name: STRING
    loved_one,landlord: PERSON2

    <<Fragment:set_loved>>
    do loved_one := l
  ----------------------------------------

Think of it as search'n'replace: put the code 'Fragment' where the
'PlaceHolder' appears.  'Effective' says that the "unknown piece of
code" is syntactically derived from the nonterminal 'Effective'.  This
ensures that syntax errors and ambiguities cannot arise when putting
the pieces together. 

A good compilation system would of course not actually do the
search'n'replace---clients should not be recompiled just because the
implementation changes---but the semantics should be as-if.

For some purposes, we might prefer to link the PERSON2 interface with
another implementation:

  ----------------------------------------
    <<Fragment:person2_entitites>>
    name: STRING
    landlord: PERSON2
    loved_ones: LINKED_STACK[PERSON2] 
      -- ought to make this non-void somewhere ;-)

    <<Fragment:set_loved>>
    do loved_ones.push(l)
  ----------------------------------------

This is a compile-time choice between two different implementations.
If inheritance is preferably used for conceptual modelling, there is a
need for a separate mechanism for such things---using inheritance to
choose between two different implementations would pollute the
inheritance hierarchy with implementation considerations.  Moreover,
the polymorphism implied by the inheritance approach would prevent a
fast, static routine dispatch, which could be achieved with the
'Fragment'/'PlaceHolder' driven approach.  There is a
too-much-generality cost when using inheritance, one might say.. 

Of course, the standard Eiffelish reaction would be "there should not
be any other notion of module than that of a class", and perhaps
"short/flat is at least as good a solution as having physical
separation of interface and implementation", so I'm presumably mostly 
speaking to the Eiffel underground, if such one exists ;-)

Anyway, it works perfectly well in BETA, and it certainly supports 
the below mentioned cases (though "Multiple implementations, run time"
would also be handled with polymorphism in BETA, and "Multiple
implementations, item-specific, compile time" would be handled with
virtual patterns). 

Here are all the interesting challenges, as written by Samuel Mize:

> I'm not familiar with Eiffel.  Let me tell you a few things we
> do in Ada, and you can tell me if the tools support it or not.
> I'd be quite interested to know how the short-flat extraction tool,
> or the deferred class approach, address these.  NOTE: I'M NOT
> SAYING THEY CAN'T, I'M ASKING HOW THEY DO IT.  Please don't
> assume this is an attack; it isn't.  I'ts a request for info.
> 
> Please specify whether the practice you suggest is commonly
> done.  I've listed things that I've seen done several times for
> real production code.  I'm especially curious if the deferred-class
> approach that Patrick Doyle suggests is a common idiom in Eiffel.
> 
> Some capabilities that are provided by Ada's separate spec/body
> approach are:
> 
> * Different order of subprograms -- one order or grouping may be
>   most meaningful for the interface, another for implementation.
> 
> * Unexported (local to the package) subprograms and declarations.
> 
> * Different comments -- the Ada spec usually contains comments that
>   describe what facility a subprogram provides and how to use it,
>   the package contains a description of its implementation details.
> 
> * Interface control and verification -- the Ada spec can be written
>   and published, and other groups can code against it.  If the
>   implementation or the client changes, the compiler can verify that
>   they are still consistent without having to reprocess both.
> 
> * Multiple interfaces -- you can have several sub-packages that
>   export subsets of a package's functionality.  In Ada 83, if
>   visibility into the body (implementation) is required, these
>   must all be contained in the main package's spec; in Ada 95,
>   they can be separate child packages.  In either case, if you
>   just want to re-package existing functionality to provide
>   different views, you can provide "view" packages that rename
>   elements from the main ("full-view") package.
> 
> * Multiple implementations, global, compile time -- you can have
>   many implementations of your package spec, and select the best
>   one for your application at compile time.  Thus, your "list"
>   could have a hash table for faster lookup, or store its contents
>   to disk to allow long lists of huge data items (just one in
>   memory at a time), or whatever -- as long as the spec stays the
>   same, the client code doesn't need to be recompiled.
> 
> * Multiple implementations, item-specific, compile time --
>   Ada generics can provide a unified interface for several
>   implementations of a facility.  Any logic that is common across
>   all the implementations is written into the generic, while any
>   code that is implementation-specific is provides as subprograms
>   that are parameters to the generic.  In the worst case, the
>   generic only provides a "template" that instantiations must
>   follow.  For example:
> 
>     generic
>       type Item is private;
>       type Stack is private;
>       with procedure Push (S: in out Stack; I: in out Item);
>       with procedure Pop (S: in out Stack; I: in out Item);
>     package Generic_Stack is
>       -- exports the procedures imported
>       procedure Push (S: in out Stack; I: in out Item);
>       procedure Pop (S: in out Stack; I: in out Item);
>     end Generic_Stack;
> 
>   This generic just encapsulates an interface.  If you write clients
>   that instantiate it, and implementation packages that can be used
>   to instantiate it, then you know any client can switch to any
>   implementation with a simple, compile-time change to the client
>   code (where it instantiates the generic).
> 
> * Multiple implementations, run time -- these are best supported in
>   Ada by dispatching subprograms and tagged types, not by packaging.


   cheers,

--
Erik Ernst                            eernst@daimi.aau.dk
Computer Science Department of Aarhus University, Denmark
Check <URL:ftp://ftp.daimi.aau.dk/pub/empl/eernst/gbeta/>

Re: Interface/Implementation (was Re: Design by Contract)

[Joerg Rodemann]

Don Harrison (nospam@thanks.com.au) wrote:
> :* Interface control and verification -- the Ada spec can be written
> :  and published, and other groups can code against it.  If the
> :  implementation or the client changes, the compiler can verify that
> :  they are still consistent without having to reprocess both.

> Possible in any IDE supporting freezing of short forms.

> :* Multiple implementations, global, compile time -- you can have
> :  many implementations of your package spec, and select the best
> :  one for your application at compile time.  Thus, your "list"
> :  could have a hash table for faster lookup, or store its contents
> :  to disk to allow long lists of huge data items (just one in
> :  memory at a time), or whatever -- as long as the spec stays the
> :  same, the client code doesn't need to be recompiled.

> Possible in any IDE supporting multiple class texts.

Well, twice you mention the need of an IDE...so tell me, does the Eiffel
IDE that works just so wonderfully work when your terminal and your host
computer are separated by a firewall? Does it come with vi? emacs? Surely
you know, tastes differ wrt this. (I never got accustomed to MS's great M.)
What if you have to get along with an environment that is hopefully at least
vt100 capable...? I think this may be not too uncommon.

With Ada, to start working I 'just' need a compiler/linker combination.
But from then on I AM able to work. Perhaps not with all the worlds luxuries
and little add-ons and features, but it is possible. However, if I need
a fully blown-up intelligent IDE, then I am lost. (Since I am sure there
won't be any ports to some platforms I am interested in.) Surely Ada has
a better stand in here...but sadly --- if you want oo at all --- often C++
only wins. Maybe this will change some day. *sigh*

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: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> IMHO, this is how it should be. One of the annoying things I find with the
> ability to order operations differently in Ada spec and body is that you
> see them in a certain order in the spec and may have trouble finding them
> in the body because they've been re-ordered, often due to compilation
> dependencies. IMO, there's no excuse for imposing dependency-related ordering
> in an age of multi-pass compilation.

This seems a little bit 'off' - Anything in an Ada body can see
everything
in the spec.  The spec may be ordered to make things easy for the client
to read.  The body may be ordered to make the implementation easy to
understand.
And with many support tools (such as are nearly mandatory for a large
product)
finding the body depends on the tool, not on the sequence.

> As Patrick explained, comments are either extracted or ignored on the basis of
> where they appear in the class text. Those in interface-specific parts of the
> text are extracted into the short form. 

Does this mean the accuracy and usefulness of the "spec" depends on the 
coder's compliance with style rules that are not automtically enforced?

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Patrick Doyle wrote:

:In article <EFv7yL.yr@syd.csa.com.au>,
:Don Harrison <nospam@thanks.com.au> wrote:
:>:>> >More to the point: not _relevant_ in the Ada case as this is handled
:>:>> >by a different orthogonal capability 
:>
:>Agree. Multiple, polymorphic implementations are provided by deferred classes
:>and abstract types in Eiffel and Ada respectively. As Jon says, this is an 
:>orthogonal concept to interfaces.
:
:Thanks, but I didn't say that.  I think Jon said it.

Yes, he did and I was aware of it. I admit my attribution wasn't clear.

:>:>> using a deferred class is more powerful than a simple interface
:>:>> file, and can accomplish all the same things, so why split
:>:>> this into two concepts?
:>
:>Because they serve different purposes. (See my previous post).
:
:But the deferred class can serve both purposes, can't it?

Not in the Ada or Modula sense of the term "interface". I expect the situation 
is made somewhat confusing by different nomenclature. Equating Eiffel deferred
classes with Java "interfaces" may make sense, for example. (Not sure as 
I'm not a Java expert.) But in terms of the Ada/Modula idea of interfaces 
(which is the context of this discussion - separate interface and implementation), 
deferred classes are not the correct analogue. 

For example, consider an effective class which inherits only from effective 
classes. There is no deferred class in this situation, so you obviously can't 
use one as an interface. But, clearly, the class *does* have an interface and
we see it exists as the short form. I dismiss as nonsensical the notion that 
a deferred class can be the analogue in one situation and the short form in 
another.

Also, this example shows that it's false to claim that deferred classes can do 
all that separate interfaces (or short forms) can do. 

Something that may further help to cement the difference is to consider that 
a deferred class has a short form and hence has an interface in the Ada/Modula
sense. If the deferred class itself is an interface, how can it also have 
its *own* interface? This would be a meta-interface - a nonsensical concept.
The fact that it *does* legitimately have an interface suggests that it isn't 
an interface in the first place in the Ada/Modula sense.

I think the key to getting a handle on this is to recognise that short forms 
and deferred classes serve different, *non-overlapping* purposes.

:>Try thinking along the lines of
:>
:>  a) Ada interfaces correspond to Eiffel short forms, and
:>  b) Ada abstract types correspond to Eiffel deferred classes.
:
:Yes, I'm aware that there is an analogy there.  

Okay.

:But I think the analogy is granted too much weight in terms of its importance 
:to programming.
:
:It's my position (until further enlightenment :-) that abstract/
:deferred classes can do what separate interfaces do, and more, so
:why do we need separate interfaces?

A few things here..

First, deferred classes *can't* do everything a short form (or separate 
interface) can do - see our example above.

Second, they serve a different purpose completely unrelated to interface 
specification (in the Ada/Modula sense) so are irrelevant to the separate
interface - implementation issue.

Third, if we compare the mechanisms that *are* relevant to this issue -
Eiffel short form and Ada package specs - we can see that we don't need 
separate interfaces. (I won't repeat what others have already covered.) 
In other words, I agree that we don't need separate interfaces, but disagree 
with your reasoning.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[John G. Volan]

Patrick Doyle wrote:
> 
> It's my position (until further enlightenment :-) that abstract/
> deferred classes can do what separate interfaces do, and more, so
> why do we need separate interfaces?

Well, one problem with using abstract/deferred classes as a simulation
for separate interfaces, is that the former might do _too much_. You
wind up getting polymorphic dynamic dispatching in situations that don't
really call for it.  This can result in an unnecessary run-time
performance penalty when a given program includes only one concerete
implementation class for a given abstract class (unless your programming
environment is able to detect and optimize this situation).

In Ada, every single package must have a separate spec, so Ada
programmers are used to applying this pattern everywhere.  But I'd wager
that very few Eiffel programmers would consider introducing an abstract
parent class for every one of their concrete classes, just to simulate
Ada packaging.  I'd assume that abstract/deferred classes appear in
typical Eiffel programs just as frequently as abstract tagged types do
in Ada95 programs, and that they typically serve the same role:
implementing generalization/specialization hierarchies. 

So I don't see abstract classes as a very good mapping for Ada package
specs, and I agree with those who compare Ada specs to Eiffel short
forms.

One thing I'm curious about: Can an Eiffel environment tell the
difference between an interface modification and an implementation
modification?  Suppose a programmer edits a class text and only makes
changes to its implementation (like changing a few statements in the
body of a method) but doesn't make any interface changes (like changing
the number and/or types of the method arguments).  Semantically, an
implementation change shouldn't obsolete the compilation of any client
that only depends on the class interface.  Will a typical Eiffel IDE be
able to distinguish this as an implementation-only change, or will it
force the recompilation of all client classes?

Conversely, suppose you do make an interface change. Will the IDE detect
this and require that all client classes be recompiled?  Or is it
possible in Eiffel to generate an incorrect executable by linking a
class's object code with obsolete client object code?

An Ada system can easily distinguish these situations, because the spec
and body of a package are separate constructs, typically in separate
files.  But an Eiffel system would need to be able to take a class text
and sift the interface out from the implementation, in order to avoid
recompilations when they are not needed but enforce them when they are
needed.  Do Eiffel systems, in practice, do a good job with this?
-- 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> In Ada, every single package must have a separate spec, so Ada
> programmers are used to applying this pattern everywhere.  But I'd 
> wager that very few Eiffel programmers would consider introducing an 
> abstract parent class for every one of their concrete classes, just to 
> simulate Ada packaging.  ....

Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
he/she could actually use Ada?  (And vice versa, lest anyone think
I'm making another language-bigot comment...)

The discussion of language merits is not served by either side
trying to avoid consideration of a difference by offering a kludgy
workaround of the other language's feature.

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

W. Wesley Groleau wrote:

:> IMHO, this is how it should be. One of the annoying things I find with the
:> ability to order operations differently in Ada spec and body is that you
:> see them in a certain order in the spec and may have trouble finding them
:> in the body because they've been re-ordered, often due to compilation
:> dependencies. IMO, there's no excuse for imposing dependency-related ordering
:> in an age of multi-pass compilation.
:
:This seems a little bit 'off' 

Presumably, you mean unpalatable rather than untrue. :)

First, you didn't answer my question:

  "Does the Ada95 standard impose dependency-related ordering?"

Eiffel has no such dependency ordering - if one operation calls another, you 
can declare the called operation later in the text.

- Anything in an Ada body can see everything in the spec.  

I didn't say it couldn't.

:The spec may be ordered to make things easy for the client to read.  
:The body may be ordered to make the implementation easy to understand.

With Eiffel, you have both and ordering is preserved.

:And with many support tools (such as are nearly mandatory for a large
:product) finding the body depends on the tool, not on the sequence.

(For the benefit of those who may not know what you mean here, by "body" you 
mean an "operation/task/whatever body" (implementation) rather than "package body".)

Okay, if your tools are sophisticated enough to find the operation for you 
then that would help. It's true that in that case, the ordering in the package 
body shouldn't matter. However, your comment about making an implementation 
easy to understand implies that ordering *is* signigicant. Are you referring 
there to more primitive tools such as text editors?

Text editors are what I'm talking about. In particular, I'm referring to 
the situation of scrolling through a package body and expecting to find 
operations in the same order as the spec and finding they're not, and then
having to search for them.

:> As Patrick explained, comments are either extracted or ignored on the basis of
:> where they appear in the class text. Those in interface-specific parts of the
:> text are extracted into the short form. 
:
:Does this mean the accuracy and usefulness of the "spec" depends on the 
:coder's compliance with style rules that are not automtically enforced?

Yes, in the same way that the usefulness of comments in Ada programs depends 
on adherence to style rules.

BTW, how do you "automatically enforce" the existence and content of optional
free text?


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <340F3801.47E5@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>
>> As Patrick explained, comments are either extracted or ignored on the basis of
>> where they appear in the class text. Those in interface-specific parts of the
>> text are extracted into the short form. 
>
>Does this mean the accuracy and usefulness of the "spec" depends on the 
>coder's compliance with style rules that are not automtically enforced?

  What do you mean by "enforced"?  How could they be any more "enforced"
than to either be or not be included in the short form?  How can the
compiler tell what kind of comments you are adding if you add them
wrong?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

In article <EFyrH2.7z2@syd.csa.com.au>, nospam@thanks.com.au wrote:

>IMO, there's no excuse for imposing dependency-related ordering 
>in an age of multi-pass compilation.

Note that many computer scientists, among them Tony Hoare, believe that a
measurement of goodness of a language is its ability to be compiled using a
single pass.  In that tradition, Ada was design so that it could be
compiled in a single pass.

>Does the Ada95 standard impose dependency-related ordering?

Ada was designed in the belief that the source text of a program has two
consumers: the human reader, and the Ada compiler.  As such, the Ada
philosophy is that, when reading the code, one's understanding of the code
should only depend on what has come before.  So yes, if there is a
dependency ordering between two subprogram bodies, then either the
dependent body must follow the other, or a specification for the body must
preceed the dependent body (subprogram specs can appear in the package
body).

That there is a dependency-related ordering in Ada (both 83 and 95) is by
design; that was the precise intent of Ada's designers.  This should be
regarded as a Good Thing, because it makes it easier for the human reader
to apprehend program text.

The same philosophy applies to exits from inside a loop

loop

   <text>

   exit when <predicate>

   <more text>

end loop;

Many programmers think that it's better to use a while loop, ie

while not Done loop

   <text>

   Done := True;

   if not Done then
      <more text>
   end if;

end loop;

But this is much worse solution, not only because it requires introduction
of a flag, but because the human reader has to think about what happens
_after_ the flag gets set (does anything else need to get executed prior to
the end of the loop?).  The poor reader has to study the _entire_ loop. 
With the exit approach, comprehension only depends on what has come before.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> :> IMHO, this is how it should be. One of the annoying things I find with the
> :> ability to order operations differently in Ada spec and body is that you
> :> see them in a certain order in the spec and may have trouble finding them
> :> in the body because they've been re-ordered, often due to compilation
> :> dependencies. IMO, there's no excuse for imposing dependency-related ordering
> :> in an age of multi-pass compilation.
> :
> :This seems a little bit 'off'
> 
> Presumably, you mean unpalatable rather than untrue. :)

No. I mean both.  Untrue because IF the order in the body is 
changed, it is NOT due to compilation dependencies, AND "in an 
age of" modern tools (such as 'grep') there no reason for the 
order to make things hard to find.  Unpalatable, because one 
of Ada's lower priority goals was to make a one-pass compiler 
possible though not mandatory.

>   "Does the Ada95 standard impose dependency-related ordering?"

To some extent, as stated above.  But things declared in a legal
order in the spec do not have to have their repetitions in the 
same order in the body.  (And let's not start about repetitions
again.  We've already established either that this kind of 
repetition is not a problem, or that arguing about it will 
accomplish NOTHING.)

> - Anything in an Ada body can see everything in the spec.
> I didn't say it couldn't.

That was the implication (to me) of your complaint about re-ordering.
How could it be re-ordered if it is only in the body?

> :The spec may be ordered to make things easy for the client to read.
> :The body may be ordered to make the implementation easy to understand.
> 
> With Eiffel, you have both and ordering is preserved.

What?  IF one sequence is better for the spec (short) and another
is better for the implementation, how can a single sequence be 
_best_ for both.  However, let's not get into a flame war on this--
ordering is NOT a particularly important matter.

> :And with many support tools (such as are nearly mandatory for a large
> :product) finding the body depends on the tool, not on the sequence.
> 
> (For the benefit of those who may not know what you mean here, by "body" you
> mean an "operation/task/whatever body" (implementation) rather than "package body".)

Right.

> Okay, if your tools are sophisticated enough to find the operation 

at least as sophisticated as 'grep', or the 'find' function of most
editors (even 'more' has _that_).

> then that would help. It's true that in that case, the ordering in the package
> body shouldn't matter. However, your comment about making an implementation
> easy to understand implies that ordering *is* signigicant. Are you referring
> there to more primitive tools such as text editors?

No, to more primitive tools like paper.

> ... I'm referring to
> the situation of scrolling through a package body and expecting to 
> find operations in the same order as the spec and finding they're 
> not, and then having to search for them.

If you are looking for a particular operation, why are you scrolling
through?  If you are trying to understand an operation's 
implementation, you look at it, and if it calls another, you may
choose to find that.  If your only method for finding it is by
remembering its position in the spec, well, then you have an
inconvenience. If you are trying to understand the package
implementation as a whole, then it is possible that a particular
ordering will make that easier.  But again, we're arguing VERY small
nits.
> :Does this mean the accuracy and usefulness of the "spec" depends on 
> :the coder's compliance with style rules that are not automtically 
> :enforced?
> 
> Yes, in the same way that the usefulness of comments in Ada programs 
> depends on adherence to style rules.

There is a difference between the usefulness of the "spec" (which 
I've been led to believe in Eiffel _includes_ certain essential 
comments), and the usefulness of comments themselves (which in Ada
are of secondary value to the actual "code."  Put another way,
is a short (or short flat) adequate for me to code a client if
the coder did not put his comments in the right place or format?

In Ada, _IF_ the usefulness demanded comments, and those comments
were put in the spec, they would not disappear from the spec
if their format was "wrong".  I don't say this to slam Eiffel,
because I suspect that you did not mean what you appeared to say.

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <340F3801.47E5@pseserv3.fw.hac.com> "W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com> writes:

<somebody said>
> > IMHO, this is how it should be. One of the annoying things I find with the
> > ability to order operations differently in Ada spec and body is that you
> > see them in a certain order in the spec and may have trouble finding them
> > in the body because they've been re-ordered

This seems _really_ odd given that the idea of outside IDE support is
so often bandied about by Eiffel proponents.  Come on, this is
_trivial_ and fully supported by any decent IDE.  For example, ever
use imenu in emacs?  Gives an indexed listing of the functions (in
either spec or body) and you can simply click to get there.  Or, just
find it in the spec and flip to the body - voila' you are on the
functions implementation.  Really, this is just bogus.


<and this somebody continues>
> > , often due to compilation dependencies. IMO, there's no excuse
> > for imposing dependency-related >ordering in an age of multi-pass
> > compilation.

And this is just plain wrong.  Any particular reason why you feel the
need to go around spouting obvious falsehoods?  Also, multi-pass
compilation has existed for over 30 years (probably longer) so this is
just plain irrelevant.

These two bits end up making you look completely clueless...

/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: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

iSamuel Mize in his nice list says

<<* Different order of subprograms -- one order or grouping may be
  most meaningful for the interface, another for implementation.
>>

I find this very useful. If you look at the GNAT sources, you will see
that the specs are typically in some useful logically grouped order
by subprograms, but the body is in alphabetical order for easier
reference.

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EG0upp.Irq@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

>   "Does the Ada95 standard impose dependency-related ordering?"

Not in the sense you mean here (i.e., the old Ada83 sense).


> Okay, if your tools are sophisticated enough to find the operation
> for you then that would help. It's true that in that case, the
> ordering in the package body shouldn't matter.

Anyone relying on outside tool support to generate things like the
short form, etc. really shouldn't be implying that the sort of tool
mentioned here is somehow advanced and/or rare.  It's not.


> Text editors are what I'm talking about. In particular, I'm
> referring to the situation of scrolling through a package body and
> expecting to find operations in the same order as the spec and
> finding they're not, and then having to search for them.

Come on Don - if you use something as primitive as vi, well whatever.
However, any remotely reasonable IDE will give you "jump to this
functions impl".

/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: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> >Does this mean the accuracy and usefulness of the "spec" depends on 
> >the coder's compliance with style rules that are not automtically 
> >enforced?
> 
>   What do you mean by "enforced"?  How could they be any more 
> "enforced" than to either be or not be included in the short form?  
> How can the compiler tell what kind of comments you are adding if 
> you add them wrong?

That's the point.  The implication has been made that certain types
of comments are needed in the short form, and to get them there, one
has to follow some rule which has not been stated in this thread.

Whereas if the spec is a truly separate item (not generated by a tool)
any comments it has (right or wrong) can not be omitted by the
non-existent extraction process.  Nor can the non-existent extraction 
process add something from the implementation.

Keep in mind while discussing this whole matter that Bertrand Meyer
has already stated one of his premises is the idea that treating
design as a separate phase from implementation is a Bad Thing.
The Ada philosophy _at_least_in_the_matter_of_interfaces_ disagrees.

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Joerg Rodemann wrote:

:Don Harrison (nospam@thanks.com.au) wrote:
:> :* Interface control and verification -- the Ada spec can be written
:> :  and published, and other groups can code against it.  If the
:> :  implementation or the client changes, the compiler can verify that
:> :  they are still consistent without having to reprocess both.
:
:> Possible in any IDE supporting freezing of short forms.
:
:> :* Multiple implementations, global, compile time -- you can have
:> :  many implementations of your package spec, and select the best
:> :  one for your application at compile time.  Thus, your "list"
:> :  could have a hash table for faster lookup, or store its contents
:> :  to disk to allow long lists of huge data items (just one in
:> :  memory at a time), or whatever -- as long as the spec stays the
:> :  same, the client code doesn't need to be recompiled.
:
:> Possible in any IDE supporting multiple class texts.
:
:Well, twice you mention the need of an IDE...

Yes, only because I consider that to be the ideal way of developing. 
But, while a sophisticated IDE may be the optimal tool, it isn't actually 
*necessary*, as such.

Any of this CM-related or Change Control-related functionality can be done 
handraulically in the absence of such support from an IDE or if you have a 
preference for using particular tools not available through the IDE. This 
would involve writing some scripts to make the job easier but it wouldn't be 
difficult by any means.

:With Ada, to start working I 'just' need a compiler/linker combination.
:But from then on I AM able to work. Perhaps not with all the worlds luxuries
:and little add-ons and features, but it is possible. However, if I need
:a fully blown-up intelligent IDE, then I am lost.

If that's all you want, then you have that option. You can either use a 
sophisticated IDE or use a basic compiler/linker. For example, without 
intending any criticism, SmallEiffel (the free compiler), is basically 
just a command-line driven compiler. No doubt, people use it in conjunction 
with a variety of other tools.

:(Since I am sure there won't be any ports to some platforms I am 
interested in.)

Which ones are you interested in?

While none of the supported platforms are too esoteric, there are some realtime 
platforms, including VxWorks, for example. Also, there's an expressed 
willingness from some vendors to support others, presumably on the basis of 
demand. From ISE's recent announcement of "Embedded Eiffel":

   "- A version of ISE Eiffel 4 that runs on Windriver's
      VxWorks (TM) operating system for host-to-target
      development and debugging. This version can be adapted
      to other real-time operating systems.

      ...

    - Benefit from the portability of ISE Eiffel, running
      with identical source code on all major industry
      platforms including Windows NT, Windows 95, Unix
      (HP-UX, Solaris, SunOS, SGI, RS/6000, UnixWare etc.),
      Linux, VMS."

:Surely Ada has a better stand in here...

No doubt there are more embedded platforms currently supported by Ada but Ada 
vendors will also be limited by demand in terms of which they can support.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <EFyK17.2wD@syd.csa.com.au>,
Don Harrison <nospam@thanks.com.au> wrote:
>Patrick Doyle wrote:
>
>:In article <EFv7yL.yr@syd.csa.com.au>,
>:Don Harrison <nospam@thanks.com.au> wrote:
>:>
>:>Because they serve different purposes. (See my previous post).
>:
>:But the deferred class can serve both purposes, can't it?
>
>Not in the Ada or Modula sense of the term "interface". I expect the situation 
>is made somewhat confusing by different nomenclature. Equating Eiffel deferred
>classes with Java "interfaces" may make sense, for example. (Not sure as 
>I'm not a Java expert.) But in terms of the Ada/Modula idea of interfaces 
>(which is the context of this discussion - separate interface and implementation), 
>deferred classes are not the correct analogue. 

  Ok, let's boil this down to two questions:

1. What is the purpose of short forms/Ada interfaces?
2. Why can't deferred classes accomplish this purpose?

>For example, consider an effective class which inherits only from effective 
>classes. There is no deferred class in this situation, so you obviously can't 
>use one as an interface. But, clearly, the class *does* have an interface and
>we see it exists as the short form. I dismiss as nonsensical the notion that 
>a deferred class can be the analogue in one situation and the short form in 
>another.

Well, before you dismiss it, let me make a case for a very similar
situation...

If you want to look at the whole interface of a class, you can use
Eiffel's "short" tool to extract it.  What the short tool produces is
code which is, effectively, the deferred class which would correspond
to the effective class in question (except that it is missing the
word "deferred" in certain places).

So if you want to specify an interface, use a deferred class.  If you
already have an effective class and want to see its interface, you
can simply look at its deferred parent class (if it was designed with
one) or, failing that, the "short" tool can rig one up for you.

>Also, this example shows that it's false to claim that deferred classes can do 
>all that separate interfaces (or short forms) can do. 

I haven't yet seen you describe just what an interface or short form *does*.

>Something that may further help to cement the difference is to consider that 
>a deferred class has a short form and hence has an interface in the Ada/Modula
>sense. If the deferred class itself is an interface, how can it also have 
>its *own* interface? This would be a meta-interface - a nonsensical concept.

I think this still makes sense.  The short form is only missing the
word "deferred" (and some other trivial syntactical niceties) in the
appropriate places.  Add these back in, and the resulting deferred
class is exactly the same as the original class.  Thus, the class *is*
its interface.  

I could create a DoyleShort tool which produces the same thing as the
Short tool, except with the "deferred" etc. in the appropriate places.
If I follow your reasoning, the Short tool's output would then correspond
to an Ada interface, while DoyleShort's output would correspond to an
abstract package (is that the term?) in Ada.  Yet the only difference
is the word "deferred".  How can such a trivial difference make the
two concepts orthogonal?

>The fact that it *does* legitimately have an interface suggests that it isn't 
>an interface in the first place in the Ada/Modula sense.

Unless the interface is identical to the class itself.

>I think the key to getting a handle on this is to recognise that short forms 
>and deferred classes serve different, *non-overlapping* purposes.

I'm ready to accept this if someone would just tell me what these purposes
are.

>:It's my position (until further enlightenment :-) that abstract/
>:deferred classes can do what separate interfaces do, and more, so
>:why do we need separate interfaces?
>
>A few things here..
>
>First, deferred classes *can't* do everything a short form (or separate 
>interface) can do - see our example above.

I'm sorry--it's been a long day--but I didn't see you explain what
short forms or interfaces *do* at all.

>Second, they serve a different purpose completely unrelated to interface 
>specification (in the Ada/Modula sense) so are irrelevant to the separate
>interface - implementation issue.
>
>Third, if we compare the mechanisms that *are* relevant to this issue -
>Eiffel short form and Ada package specs - we can see that we don't need 
>separate interfaces. (I won't repeat what others have already covered.) 
>In other words, I agree that we don't need separate interfaces, but disagree 
>with your reasoning.

Well, thanks for your patient attempts to persuade me :-) but I'm still
a bit puzzled...

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Franck Arnaud]

John G. Volan:

> This can result in an unnecessary run-time performance penalty when 
> a given program includes only one concerete implementation class for 
> a given abstract class (unless your programming environment is able 
> to detect and optimize this situation).

All Eiffel compilers do that optimisation (and they have to as any
routine could be polymorphic).

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

Patrick Doyle wrote:
> 
> >Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
> >he/she could actually use Ada?  (And vice versa, lest anyone think
> >I'm making another language-bigot comment...)
> >
> >The discussion of language merits is not served by either side
> >trying to avoid consideration of a difference by offering a kludgy
> >workaround of the other language's feature.
> 
>   Being the one who seems to be pursuing this quest, I'll explain
> myself.
> 
>   I'm not trying to emulate Ada.  Creating an interface that can be
> frozen for programmers to work against is a very important thing.
> On first glance, it seems there's no easy way to do that in Eiffel,
> .... and so the Ada people have a great deal of experience
> with this methodology; so I was asking them about using deferred
> classes because presumably they'd be the best ones to find the
> flaws in the deferred class methodology.

Well, your rationale for the question is valid.  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."

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <340F39E3.4B71@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>
>Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
>he/she could actually use Ada?  (And vice versa, lest anyone think
>I'm making another language-bigot comment...)
>
>The discussion of language merits is not served by either side
>trying to avoid consideration of a difference by offering a kludgy
>workaround of the other language's feature.

  Being the one who seems to be pursuing this quest, I'll explain
myself.

  I'm not trying to emulate Ada.  Creating an interface that can be
frozen for programmers to work against is a very important thing.
On first glance, it seems there's no easy way to do that in Eiffel,
besides using the Short tool and checking the output for changes.

  My point is that deferred classes *are* interfaces, so if you
want to freeze an interface, freeze a deferred class.

  See--it has little to do with Ada.  I'm simply referring to Ada
because it has a built-in facility for creating interfaces for
every class, and so the Ada people have a great deal of experience
with this methodology; so I was asking them about using deferred
classes because presumably they'd be the best ones to find the
flaws in the deferred class methodology.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <340F20A0.49B5@ac3i.dseg.ti.com>,
John G. Volan <johnv@ac3i.dseg.ti.com> wrote:
>
>Well, one problem with using abstract/deferred classes as a simulation
>for separate interfaces, is that the former might do _too much_. You
>wind up getting polymorphic dynamic dispatching in situations that don't
>really call for it.  This can result in an unnecessary run-time
>performance penalty when a given program includes only one concerete
>implementation class for a given abstract class (unless your programming
>environment is able to detect and optimize this situation).

The only time when dynamic dispatching can be avoided is when the
call is not polymorphic.  If it is polymorphic, then the compiler
can still optimize it anyway, so we haven't lost anything in this
department.

>In Ada, every single package must have a separate spec, so Ada
>programmers are used to applying this pattern everywhere.  

But is it really necessary everywhere?  Or just where interfaces
need to be frozen?

>But I'd wager
>that very few Eiffel programmers would consider introducing an abstract
>parent class for every one of their concrete classes, just to simulate
>Ada packaging.  I'd assume that abstract/deferred classes appear in
>typical Eiffel programs just as frequently as abstract tagged types do
>in Ada95 programs, and that they typically serve the same role:
>implementing generalization/specialization hierarchies. 

I'd tend to agree.  Using abstract parent classes in this manner
is a very important usage.  Using them to freeze an interface is
another important usage.

>So I don't see abstract classes as a very good mapping for Ada package
>specs, and I agree with those who compare Ada specs to Eiffel short
>forms.

I've argued before that an Eiffel short form is just an abstract
parent class generated after the fact.  So if Ada specs compare with
Eiffel short forms, then they compare with abstract parent classes.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Joachim Durchholz]

Joerg Rodemann wrote:
> > Which ones are you interested in?
> 
> Cray T3D/E, NEC SX-4, Intel Paragon, Sgi Origin MP (A group from
> vieanna
> used GNAT quite successfully on such a platform for a parallel
> application),
> IBM SP-2,...

Any platform that gcc can produce code for can run Eiffel code. Most (if
not all) Eiffel compilers can produce intermediate C code. You may run
into problems trying to get the C source for the run-time system, but
there's always SmallEiffel (which is free).

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]


In article <EG2Dv5.74D@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:


>In the entity-declaration case, we're talking about attaining
>a higher level of abstraction by separating the declaration of an
>entity from its implementation.  Does it really matter to the human
>if the implementation comes before or after the usage?

In order to understand something, you have to know a few other things. 
Because humans are complexity challanged (sp?; man, I've got to install my
spell-checker...) , we want to limit the amount of information the human
reader of the code has process in order to understand it.

If he has to scan past a point in the text in order to figure something
out, then there's a lot of stuff after that point, but prior to the point
containing the next useful piece of information.  But the reader doesn't
know what's useful and what's not, in order to understand this particular
problem, so he has to digest it all, and then prune away all the
unnecessary stuff after he's figured out his problem.  It seems that it
would be simpler for that reader, if in order to understand something, he
knows up front that all he needs to care about has already appeared.

That's why exit conditions from the middle of a loop make a lot of sense. 
As soon as the exit condition appears, then the reader can turn his brain
off, and scan past all the text prior to the end of the loop.  The precise
intention of the language designers is that this would limit the amount of
information the reader has to process in order to understand what he's
reading.

Incidently, the article Cognitive Strategies and Looping Constructs
(Soloway et al, CACM, Vol 26, No. 11, Nov 83, p. 853 - 860) described a
study demonstrating that exits from the middle a loop were easier for
programmers to understand and get right; they showed empirically that those
constructs had fewer errors.   Exit-from-the-middle loops better fit the
cognitive strategy used by real programmers: "When writing a simple looping
program, those using the loop .. leave .. again construct were more often
correct than were those using the standard Pascal loop constructs."

I wish everyone would read this paper, so we could end this perennial
debate.  "Programming is a human activity.  Forget that, and all is lost." 
(paraphrased from Stroustrup)  

>Consider this: the reason for this abstraction is that the human
>reader need not be bothered with unnecessary details.  If these
>details are unnecessary, who cares where they go?  And if they
>*are* necessary, then a human reader searching a single text file
>with any reasonable editor should have no trouble finding it.

But the reader of a piece of code doesn't know what's necessary and what's
unnecessary when trying to figure something out.  By enforcing dependency
order, you know up front that what comes before is necessary, and you only
need to keep reading until you figure your problem out; everything after
that point is unnecessary.

The Eiffel camp seems to think that dependency order is a limitation, but
it was a deliberate decision by Ada's designers.   As an Ada programmer, I
haven't found it to be a limitation at all; in fact, I find it quite
helpful, exactly as the designers imagined it would be.

To get random signatures put text files into a folder called �Random
Signatures� into your Preferences folder.

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <34104798.17D7@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>
>> [I said:]
>> 
>>   What do you mean by "enforced"?  How could they be any more 
>> "enforced" than to either be or not be included in the short form?  
>> How can the compiler tell what kind of comments you are adding if 
>> you add them wrong?
>
>That's the point.  The implication has been made that certain types
>of comments are needed in the short form, and to get them there, one
>has to follow some rule which has not been stated in this thread.
>
>Whereas if the spec is a truly separate item (not generated by a tool)
>any comments it has (right or wrong) can not be omitted by the
>non-existent extraction process.  Nor can the non-existent extraction 
>process add something from the implementation.

I see what you mean.  This is true.  However, remember that in order
for comments to appear in the interface file, the programmer must
put them *there* instead of the implementation file.  If this seems
trivial to you, then good, because I think it's trivial too.  But so
is putting the comments in the right place in Eiffel.

It looks like this:

class Goober
  feature Puree is
        -- Comments describing the interface
    do
        -- Comments describing the implementation
    end
end

See, the interface comments still appear in the interface, and the
implementation comments still appear in the implementation.  It's
just that they're in the same file now.

So whatever miniscule amount of mental discipline is necessary to put
comments in the right place in Ada applies to Eiffel too.

(BTW, I hope I got the comment placement right--I've never used the
short tool!)

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <JSA.97Sep5131901@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
><and this somebody continues>
>> > , often due to compilation dependencies. IMO, there's no excuse
>> > for imposing dependency-related >ordering in an age of multi-pass
>> > compilation.
>
>And this is just plain wrong.  Any particular reason why you feel the
>need to go around spouting obvious falsehoods?  Also, multi-pass
>compilation has existed for over 30 years (probably longer) so this is
>just plain irrelevant.

So you think there exists a reason to impose dependency-related
ordering?

>These two bits end up making you look completely clueless...

Boy, Jon, we really could have done without this wisecrack.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

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

On Fri, 05 Sep 1997 09:11:02 -0800, Matthew Heaney <mheaney@ni.net> wrote:
:Note that many computer scientists, among them Tony Hoare, believe that a
:measurement of goodness of a language is its ability to be compiled using a
:single pass.  

Did he say what the sign of the 'goodness delta' for a single pass was?
Maybe it's negative? :-) 


:In that tradition, Ada was design so that it could be
:compiled in a single pass.

What counts as a 'pass'?  

:>Does the Ada95 standard impose dependency-related ordering?
:
:Ada was designed in the belief that the source text of a program has two
:consumers: the human reader, and the Ada compiler.  As such, the Ada
:philosophy is that, when reading the code, one's understanding of the code
:should only depend on what has come before.  So yes, if there is a
:dependency ordering between two subprogram bodies, then either the
:dependent body must follow the other, or a specification for the body must
:preceed the dependent body (subprogram specs can appear in the package
:body).

Wow.  That is a really antideluvian mode of thought.

:That there is a dependency-related ordering in Ada (both 83 and 95) is by
:design; that was the precise intent of Ada's designers.  This should be
:regarded as a Good Thing, because it makes it easier for the human reader
:to apprehend program text.

Does it, really?  

Am I supposed to apprehend a whole program as if it were all dumped on
some line printer---but as if I had never read it before, like a novel?
Who would do that?  Dilbert's pointy-headed-boss? :-)  

In real life could I even REMEMBER which identifiers were identified when?
Or is this something that a computer can only remember perfectly?

In real life, while I'm programming, why am I supposed to have to
remember which things are "before" and "after", in some silly conflation of
location in a text document with 'time'?   Assuming I don't have a single
source file, is this at all justifiable?  
 

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <mheaney-ya023680000509970911020001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>In article <EFyrH2.7z2@syd.csa.com.au>, nospam@thanks.com.au wrote:
>
>>IMO, there's no excuse for imposing dependency-related ordering 
>>in an age of multi-pass compilation.
>
>Note that many computer scientists, among them Tony Hoare, believe that a
>measurement of goodness of a language is its ability to be compiled using a
>single pass.  

Holy cow.  I'm hard pressed to think of a criterion less relevant to
judging a computer language than this.  Does Mr. Hoare provide an
explanation for his position on this?

>In that tradition, Ada was design so that it could be
>compiled in a single pass.

Note than given a high enough memory-cleverness product, any language
can be processed in one pass.  Worst case, the entire text of the
program is read into memory (the one and only pass) and processed
there.  Of course, we can normally do better than that.

I find it amazing that this issue is given so much weight.  It's not
even the most important issue in compiler efficiency.  Look at C++:
it's designed to be processed in one pass, but its use of header
files which need to be re-parsed for each compilation unit is
inherently inefficient.  Precompiled headers help a lot, but the
point is that its one-pass nature doesn't.

>>Does the Ada95 standard impose dependency-related ordering?
>
>Ada was designed in the belief that the source text of a program has two
>consumers: the human reader, and the Ada compiler.  As such, the Ada
>philosophy is that, when reading the code, one's understanding of the code
>should only depend on what has come before.  So yes, if there is a
>dependency ordering between two subprogram bodies, then either the
>dependent body must follow the other, or a specification for the body must
>preceed the dependent body (subprogram specs can appear in the package
>body).

For the human understanding part, assuming that a person will only
understand what came before also means assuming that the source text
will be read in a linear fashion, which (in my experience) does not
seem to be an actual limitation of humans.

>That there is a dependency-related ordering in Ada (both 83 and 95) is by
>design; that was the precise intent of Ada's designers.  This should be
>regarded as a Good Thing, because it makes it easier for the human reader
>to apprehend program text.

I understand why it might be regarded as a Good Thing, but I'm more
inclined to regard it as an Unnecessary Restriction.

>The same philosophy applies to exits from inside a loop
>
>loop
>
>   <text>
>
>   exit when <predicate>
>
>   <more text>
>
>end loop;
>
>Many programmers think that it's better to use a while loop, ie
>
>while not Done loop
>
>   <text>
>
>   Done := True;
>
>   if not Done then
>      <more text>
>   end if;
>
>end loop;
>
>But this is much worse solution, not only because it requires introduction
>of a flag, but because the human reader has to think about what happens
>_after_ the flag gets set (does anything else need to get executed prior to
>the end of the loop?).  The poor reader has to study the _entire_ loop. 

I know that this point is incidental to the thread, but...

I agree that this is not always better, but I wouldn't call it "much worse".
What I would like to see is a loop structure like this:

while not (Done or Error_Occurred) loop
  ...
  if(Some condition) exit because Error_Occurred;
  ...
  if(Some other condition) exit because Done;
  ...
end loop;

This seems to me to have several advantages:

1. The exit conditions are in the header of the loop, concentrated
in one place for easy understanding of the loop.

2. It eliminates the nested if statements which would be required
for #1 if the "exit" command didn't exist.

3. When the "exit" command is encountered, the reader does not
have to be concerned with the rest of the loop.

4. After the loop, the reason for the termination can be determined:

while not (Done or ErrorOccurred) loop 
  ... 
end loop;
if(Done) then ... end if;
else
if(ErrorOccurred) then ... end if;

Of course, full understanding of a loop is impossible without studying
the entire body, but I think this methodology makes it as understandable
as possible without having to do that.

(BTW, notice how the body of the loop can be ellided in the above
example because all the necessary information is in the header.)

>With the exit approach, comprehension only depends on what has come before.

Yes, there seems to be an analogy here, but I think it's superficial.
Certainly the statement "comprehension dependy only on what has come
before" applies in both cases, but let's consider whether this is
really important.

In the loop-with-exit-flag case, the loop should logically terminate
when a condition occurs, but the coding style does not force this,
so the programmer is forced to inspect the code which follows the
exit command even though logically it should do nothing.

In the entity-declaration case, we're talking about attaining
a higher level of abstraction by separating the declaration of an
entity from its implementation.  Does it really matter to the human
if the implementation comes before or after the usage?

Consider this: the reason for this abstraction is that the human
reader need not be bothered with unnecessary details.  If these
details are unnecessary, who cares where they go?  And if they
*are* necessary, then a human reader searching a single text file
with any reasonable editor should have no trouble finding it.

Granted, this is not an argument against dependency-driven ordering,
but merely a rebuttal of your argument in favour of it.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Fergus Henderson]

jsa@alexandria.organon.com (Jon S Anthony) writes:

>Come on Don - if you use something as primitive as vi, well whatever.
>However, any remotely reasonable IDE will give you "jump to this
>functions impl".

Hey, vi can do that.  The command to jump to the definition of `this_func'
is

	:!make tags
	:tag this_func

or just control-], if the tags file is already up-to-date and
then cursor is on an occurrence of `this_func'.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <slrn611l25.mp.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) writes:

> :should only depend on what has come before.  So yes, if there is a
> :dependency ordering between two subprogram bodies, then either the
> :dependent body must follow the other, or a specification for the body must
> :preceed the dependent body (subprogram specs can appear in the package
> :body).
> 
> Wow.  That is a really antideluvian mode of thought.

Actually it is merely one way of getting at "consistent" elaboration
for consistent execution results.  It really has nothing to do with
compiling technology.

> :That there is a dependency-related ordering in Ada (both 83 and 95) is by
> :design; that was the precise intent of Ada's designers.  This should be
> :regarded as a Good Thing, because it makes it easier for the human reader
> :to apprehend program text.
> 
> Does it, really?

Who knows?  In some cases, yes, in others no.  More to the point, who
cares?  That's not what it's about anyway.

> In real life could I even REMEMBER which identifiers were identified
> when?  Or is this something that a computer can only remember
> perfectly?

Obviously if you trip, it's the job of the compiler to tell you.

> In real life, while I'm programming, why am I supposed to have to
> remember which things are "before" and "after", in some silly
> conflation of location in a text document with 'time'?  Assuming I
> don't have a single source file, is this at all justifiable?

Well, this is (as I'm sure you realize) a strawman.  I mean you don't
have to remember anything as the compiler will tell you if you got it
wrong.  Is this "justifiable"?  Well, it is one way to resolve
elaboration problems.  If you think that's rubbish, well, then I guess
you don't think it's justifiable.  Shrug.

/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: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EG2CEx.6uq@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> So you think there exists a reason to impose dependency-related
> ordering?

There's a reason - consistent elaboration.  Whether people think
that's a good enough reason is a different kettle of fish.


> >These two bits end up making you look completely clueless...
> 
> Boy, Jon, we really could have done without this wisecrack.

I suppose, but we could do even better without (mis|dis)information
being broadcast all over the place.

/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: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <5ursej$dhp@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

> jsa@alexandria.organon.com (Jon S Anthony) writes:
> 
> >Come on Don - if you use something as primitive as vi, well whatever.
> >However, any remotely reasonable IDE will give you "jump to this
> >functions impl".
> 
> Hey, vi can do that.  The command to jump to the definition of `this_func'
> is
> 
> 	:!make tags
> 	:tag this_func
> 
> or just control-], if the tags file is already up-to-date and
> then cursor is on an occurrence of `this_func'.

Criminey, forgot about the good ol' tags file.  Wow.  I guess that
means I should have said something like "as primitive as a keypunch"
Or is there a neat trick with punched cards too?

/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: Interface/Implementation (was Re: Design by Contract)

[Joachim Durchholz]

W. Wesley Groleau x4923 wrote:
> If you are looking for a particular operation, why are you scrolling
> through?

Well, personally I don't scroll through too often, but this is often
useful to get a first impression on what a class does. A good ordering
can be valuable.

> If you are trying to understand an operation's
> implementation, you look at it, and if it calls another, you may
> choose to find that.

Finding the implementation interrupts the reading process. These
interruptions are barely tolerable if just clicking the identifier in
question brings me to its definition (or implementation), but explicitly
calling up a Find dialog breaks my concentration.

> There is a difference between the usefulness of the "spec" (which
> I've been led to believe in Eiffel _includes_ certain essential
> comments),

There might be a misunderstanding at work here. Wether these comments
are essential or not depends on your point of view.
At the language level, these comments have the usual comment semantics,
i.e. removing them doesn't change anything.
However, they are useful because they go into the text extracted by the
short and short-flat tools; because of this you can have all sort of
documentation here. This includes:
- Assertions that the language cannot express because they are informal,
e.g. "Result is a nicely formatted report template".
- Assertions that we don't want the run-time system to check even if
assertion checking is on, because they are too time-consuming to check,
e.g. "Result is acyclic" where Result may be a graph with several
million edges.
- Comments on assertions, e.g. "This precondition should go away in
future versions".

> Put another way,
> is a short (or short flat) adequate for me to code a client if
> the coder did not put his comments in the right place or format?

It's just the right place (no formatting conventions *inside* Eiffel
comments). And it is very difficult to get the place wrong.

A typical Eiffel routine looks as follows:

  feature
    <routine name> (<parameter list>) is
    require
      <put your preconditions here>
    ensure
      <put your postconditions here>
    do
      <routine body>
    end


-- 
Please don't send unsolicited ads.

Re: Interface/Implementation (was Re: Design by Contract)

[Joachim Durchholz]

Joerg Rodemann wrote:
> With Ada, to start working I 'just' need a compiler/linker
> combination.
> But from then on I AM able to work. Perhaps not with all the worlds
> luxuries
> and little add-ons and features, but it is possible. However, if I
> need
> a fully blown-up intelligent IDE, then I am lost.

You can use at least some Eiffel compilers without an IDE. And you can
edit the class texts with any editor, so you're free to use vi, emacs,
or whatever you like.
I guess this is even the way people worked with Eiffel initially. I
guess short (to extract the interfaces) and flat (which merges the text
of a class with its ancestors to yield a single text that shows what the
class really does) were indispensable at that time (and they're still
indispensable if one wishes to produce printed paper).

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Interface/Implementation (was Re: Design by Contract)

[Joachim Durchholz]

Matthew Heaney wrote:
> 
> >IMO, there's no excuse for imposing dependency-related ordering
> >in an age of multi-pass compilation.
> 
> Note that many computer scientists, among them Tony Hoare, believe
> that a
> measurement of goodness of a language is its ability to be compiled
> using a
> single pass.

Well, dropping names doesn't help me understanding your point.
Can you give some arguments why a one-pass-compilation language is
superior?

> That there is a dependency-related ordering in Ada (both 83 and 95) is
> by design; that was the precise intent of Ada's designers.

I can see that.

> This should
> be regarded as a Good Thing, because it makes it easier for the human
> reader to apprehend program text.

This is a valid point.
However, not all definitions are cycle-free in practice. Notable
examples are pointers and recursive routines.
These are dependencies that originate in run-time usage. In an OO
language, inheritance adds a strictly compile-time dependency. (E.g. a
class C may contain references to objects of class D where D is some
remote descendant of C.)
It is impossible to remove all circularities, so the language must not
prohibit them (though it is a Good Thing to arrange a program so that
most dependencies are one direction).

> The same philosophy applies to exits from inside a loop
> 
> loop
>    <text>
>    exit when <predicate>
>    <more text>
> end loop;
> 
> Many programmers think that it's better to use a while loop, ie
> 
> while not Done loop
>    <text>
>    Done := True;
>    if not Done then
>       <more text>
>    end if;
> end loop;

Unfortunately I cannot totally agree with you here.
A while loop has a tremendous advantage: it makes the termination
condition stand out clearly.
After reading

  while <termination condition> loop
    <loop body>
  end loop

can be sure that <termination condition> does not hold after "end loop".
This may be enough that I can read on without further looking at the
loop body (at least if I'm only interested in some properties of the
code, e.g. the control flow under some specific circumstances).

Of course if the termination condition is just "Done" this doesn't help
me when reading the code, but such flags aren't too frequent (at least
if you tend to avoid them, it's a matter of personal style to some
degree).

It may be more straightforward to symbolically execute an "exit
when"-style loop. But for gathering properties of a piece of code a
while loop is often better.

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]



In article <EG2Dv5.74D@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:


>>With the exit approach, comprehension only depends on what has come before.
>
>Yes, there seems to be an analogy here, but I think it's superficial.
>Certainly the statement "comprehension dependy only on what has come
>before" applies in both cases, but let's consider whether this is
>really important.

I'm merely stating what was told to me privately by Ada's original designer
(Jean Ichbiah) and what is documented publicly in the Ada 83 Rationale. 
There definately _is_ an analogy, because the designer decided
intentionally that there would be.  This analogy isn't superficial at all -
it pervades the whole of the design of the language.

To get random signatures put text files into a folder called �Random
Signatures� into your Preferences folder.

Re: Interface/Implementation (was Re: Design by Contract)

[Ell]

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

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <34103462.1D86@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>
>Patrick Doyle wrote:
>> 
>>   Being the one who seems to be pursuing this quest, I'll explain
>> myself.
>
>Well, your rationale for the question is valid.  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.

My argument is that Eiffel already has a facility to freeze an
interface.  In other words, Ada's extra interface file can be
simulated in Eiffel with *no extra effort* than is required
in Ada.

(BTW, I'm starting to be convinced that the extra interface
file is a Good Thing, but I'm not fully decided just yet... :-)

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

  Or (4) "Here's a simple elegant way to get all the benefits if MI
using existing Ada techniques".

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

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

Note that (2) is what the Ada Rationale says, in detail.  I agree, we
should be careful to emulate it.

Sam Mize

-- 
Samuel Mize -- smize@imagin.net -- Team Ada
(personal net account)

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EG1Iz4.5po@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

>   My point is that deferred classes *are* interfaces, so if you
> want to freeze an interface, freeze a deferred class.

And?  I'm not sure what you are fishing for - an Ada spec. is simply a
different kind of thing.  It _provides_ a "bundled" (aka packaged)
interface or several interfaces depending on what is packaged up in
it.


>   See--it has little to do with Ada.  I'm simply referring to Ada
> because it has a built-in facility for creating interfaces for
> every class, and so the Ada people have a great deal of experience
> with this methodology; so I was asking them about using deferred
> classes because presumably they'd be the best ones to find the
> flaws in the deferred class methodology.

Maybe that's the problem.  Why should there be a "flaw"?  It's just a
different thing.  Package specs provide encapsulated interfaces.  The
package specs. themselves can't be derived and can't be inherited.
They have nothing corresponding to them at runtime (whereas a deferred
or abstract class should have a jump table.  Well, probably...)

/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: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5478 bytes --]


In article <mheaney-ya023680000609971901030001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>
>In order to understand something, you have to know a few other things. 
>Because humans are complexity challanged (sp?; man, I've got to install my
>spell-checker...) , we want to limit the amount of information the human
>reader of the code has process in order to understand it.
>
>If he has to scan past a point in the text in order to figure something
>out, then there's a lot of stuff after that point, but prior to the point
>containing the next useful piece of information.  

Ok so far...

>But the reader doesn't
>know what's useful and what's not, in order to understand this particular
>problem, so he has to digest it all, and then prune away all the
>unnecessary stuff after he's figured out his problem.  

This isn't true.  If there's a reference to a class, for example,
he just has to scan the headers of class declarations, of which
there is only on per class.  Not really that much stuff to plough
through.

By contrast, in the loop situation, in general, the entire ramining
part of the loop must be understood to see that it does what's
expected.

Also, remember that on average, saving the programmer from scanning
below saves only 1/2 the work.  Not an order of magnitude, by any
means.  Perhaps you'll argue that 1/2 is important enough?  Well,
then I suggest you get a decent editor and save yourself *far*
more than 1/2 the work by having it look up the definitions for
you. 

>It seems that it
>would be simpler for that reader, if in order to understand something, he
>knows up front that all he needs to care about has already appeared.

Remember, to say it has "already" appeared is implying that there is
a time component to this, which in turn implies that the file is
read in a linear fashion.  

>That's why exit conditions from the middle of a loop make a lot of sense. 
>As soon as the exit condition appears, then the reader can turn his brain
>off, and scan past all the text prior to the end of the loop.  The precise
>intention of the language designers is that this would limit the amount of
>information the reader has to process in order to understand what he's
>reading.

I agree in this case, because in general then entire remaining portion
of the loop would have to be understood to ensure that it does what
is expected.  On the other hand, with forward references, I can't think
of any situation where all the code would matter.  You're just scanning
for the right declaration.

>Incidently, the article Cognitive Strategies and Looping Constructs
>(Soloway et al, CACM, Vol 26, No. 11, Nov 83, p. 853 - 860) described a
>study demonstrating that exits from the middle a loop were easier for
>programmers to understand and get right; they showed empirically that those
>constructs had fewer errors.   Exit-from-the-middle loops better fit the
>cognitive strategy used by real programmers: "When writing a simple looping
>program, those using the loop .. leave .. again construct were more often
>correct than were those using the standard Pascal loop constructs."

No argument here.

>I wish everyone would read this paper, so we could end this perennial
>debate.  "Programming is a human activity.  Forget that, and all is lost." 
>(paraphrased from Stroustrup)  

I didn't think that's what the debate was.

>>Consider this: the reason for this abstraction is that the human
>>reader need not be bothered with unnecessary details.  If these
>>details are unnecessary, who cares where they go?  And if they
>>*are* necessary, then a human reader searching a single text file
>>with any reasonable editor should have no trouble finding it.
>
>But the reader of a piece of code doesn't know what's necessary and what's
>unnecessary when trying to figure something out.  By enforcing dependency
>order, you know up front that what comes before is necessary, and you only
>need to keep reading until you figure your problem out; everything after
>that point is unnecessary.

Yes he does know what's necessary.  Remember, he's the guy trying to
understand something.  If he looks at something and understands it
because good abstraction was used, then he doesn't need the definition.
If he doesn't understand it, he needs to look it up.  If he thinks
he understands it and he's wrong, then the code is misleading,
and badly written code will always present problems.

But also remember this: just because a language doesn't enforce
dependency ordering doesn't mean you can't use it.  So if you have
a thing used in a way that might be misleading, you can put its
definition above its usage and get all the benefits you describe.

The advantage to not enforcing dependency ordering is that it
allows the programmer to choose a meaningful ordering, and also
that the compiler doesn't choke on technicalities when you have
forward references.

>The Eiffel camp seems to think that dependency order is a limitation, but
>it was a deliberate decision by Ada's designers.   As an Ada programmer, I
>haven't found it to be a limitation at all; in fact, I find it quite
>helpful, exactly as the designers imagined it would be.

Perhaps it is helpful, but it is also a limitation.  Perhaps a
helpful limitation, but a limitation nonetheless.  

>To get random signatures put text files into a folder called �Random
>Signatures� into your Preferences folder.

What's this all about?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don says

<<IMHO, this is how it should be. One of the annoying things I find with the
ability to order operations differently in Ada spec and body is that you
see them in a certain order in the spec and may have trouble finding them
in the body because they've been re-ordered, often due to compilation
dependencies. IMO, there's no excuse for imposing dependency-related ordering
in an age of multi-pass compilation.

Does the Ada95 standard impose dependency-related ordering?>>

No, and neither does the Ada 83 standard in this context, so your comment
about finding this annoying is simply confused.

We are talking about the order in the body of entities declared in the spec.
Clearly these have all been previously declared, so the order of subprogram
bodies in the body of the package is completely free, I have no idea what
you are talking about.

If you see a different ordering in the spec than in the body, it is not
because of "compilation dependencies", it is because the programmer thinks
this is a good idea. Yes, I know, language designers are partially in the
business of telling the programmer that they know better than the programmer
does and imposing restrictions, but this one seems inappropriate.

What I often find quite appropriate in Ada is to group the specs in a logical
order in the package spec, since this is often browsed to get an idea of the
facilities offered by a package by humans, and an appropriate logical order
can help this browsing.

On the other hand, you never need to browse the body as a client of the 
package, so the logical ordering requirement for such browsing does not
apply. The two files are viewed VERY differently in an Ada environment,
not only will different people touch them, but different people will look
at them, and the client of a package should almost never be looking inside
the body -- if they need to, it shows something is wrong with the spec.

Incidentally the separate files aid this goal. An Ada programmer expects
to find everything they need in one file, and is definitely annoyed, and
knows that there is a bug, if they have to go and look at the body. If you
put things in one file, even a single file with different views, it is far
too easy for programmers to get in the habit of looking at this file without
going though the restricted interface view, and thus not to be sensitive
enough to enforcing the separation. Yes, tools could make this harder, but
in practice, not everyone is using such tools, and it is all too easy for
a client to easily browse the implementation.

Going back to the ordering issue, in the body, I usually prefer to arrange
the subprograms in alphabetical order, because this is easier for reference
purposes for the implementor who needs to go to a particular body to debug
or otherwise fiddle around.

That's the *crucial* difference between the spec and the body, the spec gets
browsed as a whole, the body never does. I quite see how Eiffel programmes,
or other programmers not used to this strong separation would not see the
benefit of being able to organize the two objects differently, you do not
miss what you do not have.

One of the most widespread weaknesses, even among experienced professional
programmers, is the inability to comprehend the importance of separating
specification from implementation. Note tha the entire "comments are useless,
my code is self documenting" view is fundamentally at odds with this basic
requirement of separation.

Yes, you can separate effectively in any language if you work hard enough
(the equivalent of a separate spec can be created entirely by commenting
even in a language like COBOL or BASIC with absoslutely NO avbstraction
capability of this sort), but in practice, a language like Ada where this
separation is very strong will encourage more programmers to understand
the importance of the separation. In the Ada world, absolutely everyone
understands that you should be able to use a package only looking at its
spec and not its body, and the fact that the spec can be handled separatly
as a coherent compilable entity is one of the most important aspects of
Ada, since it leads even inexperienced not very competent programmers
to fully grasp the importance of the separation of spec and body.

<<dependencies. IMO, there's no excuse for imposing dependency-related ordering
in an age of multi-pass compilation.>>

Though this technical point is completely irrelevant to the main thread
of discussoin here, if you are saying that you should be able to use entities
before they are declared. I strongly disagree. Sure my compiler can make
multiple passes through a source document, but as a human reading the
document, I prefer not to. There is a reason why we arrange text books,
and other materials not to have forward references (such as mentioning
a character in a novel before introducing them). Programs benefit in the
same way from a basically linear approach, in which overall understanding
can be obtaineed in a single linear pass.

But as I noted, this point is totally irrelevant to the discussion, since
of course the spec appears "before" the body, so there are no ordering
relationships imposed on the entities in the body that correspond to those
in the spec in any case.

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]


In article <EG4KGI.ILG@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:


>>The Eiffel camp seems to think that dependency order is a limitation, but
>>it was a deliberate decision by Ada's designers.   As an Ada programmer, I
>>haven't found it to be a limitation at all; in fact, I find it quite
>>helpful, exactly as the designers imagined it would be.
>
>Perhaps it is helpful, but it is also a limitation.  Perhaps a
>helpful limitation, but a limitation nonetheless.  

This is not unlike saying that "strong typing"  is a helpful limitation,
but a limitation nonetheless.  Forward declarations just confuse me, but
your mileage may vary.

>>To get random signatures put text files into a folder called �Random
>>Signatures� into your Preferences folder.

Oops!  I recently installed Navigator 4.03, and it installed some extra
stuff (grrrrr...) that overrode the behavior of what was already working. 
I guess they call that a "feature," eh?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

<<Therefore I also prefer the spec to be completely seperated which
doesn't exclude some good (CASE) tools auto-generating a code framework.
Also I got the feeling people here mix up 'spec', 'description of
interfaces as derived out of the requirements specification', 'detailed
description of implementation interfaces' (which would more be a part of
the design IMO). Maybe even I am the one who doesn't get the meaning
right. :-)
And finally, in my specific environment, I would be happy to have a
early, stable spec and a good design documentation at all. :-(>>

This is confusing things. The specification of an interface at a suitably
abstract level is quite a different thing from the package declaration in
an Ada program. Have you written in Ada? I would guess not, or you would
have a better feel of what is being talked about here. Give it a try, even
a little experience here will be very helpful.

P.S. no one yet answered by question about people having actually interfaced
Eiffel to Continuus or Clearcase to show how the CM problems are overcome.
I am beginning to assume that no one has done it (not surprising, because
the point of my question was that it does not look easily doable, and people
tend simply not to do what is not easy to do!)

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

<<:The spec may be ordered to make things easy for the client to read.
:The body may be ordered to make the implementation easy to understand.

With Eiffel, you have both and ordering is preserved.>>

That's rather confused, in Eiffel you have to use the same ordering 
effectively for the spec and the body. The whole point of the above is
that may have different ordering requirements. Eiffel does not accomodate
this, and the best defence is that people don't think they need it -- fine,
most C programmers don't think they need strong typing -- you seldom 
find that you absolutely need something you can't get!

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don says

<<Okay, if your tools are sophisticated enough to find the operation for you
then that would help. It's true that in that case, the ordering in the package
body shouldn't matter. However, your comment about making an implementation
easy to understand implies that ordering *is* signigicant. Are you referring
there to more primitive tools such as text editors?

Text editors are what I'm talking about. In particular, I'm referring to
the situation of scrolling through a package body and expecting to find
operations in the same order as the spec and finding they're not, and then
having to search for them.>>


No, there are no ordering rules that are significant at the implementatoin
level -- look Ada rules are well known, you can just look them up, they are
not the subject of speculation!!!!

There is no reason to have an expectation that the routines in the body
be in the same order as those in the spec, and as I have pointed out
before, we always order the subprograms in the body alphabetically, which
turns out to be much more convenient for reference purposes, particularly
if you print out the code -- yes, some of us still prefer nice paper
output to the low resolution screen output available to day. When they
make a screen with 1200 DPI resolution, let me know (I find 300DPI paper
quite unpleasant to read at this stage).

Re: Interface/Implementation (was Re: Design by Contract)

[John G. Volan]

Matthew Heaney wrote:
> 
> In article <EFyrH2.7z2@syd.csa.com.au>, nospam@thanks.com.au wrote:
> 
> >IMO, there's no excuse for imposing dependency-related ordering
> >in an age of multi-pass compilation.
> 
> Note that many computer scientists, among them Tony Hoare, believe that a
> measurement of goodness of a language is its ability to be compiled using a
> single pass.  In that tradition, Ada was design so that it could be
> compiled in a single pass.

There is a whole other dimension to the ordering of source code in Ada
which has not been mentioned: elaboration order.  

For those of you on this thread not familiar with Ada's elaboration
model, here's the gist:  Every declaration in an Ada program gets
"elaborated" at a specific point in time during execution. "Elaboration"
is the process whereby a given declaration "takes effect" at run time. 
What this means depends on what kind of declaration we're talking
about.  For instance, if it's an object declaration, then "taking
effect" means that the object is allocated memory (on the heap or on the
stack or in a register as the case may be) and any implicit or explicit
initialization of its contents occurs.

Elaboration is linear: Declarations are elaborated in the order in which
they appear in the source text. So the order in which you declare things
can potentially have an effect during execution.

Since Ada verifies at compilation time that you haven't referred to
anything before it's been declared, this also guarantees (more or less)
that the thing will have been elaborated and actually exist at run time,
before you can execute any statements that reference it.  This can be a
very useful property.

For instance, consider the problem of classwide global data ("static
members", in C++ parlance).  When do these beasts get initialized?  In
Ada, you'd just have some "global" variables/constants declared in the
body of a package, but outside of any procedure or type declaration in
that package.  The variables/constants would get elaborated (in the
order they appear) at the time that their enclosing package gets
elaborated.  When is that? Well, according to the rules, a package gets
elaborated (more or less) sometime before any of its clients (any units
that "with" the package).  So you're guaranteed (more or less) that
those globals are initialized before any client can call any of the
subprograms from that package.

(I said "more or less" in the paragraphs above because there are some
subtleties to Ada's elaboration model, but we don't really need to go
into them right now.)

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?  If so, it seems to me that
Ada's idiom for this is more straighforward than Eiffel's.  (I'm not
saying it's better, just more straightforward for this particular
application.)

-- 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <dewar.873630067@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>Though this technical point is completely irrelevant to the main thread
>of discussoin here, if you are saying that you should be able to use entities
>before they are declared. I strongly disagree. Sure my compiler can make
>multiple passes through a source document, but as a human reading the
>document, I prefer not to. There is a reason why we arrange text books,
>and other materials not to have forward references (such as mentioning
>a character in a novel before introducing them). Programs benefit in the
>same way from a basically linear approach, in which overall understanding
>can be obtaineed in a single linear pass.

Novels and program code are read in fundamentally different ways.  Program
code is a reference text, more like a dictionary than a novel.  If you
look up a word in a dictionary and it uses another word you don't know,
do you care whether this new word is before the first word?  Of course
not.

IMO, the idea that code is read linearly is a misconception.  Perhaps
the spec might be read linearly if a programmer is new to that package
and wants to immerse himself in it and learn it all at once.  This
usage is analogous to the usage of a text book, and perhaps dependency
ordering provides some nominal assistance here.  Other
than this particular usage, it's my experience that code is not read
linearly, so dependency ordering is addressing a non-issue, especially
in the package body.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <34103462.1D86@pseserv3.fw.hac.com>, wwgrol@pseserv3.fw.hac.com 
says...
> 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."

The Language Rationale does (2).  I just wish I understood the examples.

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: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Wes says

<<Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
he/she could actually use Ada?  (And vice versa, lest anyone think
I'm making another language-bigot comment...)>>


Very often in such discussions, you see claims that

"feature x in language y can easily be simulated in language w using approach z"

The trouble with such statements is that they are almost always true, and
there almost always exists w,z for all x,y, but the observation is 
meaningless.

For instance, a C programmer by very restricted, very stylized use of
headers, together with amazing tools that enforce and monitor these
restrictions, essentially complete duplicate the effect of the separation
of Ada specs and bodies.

But the issue is not whether C programmers *could* do this, but whether
they *do* do this in practice? And certainly for that example, the answer
is (rather universally) no.

SO the issue with Eiffel is not whether you *could* get the effects, e.g.
ease of ability to separate spec and body in a CM environment, but whether
people *in practice* work this way.

Note how significant it is that I make a simple request for anyone to 
report in on how Eiffel would work together with a typical CM tool
like Continuus or Clearcase to achieve this kind of separation.

The only responses have been theoretical, pointing out that in very general
terms, with some unspecified additional tools, it could be achieved. But
even these theoretical reponses have not shown any awareness of these
CM tools -- one would almost begin to get the feeling that typical Eiffel
projects are not using CM tools at all, though that cannot be right (probably,
as is the case for Ada, most of the people working on real live projects
have better things to do with their time than read, let alone contribute to,
this rather wandering thread.

Still it would be nice to have at least ONE concrete experience report
that shows that the engineering details of this approach are practical.

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> With the exception perhaps of the ordering argument (which itself is not very
> strong, IMO), all of the arguments I've seen advanced in favour of separate
> interfaces 

Excuse me?  Wasn't it you who brought up the "possibility" of 
changing the order as an argument _against_ separation?

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

In article <dewar.873826570@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

><<Note that many computer scientists, among them Tony Hoare, believe that a
>measurement of goodness of a language is its ability to be compiled using a
>single pass.  In that tradition, Ada was design so that it could be
>compiled in a single pass.>>
>
>I never heard Tony say any such thing, and certainly everyone knows that
>high quality compilers these days require multiple passes, for code 
>generation if nothing else.

Then you weren't at Tony's Turing Award lecture:

"...I adopted certain basic principles [of language design] which I believe
to be as valid today as they were then...(4) The forth principle was that
the compiler should use only a single pass....I can still recommend
single-pass top-down recursive descent both as an implementation method and
as a design principle for a programming language.  [Note carefully the next
sentance.] First, we certainly want programs to be read by _people_ and
people prefer to read things once in a single pass."

That last line is exactly what Robert was refering to: design the language
so that it can be read by _humans_ in a single pass (even if it isn't
compiled that way), because that's what humans prefer to do.

If only the rest of Tony's lecture were that favorable toward Ada...

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert Dewar wrote:

:Don says
:
:<<IMHO, this is how it should be. One of the annoying things I find with the
:ability to order operations differently in Ada spec and body is that you
:see them in a certain order in the spec and may have trouble finding them
:in the body because they've been re-ordered, often due to compilation
:dependencies. IMO, there's no excuse for imposing dependency-related ordering
:in an age of multi-pass compilation.
:
:Does the Ada95 standard impose dependency-related ordering?>>
:
:No, and neither does the Ada 83 standard in this context, so your comment
:about finding this annoying is simply confused.

Yes, as you say, operations etc. declared in the spec can be freely ordered 
in the body. My mistake.

What I'm referring to, is the fact that depedendency-related ordering is 
imposed for elements (operations/types etc.) declared and used in the *same*
spec or the *same* body - a different issue, as you say below. (More on 
this at the end).

:We are talking about the order in the body of entities declared in the spec.
:Clearly these have all been previously declared, so the order of subprogram
:bodies in the body of the package is completely free, I have no idea what
:you are talking about.

While the order of elements previously declared in the spec is free, the 
order of elements declared in the body is not, which, though explicable, is 
inconsistent.

:If you see a different ordering in the spec than in the body, it is not
:because of "compilation dependencies", it is because the programmer thinks
:this is a good idea..

[..]

:On the other hand, you never need to browse the body as a client of the 
:package, so the logical ordering requirement for such browsing does not
:apply. The two files are viewed VERY differently in an Ada environment,
:not only will different people touch them, but different people will look
:at them, and the client of a package should almost never be looking inside
:the body -- if they need to, it shows something is wrong with the spec.

The client and the implementer are not necessarily different parties. For 
example, for a maintainer of a package whose spec and body were written by 
different people, it can be annoying to find them ordered differently.
At least, that is my experience.

:Incidentally the separate files aid this goal. An Ada programmer expects
:to find everything they need in one file, and is definitely annoyed, and
:knows that there is a bug, if they have to go and look at the body. If you
:put things in one file, even a single file with different views, it is far
:too easy for programmers to get in the habit of looking at this file without
:going though the restricted interface view, and thus not to be sensitive
:enough to enforcing the separation. Yes, tools could make this harder, but
:in practice, not everyone is using such tools, and it is all too easy for
:a client to easily browse the implementation.

In the case of Eiffel, commercial implementations *do* provide a short
form tool, so storing interface and implementation in separate files isn't 
necessary.

:Going back to the ordering issue, in the body, I usually prefer to arrange
:the subprograms in alphabetical order, because this is easier for reference
:purposes for the implementor who needs to go to a particular body to debug
:or otherwise fiddle around.

My own preference is to organise along functional lines in both spec and body.
That way, related operations get grouped together and you can often just scroll 
up or down to look at what you're interested in.

That's why I have no problem with consistent ordering being enforced.

However, forcing consistent ordering doesn't necessarily mean that you 
can't *access* in some other order. An Eiffel implementation could provide, 
for example, a "very short form" consisting of just feature names. Feature
ordering in the window could be changed in just the same way as you can select
different directory views in a file manager. Possible feature views might be:

  a) Same as short form (the default)
  b) Alpabetical
  c) Most recently updated
  d) etc.

With such a capability, forced consistent ordering would not be the end of 
the world if you prefer some other view. 

:That's the *crucial* difference between the spec and the body, the spec gets
:browsed as a whole, the body never does. 

Not if you order on functional lines, in which case, *sections* may be browsed 
as a whole. BTW, wouldn't it be hard to maintain alphabetical ordering when you 
add operations specific to the body? - you would lose your ordering due to 
dependencies.

:I quite see how Eiffel programmers,
:or other programmers not used to this strong separation would not see the
:benefit of being able to organize the two objects differently, you do not
:miss what you do not have.

OTOH, I can see why Ada programmers might consider this more of an issue 
because they are dealing with modules of typically coarser granularity 
than Eiffel programmers. In the case of co-encapsulation, Ada modules map 
one-to-many to abstractions, potentially giving rise to many features. 
It's less of an issue in Eiffel because modules correspond one-to-one to 
abstractions.

:One of the most widespread weaknesses, even among experienced professional
:programmers, is the inability to comprehend the importance of separating
:specification from implementation. Note tha the entire "comments are useless,
:my code is self documenting" view is fundamentally at odds with this basic
:requirement of separation.

Sorry, don't see the connection. Can you explain?

:Yes, you can separate effectively in any language if you work hard enough
:(the equivalent of a separate spec can be created entirely by commenting
:even in a language like COBOL or BASIC with absoslutely NO avbstraction
:capability of this sort), but in practice, a language like Ada where this
:separation is very strong will encourage more programmers to understand
:the importance of the separation. In the Ada world, absolutely everyone
:understands that you should be able to use a package only looking at its
:spec and not its body, and the fact that the spec can be handled separatly
:as a coherent compilable entity is one of the most important aspects of
:Ada, since it leads even inexperienced not very competent programmers
:to fully grasp the importance of the separation of spec and body.

I can assure you Eiffel developers place just as much importance on the 
interface as Ada programmers. 

With the exception perhaps of the ordering argument (which itself is not very
strong, IMO), all of the arguments I've seen advanced in favour of separate 
interfaces are not intrinsically that at all. They are arguments in favour 
of being able to *distinguish* between interface and implementation. While 
these arguments are perfectly valid, they're incorrectly passed off as 
supporting separate interfaces. They're not.

For the purpose of those arguments, how the interface came about is immaterial. 
It doesn't matter whether it was written first or generated from the 
implementation. The claim that you need separate interfaces to realise the 
benefits of distinguishing between them is bogus.

:<<dependencies. IMO, there's no excuse for imposing dependency-related ordering
:in an age of multi-pass compilation.>>
:
:Though this technical point is completely irrelevant to the main thread
:of discussoin here, if you are saying that you should be able to use entities
:before they are declared. I strongly disagree. Sure my compiler can make
:multiple passes through a source document, but as a human reading the
:document, I prefer not to. There is a reason why we arrange text books,
:and other materials not to have forward references (such as mentioning
:a character in a novel before introducing them). Programs benefit in the
:same way from a basically linear approach, in which overall understanding
:can be obtaineed in a single linear pass.

I agree to the extent that I think a linear pass is useful for gaining an
overall impression of what a program does. Consequently, I agree with the 
recommended Eiffel style of identifying broad categories of functionality 
which are consistently applied and ordered in all classes. It's then easy 
to gain a broad-brush view of a class by scanning it linearly.

However, once a reader has gained such an impression, they typically want 
to move from sequential to direct access, more like consulting an encyclopaedia
than reading a novel. (I think someone has already mentioned this). In that
case, what they want to do is to jump around within the text with the aid 
of the string search facility of the underlying editor. They get a bonus 
if the implementation is ordered along functional lines because they can 
scroll as well.

Incidentally, well-written technical books may be read this way as well.

Eliminating dependency-related ordering has another advantage: removing the need
for redundant pre-declarations (for me, another of Ada's little annoyances). 
In the absence of this constraint, the redundant lines marked "no longer needed" 
could be removed from the following declarations in a body:

  type a_rec;                       -- no longer needed
  type a_rec_ptr is access a_rec;
  type a_rec is record
    next: a_rec_ptr;
  end record;

  procedure do_d;                   -- no longer needed
  procedure do_c is
  begin
    do_d;
  end;

  procedure do_d is
  begin
    do_c;
  end;

:But as I noted, this point is totally irrelevant to the discussion, since
:of course the spec appears "before" the body, so there are no ordering
:relationships imposed on the entities in the body that correspond to those
:in the spec in any case.

True.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <3414BF1E.2E7C@ac3i.dseg.ti.com>, johnv@ac3i.dseg.ti.com says...

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

Yes.  For example, in a discrete event simulation system I would want
to have a global event queue.  The class holding it would look
something like this:


   class THE_QUEUE

      feature

         the_queue: PRIORITY_QUEUE [EVENT] is
               -- The global event queue.
            once
               !!Result; -- Create the result of this function
            end;

   end;

This class can then be inherited by any other class which needs to access
the event queue.  Within such a class I can use code such as

   the_queue.item.trigger;
   the_queue.remove;
   the_queue.put (new_event);

Every descendant of THE_QUEUE gets the same global queue object.

>If so, it seems to me that
>Ada's idiom for this is more straighforward than Eiffel's.  (I'm not
>saying it's better, just more straightforward for this particular
>application.)

In Ada you have to worry about the order of initialisation to accomodate
any dependencies.  In Eiffel you just use the once routines.  Any
interdependencies between once functions will be reflected in their
own call graphs, and get taken care of automatically.

The Eiffel mechanism can even take care of circular dependencies, although
it does need a little care.  Suppose that after creating the result object,
"the_queue" called some other function (maybe a "once" function) which
referred to "the_queue".  At this time "the_queue" will return its current
value of "Result" without executing again.  You can't execute a "once"
function twice, even by recursion.

In Ada, as I understand things, you would have to split the various bits
of initalisation into non-recursive bits, and hence make the process visible
at a higher level than would otherwise be necessary.

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: Interface/Implementation (was Re: Design by Contract)

[Nick Leaton]

John G. Volan 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?  If so, it seems to me that
> Ada's idiom for this is more straighforward than Eiffel's.  (I'm not
> saying it's better, just more straightforward for this particular
> application.)

One quick explaination first.

	x: MY_CLASS

This does no allocation

	!!x

or	!OTHER_CLASS!x

or	!!x.make -- or some other feature declared as a creation feature

The !! creates a object and allocates the memory. Prior to this, x is
Void.
The second case is interesting, OTHER_CLASS must conform to MY_CLASS.

OK, back to global objects.

	x: MY_CLASS is
	   once
	      !!Result
	   end

The first time I use x, Result will be made. The second time I use x,
the Result from the previous use will be returned. Think of it as a just
in time singleton.

So the order of creation is the order of use.

Is this a problem where you want some objects initialised first?

No, because you will want the objects initialised first in order to use
them, but the use will create them. ie a DATABASE object. You can use
this if it is a once feature anywhere, first use will create so you know
it is created. If it needs something else to be create first, the client
of DATABASE shouldn't be worried, DATABASE itself should create the
appropiate objects, probably using a once feature.

Are there any issues with once features?

Yes, they never get 'deleted', once created they exist for the lifetime
of the program. They could be large structures only used during the
initialisation of the program, and therefore with never be garbage
collected. However with a generational garbage collector, they will be
compacted. (Once features a roots as far as GC is concerned)

There is a solution to this problem if needed, just add a layer of
indirection.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Wes said

<<No. I mean both.  Untrue because IF the order in the body is
  changed, it is NOT due to compilation dependencies, AND "in an
  age of" modern tools (such as 'grep') there no reason for the
  order to make things hard to find.  Unpalatable, because one
  of Ada's lower priority goals was to make a one-pass compiler
  possible though not mandatory.>>

That's a bit misleading. It is in fact NOT possible in any reasonable
way to create a one-pass compiler for Ada 95, and certainly no one has
done so. The design goal is a rather different one, it is to enable a
basically one pass scan for human comprehension purposes. If you stick
to a basically linear elaboration model, you make it easier for the
reader.

    >   "Does the Ada95 standard impose dependency-related ordering?"

<<To some extent, as stated above.  But things declared in a legal
  order in the spec do not have to have their repetitions in the
  same order in the body.  (And let's not start about repetitions
  again.  We've already established either that this kind of
  repetition is not a problem, or that arguing about it will
  accomplish NOTHING.)>>


To clarify, in general there is no restriction on the order in which
subprograms occur. However, Ada follows the C and Pascal style of
basically forbidding forward references, rather than the Algol-68
style which allows forward references.

This is a very deliberate choice, and one I strongly support. Following
the Algol-60/68 choice here is a serious wrong step in my view (and
certainly mainstream language design agrees with this viewpoint).

Re: Interface/Implementation (was Re: Design by Contract)

[Richard Kenner]

In article <dewar.873780309@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>That's a bit misleading. It is in fact NOT possible in any reasonable
>way to create a one-pass compiler for Ada 95, and certainly no one has
>done so. The design goal is a rather different one, it is to enable a
>basically one pass scan for human comprehension purposes. If you stick
>to a basically linear elaboration model, you make it easier for the
>reader.

There are indeed some "one pass" issues in the design of Ada 95.  For
example, as you've pointed out a number of times, the best intuitive
way to view the freezing rules are to think of what would be needed to
allow one-pass compilation.

Re: Interface/Implementation (was Re: Design by Contract)

[John G. Volan]

Nick Leaton wrote:
> 
>         x: MY_CLASS is
>            once
>               !!Result
>            end
> 
> The first time I use x, Result will be made. The second time I use x,
> the Result from the previous use will be returned. Think of it as a just
> in time singleton.

Suppose such a "once" function is referenced at several different points
in a program. If the compiler were able to predict which of these
references would be the first to occur at runtime, then perhaps it would
be able to perform some optimizations: It could inline the
object-creation code right at the first call, and then turn all the
subsequent calls into direct object references.  

But I don't think it's possible, in principle, for a compiler to make
such a prediction. (My guess is that it's equivalent to the halting
problem.)  So it seems to me that every reference to a "once" function
would have to incur the overhead of a functional call, plus a
conditional test to determine whether the object has already been
created "once" before.  Sounds like a pretty heavy-weight way to
implement global objects.

Contrast this with Ada's scheme: The compiler treats a reference to a
global object the same way it treats any other kind of object reference,
with no extra overhead inserted into the generated code.  But because of
Ada's elaboration-order rules, any such reference is guaranteed (more or
less) to occur after the elaboration of the object.

> Eiffel - Possibly the best language in the world - unless proven
> otherwise.

Hmm. To paraphrase -- who was it? Winston Churchill? -- perhaps you
should say "Eiffel is the worst language on Earth ... except for all the
others!" :-)

-- 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: Interface/Implementation (was Re: Design by Contract)

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

On Thu, 4 Sep 1997 22:44:51 GMT, W. Wesley Groleau:
:
:> In Ada, every single package must have a separate spec, so Ada
:> programmers are used to applying this pattern everywhere.  But I'd 
:> wager that very few Eiffel programmers would consider introducing an 
:> abstract parent class for every one of their concrete classes, just to 
:> simulate Ada packaging.  ....
:
:Hear, hear!  Why would an Eiffel programmer want to simulate Ada, when
:he/she could actually use Ada?  (And vice versa, lest anyone think
:I'm making another language-bigot comment...)

I agree. 

If few Eiffel programmers consider introducing an abstract parent class for
every one of their concrete classes, perhaps this is an indication that such
a thing is not generally needed or wanted --- merely for the purpose of
forcing a separate spec from every implementation?  Ada might have other
needs or uses for it. 

I suspect that Eiffel programmers have little reluctance introducing
abstract classes when they make sense as specification.

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> I disagree, the short form is not code, but documentation. As such, 
> they can't be regarded as the same thing.

In Ada, a package spec is code AND documentation.  It is, in a way, 
a contract with all clients of the package, and a precondition for
the implementation.  However, in Eiffel, since the short form comes
FROM the implementation, "documentation" is a good word.  In Ada,
since the specification conceptually precedes and constrains the
implementation, the word we've chosen--specification--is more 
precise than the broader "documentation."

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Marc Wachowitz]

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

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

In article <EG7tIq.n0F@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:

>>SO the issue with Eiffel is not whether you *could* get the effects, e.g.
>>ease of ability to separate spec and body in a CM environment, but whether
>>people *in practice* work this way.
>
>I don't think that's the issue.  If Ada people generally use a technique
>which is superior to what I do, I'd like to find a way to do it using
>Eiffel.  I don't care what people to in practice.  I'm here to learn
>and to hone my own skills.

Don't fight the language.  Something that's naturally expressable in one
language may be quite klunky in another.

You have to consider the features of a language in their _totality_.  Just
because a certain thing may be easier to do in language A than in B,
doesn't mean B is a lesser language than A because of it.  B may have many
other benefits not present in A, and to try to bend B to get that certain
thing, you can acually make B worse.

A designer or systems theorist will tell you to think holistically, and to
not be such a reductionist.

If you really want to hone your skills, then immerse yourself in a language
that uses a completely different paradigm.  Spend a few weeks or months
programming in a functional language or a logic language.

And you should care what others do "in practice."  You don't live on an
island, and so you have to work with other programmers.  Accept what the
standard practice is, because that will make it easier for others to read
and understand your code.  If you're doing a lot of idiomatic stuff, you're
going to be ostracised, even if your intentions are good.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <dewar.873725590@merv>, dewar@merv.cs.nyu.edu says...

>Note how significant it is that I make a simple request for anyone to 
>report in on how Eiffel would work together with a typical CM tool
>like Continuus or Clearcase to achieve this kind of separation.

This is a reasonable request.  I, too, find the lack of response interesting.

There are a number of possible reasons:

1: It can't be done, and the people who have tried it are lying low.

2: Its not actually necessary.

3: It can be done, but the people who are doing it are lying low.

4: It is necessary, but nobody is actually doing it.

I think we can discount (1).  It looks like a pretty simple problem,
and if people here had tried it and failed then I think they would 
have spoken up pretty quickly.

(2) is an interesting possibility.  Most organisations with configuration
control have some kind of test or inspection procedure before release.
Either of these would be sufficient to enforce the existing interface.
Tests would fail with changed interfaces, and inspectors would reject
changed interfaces precisely because they will break existing software.

(3) is also unlikely, for much the same reasons as (1).  Anyone with such a
system would have spoken up by now, and probably offered copies of the
scripts.

(4) is also possible.  If an organisation using Eiffel has sufficiently
chaotic CM processes then it will keep breaking existing software, and
generally fail to make progress.  They would also have a good motive to
keep quiet.  But I doubt that any language feature can rescue such an
organisation.

So in summary, I doubt that separate CM of interface and implementation
is that important.  The only requirement is that they can be examined
separately.

If I were running a multi-person Eiffel project I would put in CM
procedures, including test and inspection, which would check for changes
in interfaces.  If I were running a project with dozens of developers then
I might want something a little more formal.  CM of short forms plus
manual inspection of diffs before internal release would seem to be 
perfectly adequate.

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: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Patrick Doyle wrote:

:In article <EFyK17.2wD@syd.csa.com.au>,
:Don Harrison <nospam@thanks.com.au> wrote:
:>Patrick Doyle wrote:
:>
:>:In article <EFv7yL.yr@syd.csa.com.au>,
:>:Don Harrison <nospam@thanks.com.au> wrote:
:>:>
:>:>Because they serve different purposes. (See my previous post).
:>:
:>:But the deferred class can serve both purposes, can't it?
:>
:>Not in the Ada or Modula sense of the term "interface". I expect the situation 
:>is made somewhat confusing by different nomenclature. Equating Eiffel deferred
:>classes with Java "interfaces" may make sense, for example. (Not sure as 
:>I'm not a Java expert.) But in terms of the Ada/Modula idea of interfaces 
:>(which is the context of this discussion - separate interface and implementation), 
:>deferred classes are not the correct analogue. 
:
:  Ok, let's boil this down to two questions:
:
:1. What is the purpose of short forms/Ada interfaces?

To provide visibility information to a client and the compiler about a class's 
exported features. That is, it documents the client relation.

By comparison, the purpose of deferred classes is to specify what functionality 
will be provided by descendants of a class. That is, it documents the inheritance
relation. This purpose is orthogonal to that of visibility. We may declare, for
example, a deferred class which exports nothing. Such a class doesn't have 
much of client relation with client classes but does have an inheritance relation
with its descendants.

:2. Why can't deferred classes accomplish this purpose?

The issue is clouded a bit by the fact that deferred classes *contain* 
visibility information. So, if you attempt to emulate Ada package specs using
deferred classes, you're not using deferred classes per se to do it, but their
export aspects. 

:>For example, consider an effective class which inherits only from effective 
:>classes. There is no deferred class in this situation, so you obviously can't 
:>use one as an interface. But, clearly, the class *does* have an interface and
:>we see it exists as the short form. I dismiss as nonsensical the notion that 
:>a deferred class can be the analogue in one situation and the short form in 
:>another.
:
:Well, before you dismiss it, let me make a case for a very similar
:situation...
:
:If you want to look at the whole interface of a class, you can use
:Eiffel's "short" tool to extract it.  What the short tool produces is
:code which is, effectively, the deferred class which would correspond
:to the effective class in question (except that it is missing the
:word "deferred" in certain places).

I disagree, the short form is not code, but documentation. As such, they 
can't be regarded as the same thing. 

[..]

:>Also, this example shows that it's false to claim that deferred classes can do 
:>all that separate interfaces (or short forms) can do. 
:
:I haven't yet seen you describe just what an interface or short form *does*.

See above.

:>Something that may further help to cement the difference is to consider that 
:>a deferred class has a short form and hence has an interface in the Ada/Modula
:>sense. If the deferred class itself is an interface, how can it also have 
:>its *own* interface? This would be a meta-interface - a nonsensical concept.
:
:I think this still makes sense.  The short form is only missing the
:word "deferred" (and some other trivial syntactical niceties) in the
:appropriate places.  Add these back in, and the resulting deferred
:class is exactly the same as the original class.  Thus, the class *is*
:its interface.  

I think there are some non-trivial, semantic niceties that make a difference. :)

[..]

:Well, thanks for your patient attempts to persuade me :-) but I'm still
:a bit puzzled...

Hope this has helped.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <dewar.873725590@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>SO the issue with Eiffel is not whether you *could* get the effects, e.g.
>ease of ability to separate spec and body in a CM environment, but whether
>people *in practice* work this way.

I don't think that's the issue.  If Ada people generally use a technique
which is superior to what I do, I'd like to find a way to do it using
Eiffel.  I don't care what people to in practice.  I'm here to learn
and to hone my own skills.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Robert S. White]

In article <dewar.873725590@merv>, dewar@merv.cs.nyu.edu says...

>Still it would be nice to have at least ONE concrete experience report
>that shows that the engineering details of this approach are practical.

  Sorry can't speak for an Eiffel example.  But IME   PCMS (LM F-22), 
DEC CMS and Rational CMVC do a nice job of controlling Ada spec's and
bodies.  But then as you point out the language itself does a good job
of seperating the interface from the implementation.  Note some of the 
compilers used with the CM software above allow the spec to be in the
same file as the body, but in practice we _never_ do that!  We do not
want to.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter

Re: One pass compilation?

[W. Wesley Groleau x4923]

>     The AdaMagic front end is a "nearly" one-pass Ada 95 front end.
>     It "quick-parses" ahead only as necessary to ....

What about defered (private) declarations and values?

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Patrick Doyle says

<<Also, remember that on average, saving the programmer from scanning
below saves only 1/2 the work.  Not an order of magnitude, by any
means.  Perhaps you'll argue that 1/2 is important enough?  Well,>>

Not at all, since we can't keep a whole big object in our heads, if we
have to scan ahead to find information, we may easily have to do an
exponential amount of scanning. On the way forward in a linear pass,
we catalog and abstract and remember what needs to be remembered. When
we scan forward, we are looking for a particular piece of information,
and in general we don't know enough to catalog and abstract, even if
we could keep this kind of non-linear scanning straight.

Consider, in an Algol-68 program you see:

	int q = a * b;

Contrast this to the Ada statement (Pascal, C, ... would be the same)

        Q : constant Integer := A * B;

Now in the Ada case, you know you have seen A and B already, and hopefully
the (more descriptive) names that are present will trigger the reference to
your abstracted catalog gained by reading the text prior to this point and
you will remember what you are looking for. If not, a simple search in
reverse order from the point of reading will find the reference for you.

But in Algol-68, you have to do a rather careful scan forward, paying careful
attention to scope marks, to see if there are declarations of A and B in
the same scope and this is a forward reference. You have to do this even
if A and B are already declared, because normal block structure rules
say that you get the innermost one.

It is this kind of forward reference that the Ada design strenuously tries
to avoid, since it greatly complicates the reading of a program. Worse,
since people generally write linearly anyway, you get in the habit of 
reading linearly. When you see in an Algol-68 program

   int A;
   ...
   begin
      int B := A * 2;
      ...

You will almost always just assume that the A is a backward reference to
the declaration that preceded this. In the rare case where in fact there
is another A ahead of you, you will risk making a significant mistake in
understanding.

Linear comprehension is a very important capability. All text books have
indexes, which are of course functionally similar to hypretext links, but
we do not say "never mind about presenting things in a logical order, 
building on what you have already presented, if you reference something
ahead, people can just look it up in the index". Instead we expend a lot
of effort to present things in a linear order (and indeed software for
computing partial orderings of topics to create appropriate linear orderings
is a standard part of the toolset for educators).

I notice these days that people often create Hypertext documents that
blatantly disregad this principle, and they are a huge pain to read. Sure
this kind of organization is OK for reference or help material, but it is
NOT the way to present a coherent body of knowledge that you expect people
to acquire in a comprehensive manner. A lot of people complain that they
get totally lost zooming around following links in a Hypertext document,
and vey often they are actually not complaining about the paradigm at all,
but rather its misuse to try to patch up poor document organization.

Robert Dewar
Ada Core Technologies

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

> If you think about an OO class. You want to write a complete class,
> without holes but without going over the top. You will write features
> that may not be used in your system, but are there for completeness. So
> that you can reuse the class, or because you may require the system in
> the future. The disadvantage is that you have code in your system that
> isn't used in the end product. This isn't a problem as any good compiler
> will remove the dead code for you. In OO systems you have much more dead
> code that in procedural systems, and it is not wrong for systems to do
> so.

This is neither OO nor procedural.  This (as you even hinted)
is planning for re-use and upgrade, which can and should be done 
in almost any 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: Interface/Implementation (was Re: Design by Contract)

[Nick Leaton]

Robert Dewar wrote:
> 
> Patrick Doyle says
> 
> <<Also, remember that on average, saving the programmer from scanning
> below saves only 1/2 the work.  Not an order of magnitude, by any
> means.  Perhaps you'll argue that 1/2 is important enough?  Well,>>
> 
> Not at all, since we can't keep a whole big object in our heads, if we
> have to scan ahead to find information, we may easily have to do an
> exponential amount of scanning. On the way forward in a linear pass,
> we catalog and abstract and remember what needs to be remembered. When
> we scan forward, we are looking for a particular piece of information,
> and in general we don't know enough to catalog and abstract, even if
> we could keep this kind of non-linear scanning straight.
> 
> Consider, in an Algol-68 program you see:
> 
>         int q = a * b;
> 
> Contrast this to the Ada statement (Pascal, C, ... would be the same)
> 
>         Q : constant Integer := A * B;
> 
> Now in the Ada case, you know you have seen A and B already, and hopefully
> the (more descriptive) names that are present will trigger the reference to
> your abstracted catalog gained by reading the text prior to this point and
> you will remember what you are looking for. If not, a simple search in
> reverse order from the point of reading will find the reference for you.

> But in Algol-68, you have to do a rather careful scan forward, paying careful
> attention to scope marks, to see if there are declarations of A and B in
> the same scope and this is a forward reference. You have to do this even
> if A and B are already declared, because normal block structure rules
> say that you get the innermost one.


If you abstract out what you are trying to achieve.

>         Q : constant Integer := A * B;

If I see this statement, I would like to see/goto the declaration of A
and B.

In Ada, there is the advantage of knowing that one looks higher in the
text file.
In Algol-68, we have the problems of working out the scope.

In both cases the problem is the same, show me the declaration of A or
B. Now 
we can order the text, as in Ada (and enforce it)

The disadvantage of this is that I may want, for valid reasons to order
things in a different way. 

Public at the top, private implementation at the bottom.
Modifiers next to their attributes.
Attributes grouped, modifiers grouped. Procedures grouped.

There are different ways that one may want to cluster things.
Correct me if I'm wrong but doesn't Ada have some guidelines on how to
cluster things?

Now if you have the ability to click on A and either go to the
declaration, or have another window pop up with the declaration of A in
a hypertext way then you can do either, and don't have to scan.

> It is this kind of forward reference that the Ada design strenuously tries
> to avoid, since it greatly complicates the reading of a program. Worse,
> since people generally write linearly anyway, you get in the habit of
> reading linearly. When you see in an Algol-68 program
> 
>    int A;
>    ...
>    begin
>       int B := A * 2;
>       ...
> 
> You will almost always just assume that the A is a backward reference to
> the declaration that preceded this. In the rare case where in fact there
> is another A ahead of you, you will risk making a significant mistake in
> understanding.
> 
> Linear comprehension is a very important capability. All text books have
> indexes, which are of course functionally similar to hypretext links, but
> we do not say "never mind about presenting things in a logical order,
> building on what you have already presented, if you reference something
> ahead, people can just look it up in the index". Instead we expend a lot
> of effort to present things in a linear order (and indeed software for
> computing partial orderings of topics to create appropriate linear orderings
> is a standard part of the toolset for educators).

Again, we have source, we want to see the index. We should have software
produce the index. As an alternative to the bottom up construction of
Ada, why not enforce an alphabetical ordering. You then know where to
scan, albeit it wouldn't read so well as a novel.

Is source code a novel, to be read linearly?
Or is source code a more collection pictures, where composition and
layout, by clustering of components important. And each picture presents
a different prespective of the code, either structural, dependency (Ada
style), alphabetical, type of feature ...

> I notice these days that people often create Hypertext documents that
> blatantly disregad this principle, and they are a huge pain to read. Sure
> this kind of organization is OK for reference or help material, but it is
> NOT the way to present a coherent body of knowledge that you expect people
> to acquire in a comprehensive manner. A lot of people complain that they
> get totally lost zooming around following links in a Hypertext document,
> and vey often they are actually not complaining about the paradigm at all,
> but rather its misuse to try to patch up poor document organization.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

In article <EGAqKI.GsE.0.-s@inmet.camb.inmet.com>,
stt@houdini.camb.inmet.com (Tucker Taft) wrote:


>This may be a practice-versus-capability issue again.  There is
>nothing precluding the use of separate declarations, even if the
>subprogram is local to the body.  One typical coding style adopted
>for Ada package bodies is:
>
>     <declarations of local subprograms>
>
>     <bodies for visible subprograms>
>
>     <bodies for local subprograms>
>
>Given this style, the bodies can be ordered in any way that is convenient.

Funny, I didn't understand Don's comment, because I thought that everyone
already did this.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

Oops, sorry.

Samuel Mize wrote:
> I'm not saying such a design is necessarily BAD.  It may be a case
> where dependency ordering is NOT helpful, so you shouldn't try to use
> it.                          ^^^insert


Sam Mize

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Tucker Taft wrote:

:Don Harrison (nospam@thanks.com.au) wrote:
:
:: ...
:
:: 1) The most important reason is that compulsory backward references force 
:: the developer to order everything (apart from things defined in the spec) 
:: from low level to high level..
:
:This may be a practice-versus-capability issue again.  There is
:nothing precluding the use of separate declarations, even if the
:subprogram is local to the body.  One typical coding style adopted
:for Ada package bodies is:
:
:     <declarations of local subprograms>
:
:     <bodies for visible subprograms>
:
:     <bodies for local subprograms>
:
:Given this style, the bodies can be ordered in any way that is convenient.

Good idea. Although I consider it a workaround, it effectively deals with
the problem. Thanks.

:You might recommend that your programmers adopt the above style.

I'll recommend it be included in the style guide.
:
:: 2) It's problematic when an exported feature is removed from the spec (perhaps
:: because it's erroneously exported) and you have to re-order the body to 
:: accomodate dependencies..
:
:This can certainly be accommodated by putting the separate declaration
:at the top of the body when it is removed from the spec.  There is really 
:no need to reorder.  Here is where a common coding convention could really 
:help.

Agree.

:It may be that experience with Pascal would tend to think of separate
:declarations as the exception, rather than the rule, but there is
:no reason for that view in Ada.  In Pascal, having a separate "forward"
:declaration was somewhat disruptive, because the parameter profile then
:disappeared from the body, which I at least found hindered readability
:of the body.

I agree omitting the profile is a bad idea. So, Ada's forward references are 
an improvement over Pascal's. Of course, I prefer not having to duplicate 
anything at all for redundancy reasons.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don Harrison says

<<While the order of elements previously declared in the spec is free, the
order of elements declared in the body is not, which, though explicable, is
inconsistent.>>

No, it is completely consistent. What you do in the body is to first
declare the specs of all subprograms, and then the sbprograms may be
declared in any order and reference one another. You may complain
about the scheme if you like, but it is certainly totally consistent.
The one rule is that you must declare a subprogram (provide the spec)
before you use it, and before you provide the body.

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <EG9y0E.C65@syd.csa.com.au>,
Don Harrison <nospam@thanks.com.au> wrote:
>
>Matthew Heaney wrote:
>
>:This is not unlike saying that "strong typing"  is a helpful limitation,
>:but a limitation nonetheless.  
>
>I think this is a poor analogy. While strong typing delivers some obvious 
>benefits, I don't think the same can be said of forced dependency ordering.

I think it's a fine analogy, and it's true.  It *is* a helpful limitation.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <mheaney-ya023680001009970904100001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>
>In article <EGAqKI.GsE.0.-s@inmet.camb.inmet.com>,
>stt@houdini.camb.inmet.com (Tucker Taft) wrote:
>
>>One typical coding style adopted
>>for Ada package bodies is:
>>
>>     <declarations of local subprograms>
>>
>>     <bodies for visible subprograms>
>>
>>     <bodies for local subprograms>
>>
>>Given this style, the bodies can be ordered in any way that is convenient.
>
>Funny, I didn't understand Don's comment, because I thought that everyone
>already did this.

This seems to further diminish the value of dependency-ordered declarations.

Then we must ask, if everyone puts all the declarations at the top anyway,
why not let the computer do it for us?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Joachim Durchholz]

Tucker Taft wrote:
> Eiffel seems to have foregone even
> this bit of declaration-before-use -- there seems no need to
> declare the importing of one class prior to using it anywhere
> inside another.

There are two ways to "import" another class in Eiffel.

Variant 1 is inheriting a class. Inheritance links are declared right at
the start of a class, so here we have (incidentally) a rather strong
"import before use" policy.

Variant 2 is using a class, by declaring a parameter or local variable
of that class. Eiffel does not have an import clause in that case at
all!
This isn't even a disadvantage because an Eiffel module can contain only
one class (in fact there are no modules beyond classes in Eiffel).
Say we have a declaration
  feature dump (x: CONTAINER) is...
so we know x is of class CONTAINER. There is no module CONTAINER is in,
so we don't need an import clause to tell us (or the compiler) where to
find CONTAINER.
If I remember correctly, Ada import clauses are also used to resolve
name clashes, but that's unnecessary in Eiffel, too: anything in
CONTAINER will be used via x, so we always have a qualified call of the
form
  x.something
which automatically provides the necessary context.

Note 1: Note that x is much shorter than CONTAINER. If an Eiffel
"module" is so pervasive that typing the name everywhere becomes a
nuisance, we can choose entity names that are as short as we like to
access these features. In 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!).
Note 2: Inheritance gives access to the imported features without a need
for qualification, so here the possibility for name clashes exists. In
Eiffel you must rename such features in the inheriting class (which is
useful if the features are exported - inheriting two features with the
same name does not mean they are the same).

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Matthew Heaney wrote:

:In article <EG4KGI.ILG@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
:Doyle) wrote:
:
:>>The Eiffel camp seems to think that dependency order is a limitation, but
:>>it was a deliberate decision by Ada's designers.   As an Ada programmer, I
:>>haven't found it to be a limitation at all; in fact, I find it quite
:>>helpful, exactly as the designers imagined it would be.

That's interesting because I find it a hinderance more than a help for a number
of reasons:

1) The most important reason is that compulsory backward references force 
the developer to order everything (apart from things defined in the spec) 
from low level to high level. This is the exact opposite of what a human 
reader needs to comprehend the body in a linear top-down pass. It's far easier 
for them if high level stuff is declared first and low level implementation 
detail progressively lower down. That way, they can readily grasp the high 
level picture at a more abstract level and, if they require more detail, they 
can read on.

This is why Eiffel classes usually have exported features at the top and 
private ones at the bottom. You might expect to see primary ordering on 
the basis of functionality and secondary ordering from high level to low 
level. 

Due to Ada's dependency ordering, I often find myself reading package bodies 
in reverse order.

2) It's problematic when an exported feature is removed from the spec (perhaps
because it's erroneously exported) and you have to re-order the body to 
accomodate dependencies. If you're not the author of the body, you have to 
work out the particular scheme used and find an appropriate spot for it.
This may not be straighforward and is also likely to cause a ripple effect 
because operations the operation itself depends on may subsequently have to 
move. I find the trial-and-error nature of this activity incredibly annoying.

This problem doesn't arise in Eiffel because ordering is free. 

3) It's also problematic in the case of mutually recursive types and operations.
You are forced to pre-declare those that are forward referenced. For example, 

  type a_rec;                       -- pre-declaration
  type a_rec_ptr is access a_rec;
  type a_rec is record
    next: a_rec_ptr;
  end record;

and

  procedure do_d;                   -- pre-declaration
  procedure do_c is
  begin do_d; end;

  procedure do_d is
  begin do_c; end;

While not a huge burden, it's inelegant and un-necessary, IMO.

Again, this issue doesn't arise in Eiffel.


:This is not unlike saying that "strong typing"  is a helpful limitation,
:but a limitation nonetheless.  

I think this is a poor analogy. While strong typing delivers some obvious 
benefits, I don't think the same can be said of forced dependency ordering.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Matthew Heaney]

In article <EG9y0E.C65@syd.csa.com.au>, nospam@thanks.com.au wrote:


>:This is not unlike saying that "strong typing"  is a helpful limitation,
>:but a limitation nonetheless.  
>
>I think this is a poor analogy. While strong typing delivers some obvious 
>benefits, I don't think the same can be said of forced dependency ordering.

Well, at least Jean Ichbiah, Tony Hoare, and Robert Dewar disagree with
you.  Forced dependency order was a very deliberate choice.

Again, to recap Tony's Turing Award lecture: "We certainly want programs to
be read by _people_ [his italics] and people prefer to read things once in
a single pass."  I guess Tony wasn't talking about people that read Eiffel
programs, eh?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Interface/Implementation (was Re: Design by Contract)

[Nick Leaton]

John G. Volan wrote:

> Suppose such a "once" function is referenced at several different points
> in a program. If the compiler were able to predict which of these
> references would be the first to occur at runtime, then perhaps it would
> be able to perform some optimizations: It could inline the
> object-creation code right at the first call, and then turn all the
> subsequent calls into direct object references.
> 
> But I don't think it's possible, in principle, for a compiler to make
> such a prediction. (My guess is that it's equivalent to the halting
> problem.)  So it seems to me that every reference to a "once" function
> would have to incur the overhead of a functional call, plus a
> conditional test to determine whether the object has already been
> created "once" before.  Sounds like a pretty heavy-weight way to
> implement global objects.

That isn't the only way to implement it. As the reference is void
initialy, you could trap the attempt to access, then call the creation.
The interupt is relatively cheap, particularly as it is a once per
exectution. Subsequent accesses are as fast as always.

> Contrast this with Ada's scheme: The compiler treats a reference to a
> global object the same way it treats any other kind of object reference,
> with no extra overhead inserted into the generated code.  But because of
> Ada's elaboration-order rules, any such reference is guaranteed (more or
> less) to occur after the elaboration of the object.

Does this mean that all global objects are initialised? If so compare
that with just in time creation. If you don't use a global, it isn't
created. You cannot tell which globals you will need at compile time,
just which one may be needed.
Now if you have a global that takes a long time to create, reference it
at the start, and you get the psycologically better situation of a
longer start up time, traded off for no long pauses once you are
running. This would also be important in real time systems.


> > Eiffel - Possibly the best language in the world - unless proven
> > otherwise.
> 
> Hmm. To paraphrase -- who was it? Winston Churchill? -- perhaps you
> should say "Eiffel is the worst language on Earth ... except for all the
> others!" :-)
> 

Actually it comes from a lager advertisment. Heiniken, where it was the
slogan.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

Nick Leaton wrote:
> 
> John G. Volan wrote:
> > > Eiffel - Possibly the best language in the world - unless proven
> > > otherwise.
> >
> > Hmm. To paraphrase -- who was it? Winston Churchill? -- perhaps you
> > should say "Eiffel is the worst language on Earth ... except for all
the
> > others!" :-)
> >
> 
> Actually it comes from a lager advertisment. Heiniken, where it was the
> slogan.
> 
> --
> 
> Nick

The quote Jon is referring to is, I believe, from Winston Churchill,
and is roughly "Democracy is the worst system of government,
except for all the others."  I assume you mean YOUR quote comes
from the Heiniken advert.

No offense or argument intended, I just happen to like the
Churchill quote and wanted the attributions clear.

Sam Mize

Re: Interface/Implementation (was Re: Design by Contract)

[Tucker Taft]

Don Harrison (nospam@thanks.com.au) wrote:

: ...

: 1) The most important reason is that compulsory backward references force 
: the developer to order everything (apart from things defined in the spec) 
: from low level to high level. This is the exact opposite of what a human 
: reader needs to comprehend the body in a linear top-down pass. It's far easier 
: for them if high level stuff is declared first and low level implementation 
: detail progressively lower down. That way, they can readily grasp the high 
: level picture at a more abstract level and, if they require more detail, they 
: can read on.

This may be a practice-versus-capability issue again.  There is
nothing precluding the use of separate declarations, even if the
subprogram is local to the body.  One typical coding style adopted
for Ada package bodies is:

     <declarations of local subprograms>

     <bodies for visible subprograms>

     <bodies for local subprograms>

Given this style, the bodies can be ordered in any way that is convenient.
    
: This is why Eiffel classes usually have exported features at the top and 
: private ones at the bottom. You might expect to see primary ordering on 
: the basis of functionality and secondary ordering from high level to low 
: level. 

: Due to Ada's dependency ordering, I often find myself reading package bodies 
: in reverse order.

You might recommend that your programmers adopt the above style.

: 2) It's problematic when an exported feature is removed from the spec (perhaps
: because it's erroneously exported) and you have to re-order the body to 
: accomodate dependencies. If you're not the author of the body, you have to 
: work out the particular scheme used and find an appropriate spot for it.
: This may not be straighforward and is also likely to cause a ripple effect 
: because operations the operation itself depends on may subsequently have to 
: move. I find the trial-and-error nature of this activity incredibly annoying.

This can certainly be accommodated by putting the separate declaration
at the top of the body when it is removed from the spec.  There is really 
no need to reorder.  Here is where a common coding convention could really 
help.

It may be that experience with Pascal would tend to think of separate
declarations as the exception, rather than the rule, but there is
no reason for that view in Ada.  In Pascal, having a separate "forward"
declaration was somewhat disruptive, because the parameter profile then
disappeared from the body, which I at least found hindered readability
of the body.

: ...

: Don.                     (Reverse to reply)
: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
: Don Harrison             au.com.csa.syd@donh

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

[reformatted for line length]

Don Harrison wrote:
> 
> Matthew Heaney wrote:
> 
> :In article <EG4KGI.ILG@ecf.toronto.edu>, doylep@ecf.toronto.edu
> :(Patrick Doyle) wrote:
> :
> :>>The Eiffel camp seems to think that dependency order is a
> :>>limitation, but it was a deliberate decision by Ada's designers.
> :>>As an Ada programmer, I haven't found it to be a limitation at
> :>>all; in fact, I find it quite helpful, exactly as the designers
> :>>imagined it would be.
> 
> That's interesting because I find it a hinderance more than a help for
> a number of reasons:
> 
> 1) The most important reason is that compulsory backward references
> force the developer to order everything (apart from things defined
> in the spec) from low level to high level. This is the exact
> opposite of what a human reader needs to comprehend the body in a
> linear top-down pass. It's far easier for them if high level stuff
> is declared first and low level implementation detail progressively
> lower down. That way, they can readily grasp the high level picture
> at a more abstract level and, if they require more detail, they
> can read on.

I'm rather an Ada bigot, but you have convinced me that, if people
were reading large packages or procedures as linear text, this would
be a good approach, perhaps even a better approach.

As several people (including Don) have pointed out, if you try to
read an Ada unit with a lot of sub-procedures, you wind up reading
it from the end backward.

As nobody has yet pointed out, you're not going to read and
understand this large a code artifact in one pass anyway, so
the ordering is largely irrelevant.  You need to be able to
FIND referred-to elements, but it neither helps nor hurts that
all references are to earlier items (especially when the
earlier item may be a forward declaration to a later item).

So I would agree that the read-in-one-pass argument in favor
of dependency ordering is weak, at best.


> 2) It's problematic when an exported feature is removed from the
> spec (perhaps because it's erroneously exported) and you have to
> re-order the body to accomodate dependencies.

You can simply move the procedure specification (the part that
appeared in the spec) to the start of the body, with an
appropriate comment.

>If you're not the author of the body, you have to
> work out the particular scheme used and find an appropriate spot
> for it.  This may not be straighforward and is also likely to cause
> a ripple effect because operations the operation itself depends on
> may subsequently have to move. I find the trial-and-error nature of
> this activity incredibly annoying.

If it's a trial-and-error process, then the design isn't correctly
structured for this kind of organization, and you definitely SHOULD
move the procedure spec to the head of the body.

I'm not saying such a design is necessarily BAD.  It may be a case
where dependency ordering is helpful, so you shouldn't try to use
it.  I've seen well-designed Ada packages where the body starts by
forward-declaring all the internal procedures, so they can use
each other.  A recursive descent parser might be coded this way.

I find it helpful to see, up front, which things are 

> 3) It's also problematic in the case of mutually recursive types
> and operations.  You are forced to pre-declare those that are
> forward referenced.

This is in fact one of the arguments in FAVOR of dependency
ordering: it prevents accidental mutual recursion, and documents
your intent for maintenance coders.

- - -

I find that Ada's dependency ordering provides a useful level
of organization in many cases, and that it is helpful to have
forward declarations as an explicit indication that this ordering
rule is being abandoned.  However, that may just be because I'm
used to it.  Certainly you can order your declarations this way,
if it improves clarity, in a language that doesn't require it.

Sam Mize

Re: Interface/Implementation (was Re: Design by Contract)

[Nick Leaton]

Tucker Taft wrote:
> 
> Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
> 
> : ... It is in fact NOT possible in any reasonable
> : way to create a one-pass compiler for Ada 95, and certainly no one has
> : done so.
> 
> In the "for what it's worth" department...
> 
>     The AdaMagic front end is a "nearly" one-pass Ada 95 front end.
>     It "quick-parses" ahead only as necessary to find things like labels
>     and the name of a generic unit, and it does static analysis for
>     all declarations between bodies before emitting elaboration
>     code for the declarations (because rep-clauses can follow
>     the declarations, but not follow an intervening body).
>     But other than that, it can generate IL (intermediate language)
>     as it goes.

Which is then passed through various other passes, such as linking, code
optimisation, generation of machine code from the IL ...
 
>     What this means is that you could feed the source code for
>     a package body into the front end and start seeing stuff coming
>     out of the other end before you finished feeding in the whole package
>     body.
> 
> Be that as it may, I agree with Robert that the "one pass" model is most
> important in its role in simplifying the semantics of "elaboration"
> (the executable code associated with declarations) and in helpng with
> human comprehension.

OK, so we come to the crux. The one pass compiler is not the real issue,
you shouldn't care about that part. The human comprehension issue is the
important concern.
 
> Coming from Ada, it is somewhat alarming to read Java code where
> fields and methods can be referenced in code prior to their
> declarations.  This seems to be one side-effect of a lack of
> separate method declarations in Java.

Ordering code bottom up a la Ada vs ordering code in any order. Does
having the ability to freely order increase the readability of the code?
Well I do like grouping features with a class in clusters, and
(hopefully) being consistent between clusters. You can always order
bottom up if you want to, but you don't have to. In other words having
free ordering is a superset of bottom up ordering.

 > Java does have an "import" clause which must come first,
> analagous to the Ada "with" clause, when referring to external
> (packages of) classes.  Eiffel seems to have foregone even
> this bit of declaration-before-use -- there seems no need to
> declare the importing of one class prior to using it anywhere
> inside another.  Though to be fair, even in Java, "import" is
> not needed for java.lang.*, nor if you are willing to use the
> fully qualified class name rather than just its simple name.

The assumption in Eiffel is let the compiler do the work for you, so as
another example, working out dependencies is a job for the compiler. You
don't write makefiles with Eiffel.

When I changed from C++ to Eiffel, there is a major change in the way
you work. C++ Pascal, (and probably Ada) are languages that you write
using text editors. Eiffel is very different, using (ISE's) workbench
writting code is much closer to browsing the net. You are dragging and
droping code into windows, and then applying filters such as the short
tool, filters to find the attributes, features, once features, deferred
features etc. Browsing class heirachies. etc...
This, I believe although I haven't used one is close to a Small talk
environment. It is a very different way of working, and takes a couple
of weeks to get used to it.

Someone recently pointed out that you could replace text file based
systems with code in a database. This is a hybrid between the two.

If you think about an OO class. You want to write a complete class,
without holes but without going over the top. You will write features
that may not be used in your system, but are there for completeness. So
that you can reuse the class, or because you may require the system in
the future. The disadvantage is that you have code in your system that
isn't used in the end product. This isn't a problem as any good compiler
will remove the dead code for you. In OO systems you have much more dead
code that in procedural systems, and it is not wrong for systems to do
so.


-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Interface/Implementation (was Re: Design by Contract)

[Tucker Taft]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

: ... It is in fact NOT possible in any reasonable
: way to create a one-pass compiler for Ada 95, and certainly no one has
: done so. 

In the "for what it's worth" department...

    The AdaMagic front end is a "nearly" one-pass Ada 95 front end.
    It "quick-parses" ahead only as necessary to find things like labels 
    and the name of a generic unit, and it does static analysis for
    all declarations between bodies before emitting elaboration
    code for the declarations (because rep-clauses can follow
    the declarations, but not follow an intervening body).  
    But other than that, it can generate IL (intermediate language)
    as it goes.

    What this means is that you could feed the source code for
    a package body into the front end and start seeing stuff coming 
    out of the other end before you finished feeding in the whole package 
    body.

Be that as it may, I agree with Robert that the "one pass" model is most 
important in its role in simplifying the semantics of "elaboration" 
(the executable code associated with declarations) and in helpng with 
human comprehension.

Coming from Ada, it is somewhat alarming to read Java code where
fields and methods can be referenced in code prior to their 
declarations.  This seems to be one side-effect of a lack of
separate method declarations in Java.

Java does have an "import" clause which must come first,
analagous to the Ada "with" clause, when referring to external
(packages of) classes.  Eiffel seems to have foregone even
this bit of declaration-before-use -- there seems no need to
declare the importing of one class prior to using it anywhere
inside another.  Though to be fair, even in Java, "import" is
not needed for java.lang.*, nor if you are willing to use the
fully qualified class name rather than just its simple name.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Interface/Implementation (was Re: Design by Contract)

[John Viega]

In article <slrn61bgd3.fkc.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) writes:

> I agree. 
> 
> If few Eiffel programmers consider introducing an abstract parent class for
> every one of their concrete classes, perhaps this is an indication that such
> a thing is not generally needed or wanted --- merely for the purpose of
> forcing a separate spec from every implementation?  Ada might have other
> needs or uses for it. 
> 
> I suspect that Eiffel programmers have little reluctance introducing
> abstract classes when they make sense as specification.

Don't consider what I have to say hard evidence, but from what I have
seen in C++ programmers, they are less likely to seperate interface
from implementation by useing purely abstract classes than say a Java
programmer, because it just never occurs to most of them to do so.
Many such people consider themselves to be excellent OO designers,
too.  I have seen such people write in Java, appreciate the explicit
interface construct, use it extensively, and then go back to their
same old habits when they return to C++.

From what I've seen, even Java programmers rarely have an interface
that maps to every concrete class they write.

Re: Interface/Implementation (was Re: Design by Contract)

[Veli-Pekka Nousiainen]

W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote in article
<3415B700.1088@pseserv3.fw.hac.com>...
> 
> > I disagree, the short form is not code, but documentation. As such, 
> > they can't be regarded as the same thing.
> 
> In Ada, a package spec is code AND documentation.  It is, in a way, 
> a contract with all clients of the package, and a precondition for
> the implementation.  However, in Eiffel, since the short form comes

That is not the way I create my interfaces in Eiffel. 
I succest that you try EiffelCase and forward engineering. 
See what it generates from your detail design. 
Apply then 'short' and compare the results. Suprise might follow... 
VP 

> FROM the implementation, "documentation" is a good word.  In Ada,
> since the specification conceptually precedes and constrains the
> implementation, the word we've chosen--specification--is more 
> precise than the broader "documentation."
> 
> -- 
> ----------------------------------------------------------------------
>     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: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

Veli-Pekka Nousiainen wrote:
> That is not the way I create my interfaces in Eiffel.
> I succest that you try EiffelCase and forward engineering.
> See what it generates from your detail design.
> Apply then 'short' and compare the results. Suprise might follow...
> VP

This might well be a compelling argument, if everyone working
in Ada had EiffelCase available and knew your methods.

Since we don't, if you want to convince us, you'll have to
describe the tool, the method, and the results.

Sam Mize

Re: Interface/Implementation (was Re: Design by Contract)

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

On 10 Sep 1997 16:57:20 GMT, John Viega <jtv2j@cobra.cs.virginia.edu> wrote:
:
:In article <slrn61bgd3.fkc.kennel@lyapunov.ucsd.edu> kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) writes:
:
:> 
:> I suspect that Eiffel programmers have little reluctance introducing
:> abstract classes when they make sense as specification.
:
:Don't consider what I have to say hard evidence, but from what I have
:seen in C++ programmers, they are less likely to seperate interface
:from implementation by useing purely abstract classes than say a Java
:programmer, because it just never occurs to most of them to do so.
:Many such people consider themselves to be excellent OO designers,
:too.  I have seen such people write in Java, appreciate the explicit
:interface construct, use it extensively, and then go back to their
:same old habits when they return to C++.

I can see this, and I think the Eiffel practice and cleanliness is closest
to the Java side than the C++ side. 

:From what I've seen, even Java programmers rarely have an interface
:that maps to every concrete class they write.

That may be the case.  Some people might consider this foolish laziness, but
I'm not so convinced.  It may in fact be a recognition that not every concrete
class deserves a separate interface. 

-- 
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD           
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address. 
*

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <34167245.0@news.uni-ulm.de>,
Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
>
>Patrick Doyle (doylep@ecf.toronto.edu) wrote:
>> Ok.  I'll go for that, because my argument all along has been that
>> abstract superclasses can do as much as *and more than* Ada specs.
>> So let's consider just the export aspects of an abstract class.  Is
>> there anything that they can't do which Ada specs can do?
>
>How do you prevent that the implemented class derived from an abstract
>specification class can add public methods to those mentioned in that
>abstract class? 

Close, but IMO no cigar.  If we are faithfully to compare Ada and
Eiffel ways of doing this, then just as an Ada package is accessed
through its interface, so would the Eiffel class be accessed only
through the abstract superclass.  Thus, even if the subclass
added public features, the client couldn't use them.

Besides, it's hard to see how the ability to extend the interface
would be a liability anyway.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Joachim Durchholz]

Joerg Rodemann wrote:
> How do you prevent that the implemented class derived from an abstract
> specification class can add public methods to those mentioned in that
> abstract class?

Why should I want to do that?
(I could think of some situations where such a restriction might be
useful, but these are rather exotic.)

In what ways is the Ada way of doing that useful?

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <mheaney-ya023680000909970052480001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>
>In article <EG7tIq.n0F@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
>Doyle) wrote:
>
>>I don't think that's the issue.  If Ada people generally use a technique
>>which is superior to what I do, I'd like to find a way to do it using
>>Eiffel.  I don't care what people to in practice.  I'm here to learn
>>and to hone my own skills.
>
>Don't fight the language.  Something that's naturally expressable in one
>language may be quite klunky in another.

Give me some credit.  :-)  I'm not going to force myself to use some
methodology which makes my life harder.

>You have to consider the features of a language in their _totality_.  Just
>because a certain thing may be easier to do in language A than in B,
>doesn't mean B is a lesser language than A because of it.  B may have many
>other benefits not present in A, and to try to bend B to get that certain
>thing, you can acually make B worse.
>
>A designer or systems theorist will tell you to think holistically, and to
>not be such a reductionist.

Woah, now you're reading more into my comment than I put there.  Plus,
you've move into name-calling.  I think this has gone far enough.

I just meant that I'm trying to learn methodologies from other people.
If those people use different tools, then I'd like to know how to do
what they do with my tools.  Clearly, if this turns out to be so
difficult as to offer no advantage, I won't end up doing it.  But I'm
still allowed to ask the question.

>If you really want to hone your skills, then immerse yourself in a language
>that uses a completely different paradigm.  Spend a few weeks or months
>programming in a functional language or a logic language.

Great idea.  Then, presumably, I'd take what I'd learned and apply
whatever I could to my old paradigm.  If it's not helpful, of course
I'd stop.

And in the mean time, I can still ask others in this newsgroup about
their methodologies and try to learn from them.

>And you should care what others do "in practice."  You don't live on an
>island, and so you have to work with other programmers.  Accept what the
>standard practice is, because that will make it easier for others to read
>and understand your code.  If you're doing a lot of idiomatic stuff, you're
>going to be ostracised, even if your intentions are good.

I think this stuff is pretty self-evident.  All I was trying to
say is that this discussion is not merely about what is done in
practice, because some of us would like to learn new things.

Clearly, I was a bit overzealous when I said I don't care what others
do in practice.  :-)

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <EG7zJn.366@syd.csa.com.au>,
Don Harrison <nospam@thanks.com.au> wrote:
>
>Patrick Doyle wrote:
>
>:  Ok, let's boil this down to two questions:
>:
>:1. What is the purpose of short forms/Ada interfaces?
>
>To provide visibility information to a client and the compiler about a class's 
>exported features. That is, it documents the client relation.

Ok, I agree with that.

>By comparison, the purpose of deferred classes is to specify what functionality 
>will be provided by descendants of a class. 

...which includes visibility information.  (Just for the record.  :-)

>That is, it documents the inheritance
>relation. This purpose is orthogonal to that of visibility. 

I think this seems to be using a pretty loose definition of "orthogonal".

Inheritance can be inheritance of interface and/or inheritance of
implementation.  Interface inheritance means inheriting visibility
information.

Orthogonal means that anything achieved using one technique cannot
be achieved using the other.  But specifying implementation (ie.
the client relationship) can be accomplished by inheritance, so I'm
not clear on how these are orthogonal.  (Perhaps I'm mistaken about
what "orthogonal" means?  I'm going on recollections of a book I
read a while back.)

>We may declare, for
>example, a deferred class which exports nothing. Such a class doesn't have 
>much of client relation with client classes but does have an inheritance relation
>with its descendants.

Couldn't you also have an empty package spec?

>:2. Why can't deferred classes accomplish this purpose?
>
>The issue is clouded a bit by the fact that deferred classes *contain* 
>visibility information. So, if you attempt to emulate Ada package specs using
>deferred classes, you're not using deferred classes per se to do it, but their
>export aspects. 

Ok.  I'll go for that, because my argument all along has been that
abstract superclasses can do as much as *and more than* Ada specs.
So let's consider just the export aspects of an abstract class.  Is
there anything that they can't do which Ada specs can do?

>:If you want to look at the whole interface of a class, you can use
>:Eiffel's "short" tool to extract it.  What the short tool produces is
>:code which is, effectively, the deferred class which would correspond
>:to the effective class in question (except that it is missing the
>:word "deferred" in certain places).
>
>I disagree, the short form is not code, but documentation. As such, they 
>can't be regarded as the same thing. 

The Short tool could very easily be modified to put the word "deferred"
in the right places and produce actual code.  Does this change so
fundamentally alter the resulting file that they are now "orthogonal"
to each other?  IMO clearly it doesn't.

>:I think this still makes sense.  The short form is only missing the
>:word "deferred" (and some other trivial syntactical niceties) in the
>:appropriate places.  Add these back in, and the resulting deferred
>:class is exactly the same as the original class.  Thus, the class *is*
>:its interface.  
>
>I think there are some non-trivial, semantic niceties that make a difference. :)

Ok, we can agree to disagree on this, but either way, it seems to me
that the fact remains that there's nothing that Ada specs can do that
Eiffel's deferred classes can't do.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Joerg Rodemann]

Patrick Doyle (doylep@ecf.toronto.edu) wrote:
> Ok.  I'll go for that, because my argument all along has been that
> abstract superclasses can do as much as *and more than* Ada specs.
> So let's consider just the export aspects of an abstract class.  Is
> there anything that they can't do which Ada specs can do?

How do you prevent that the implemented class derived from an abstract
specification class can add public methods to those mentioned in that
abstract class? Using Ada we have just two possibilities for add-ons:
   1.) Create a child package and thus gain full access to the internals
       of a class.
   2.) Create a new package and derive a new class from the former one or
       define classwide methods. All you can do now are overriding
       existing operations and use the methods exported by the former
       package.
Also do not forget that Ada packages often contain more than one class
declaration.

By the way: I would like to hear from anyone who uses ClearCase along with
Eiffel, too. Or is the usual development environment already multi-user,
multi-platform capable?

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: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Matthew says

<<"...I adopted certain basic principles [of language design] which I believe
to be as valid today as they were then...(4) The forth principle was that
the compiler should use only a single pass....I can still recommend
single-pass top-down recursive descent both as an implementation method and
as a design principle for a programming language.  [Note carefully the next
sentance.] First, we certainly want programs to be read by _people_ and
people prefer to read things once in a single pass."

That last line is exactly what Robert was refering to: design the language
so that it can be read by _humans_ in a single pass (even if it isn't
compiled that way), because that's what humans prefer to do.

If only the rest of Tony's lecture were that favorable toward Ada...>>


Tony is talking about semantic understanding here. Of course he does not
think that real, useful, compilers can generate high quality code in a 
single pass.

As for unfavorable to Ada, Tony was surprised that people took his remarks
on Ada as being so negative. I often quote one of his favorable remarks,
which is that it is possible to choose a subset of Ada that is safe and
realiable. Since of course all real applications *are* written in a subset
chosen to be appropriate to the application area, this is a most critical
statement.

Be sure to read TH's forward to Brian's book (that was a while ago, this is
not late breaking news here :-)

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Tuck said

<<    The AdaMagic front end is a "nearly" one-pass Ada 95 front end.
    It "quick-parses" ahead only as necessary to find things like labels
    and the name of a generic unit, and it does static analysis for
    all declarations between bodies before emitting elaboration
    code for the declarations (because rep-clauses can follow
    the declarations, but not follow an intervening body).
    But other than that, it can generate IL (intermediate language)
    as it goes.>>

Sure, but this is not exactly a compiler, since you are moving to an
interpretive environment. An end to end system will then feed the JVM
into a JIT compiler, which counts as at *least* one more pass. Remember
my original statement was that it was impossible to generate efficient
code in a single pass.

It certainly is true however, that even generating code at this level in
a single pass is not possible in languages which do not pay attention
to the single pass design principle.

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert Dewar wrote:

:<<:The spec may be ordered to make things easy for the client to read.
::The body may be ordered to make the implementation easy to understand.
:
:With Eiffel, you have both and ordering is preserved.>>
:
:That's rather confused, in Eiffel you have to use the same ordering 
:effectively for the spec and the body. 

Confusing, not confused. :)

I just mean that I think the same ordering may be appropriate for both.

But, as they, YMMV (and it does).


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Samuel Mize says

<<As several people (including Don) have pointed out, if you try to
read an Ada unit with a lot of sub-procedures, you wind up reading
it from the end backward.>>

Once again, I do not know what this is about. I can imagine someone
deliberately ordering a program so that it has to be read from the
end backward, but I thankfully never encountered an Ada program
written this way, and the suggestion that this is somehow required
in Ada is entirely bogus.

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Sam Mize wrote:

[..]

:> 2) It's problematic when an exported feature is removed from the
:> spec (perhaps because it's erroneously exported) and you have to
:> re-order the body to accomodate dependencies.
:
:You can simply move the procedure specification (the part that
:appeared in the spec) to the start of the body, with an
:appropriate comment.

Agree.

:..I've seen well-designed Ada packages where the body starts by
:forward-declaring all the internal procedures, so they can use
:each other.  

Agree.

:> 3) It's also problematic in the case of mutually recursive types
:> and operations.  You are forced to pre-declare those that are
:> forward referenced.
:
:This is in fact one of the arguments in FAVOR of dependency
:ordering: it prevents accidental mutual recursion, and documents
:your intent for maintenance coders.

I wonder would accidental mutual recursion usually be obvious because the 
program would hang (or run out of memory) due to the absence of a 
termination condition. 

Alternatively, an assertion might be violated which would draw attention to it.

:I find that Ada's dependency ordering provides a useful level
:of organization in many cases, and that it is helpful to have
:forward declarations as an explicit indication that this ordering
:rule is being abandoned.  However, that may just be because I'm
:used to it.  

That's probably why the Eiffel convention initially seemed upside down to me 
at first. :)


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert Dewar wrote:

:There is no reason to have an expectation that the routines in the body
:be in the same order as those in the spec, and as I have pointed out
:before, we always order the subprograms in the body alphabetically, which
:turns out to be much more convenient for reference purposes, particularly
:if you print out the code.. 

Not sure who you mean when you say "we always order..", but you can't be 
speaking on behalf of all Ada developers. I understand why you might have 
such a preference but it's by no means common to everyone.

For those who may choose to order differently, there *is* a reason why they
may want to preserve the same ordering as the spec - consistency. If you're
familiar with the ordering in the spec, then you don't have to learn a 
different ordering for the body (Yes, I know you only have to remember the 
alphabet if you use alphabetic ordering; presumably, that's why you like it). 


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert Dewar wrote:

:Don Harrison says
:
:<<While the order of elements previously declared in the spec is free, the
:order of elements declared in the body is not, which, though explicable, is
:inconsistent.>>
:
:No, it is completely consistent. What you do in the body is to first
:declare the specs of all subprograms, and then the sbprograms may be
:declared in any order and reference one another. You may complain
:about the scheme if you like, but it is certainly totally consistent.
:The one rule is that you must declare a subprogram (provide the spec)
:before you use it, and before you provide the body.

I think you're getting your contexts confused here. My comment was made in 
the specific context of *no* prior declarations.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Code ordering

[Steve Furlong]

In article <3416BE96.A38F2295@calfp.co.uk>,
Nick Leaton  <nickle@pauillac> wrote:
...
>Ordering code bottom up a la Ada vs ordering code in any order. Does
>having the ability to freely order increase the readability of the code?
>Well I do like grouping features with a class in clusters, and
>(hopefully) being consistent between clusters. You can always order
>bottom up if you want to, but you don't have to. In other words having
>free ordering is a superset of bottom up ordering.

Look into "literate programming". Donald Knuth invented it for Pascal,
another language which imposes strict limits on the ordering of source
code. LP allows and encourages you to arrange source code in whatever
order best facilitates comprehension by a human reader, and provides
tools to massage the code into whatever arrangement the compiler needs.

The FAQ for comp.programming.literate gives the names and download
locations for quite a few LP packages, some of which can be used with
Ada. It also gives names and brief reviews of several books and
articles on LP.


Regards,
Steve Furlong

Re: Interface/Implementation (was Re: Design by Contract)

[Lee Webber]

On Wed, 10 Sep 1997 09:04:10 -0800, mheaney@ni.net (Matthew Heaney)
wrote:

>
>In article <EGAqKI.GsE.0.-s@inmet.camb.inmet.com>,
>stt@houdini.camb.inmet.com (Tucker Taft) wrote:
>
>
>>This may be a practice-versus-capability issue again.  There is
>>nothing precluding the use of separate declarations, even if the
>>subprogram is local to the body.  One typical coding style adopted
>>for Ada package bodies is:
>>
>>     <declarations of local subprograms>
>>
>>     <bodies for visible subprograms>
>>
>>     <bodies for local subprograms>
>>
>>Given this style, the bodies can be ordered in any way that is convenient.
>
>Funny, I didn't understand Don's comment, because I thought that everyone
>already did this.

Patrick Doyle already said the below in one sentence, but I thought I
might put a little more mustard on it:

   So Ada imposes dependency ordering that makes people list their
   subprograms bottom-up, but everybody defeats this by means of
   forward declarations and lists things top-down because everybody
   knows that's the more natural way to read a program.  Does anyone
   see an element of the bizarre in this?

   I've programmed extensively in Modula-2 and Pascal, and I always
   thought it was a misfeature that I had to put the main program at
   the bottom.  (Not so true for initialization code for other
   than the main module.)  I've even gone so far as to put all the
   detail in a subroutine and make the entire main program a call
   to that routine, just to get it at the top of the source.

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

<<Due to Ada's dependency ordering, I often find myself reading package bodies
in reverse order.>>


This makes no sense, you arrange the subprograms in a package body in any
order that you please, I don't know whose code you have been reading, but
this does not make sense.

First, why are you "reading" package bodies at all in this sense, I can't
see this as a useful activity.

What you might want to do is to read through the specificatoins that are
part of a body, but these of course can be in any order you please.

Then you read the subprogram implementations if you want, and of course
these can be in any order you please.

So to be clear, the typical structure of an Ada package body (we are talking
now about the ordering of sections of code) is as follows:


Collection of subprogram specifications in any order you please

followed by

Collection of subprogram bodies in any order you please, which need not
be the same order as used for the subprogram specifications.

Where exactly is the dreaded ordering dependency here that is causing you
so much grief?

Re: Interface/Implementation (was Re: Design by Contract)

[Robert S. White]

In article <EG9wrJ.F3t@ecf.toronto.edu>, doylep@ecf.toronto.edu says...
>
>In article <EG7zJn.366@syd.csa.com.au>,
>Don Harrison <nospam@thanks.com.au> wrote:
>>
>>By comparison, the purpose of deferred classes is to specify what 
>>functionality will be provided by descendants of a class. 
>
>...which includes visibility information.  (Just for the record.  :-)
>
>>That is, it documents the inheritance
>>relation. This purpose is orthogonal to that of visibility. 
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I think this seems to be using a pretty loose definition of "orthogonal".

   Don seems to be using the word orthogonal in a common usage i.e "right 
angles" per the root of the Greek word "orthos" (straight, regular, upright, 
correct, standard).

>Inheritance can be inheritance of interface and/or inheritance of
>implementation.  Interface inheritance means inheriting visibility
>information.
>
>Orthogonal means that anything achieved using one technique cannot
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>be achieved using the other.  But specifying implementation (ie.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the client relationship) can be accomplished by inheritance, so I'm
>not clear on how these are orthogonal.  (Perhaps I'm mistaken about
>what "orthogonal" means?  I'm going on recollections of a book I
>read a while back.)

  I just now went back to Webster's New Universal Unabridged (not quite
the OED?) but fairly long for its 2000+ pages.  Seems to me that your
definition of orthogonal is a bit restrictive.  In the context of 
Don's use it seems the word orthogonal is being used to say that the 
reason behind the functionality purpose is at "right angles" to that 
of the visibility purpose.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert S. White wrote:

:   Don seems to be using the word orthogonal in a common usage i.e "right 
:angles" per the root of the Greek word "orthos" (straight, regular, upright, 
:correct, standard).

[..]

:In the context of 
:Don's use it seems the word orthogonal is being used to say that the 
:reason behind the functionality purpose is at "right angles" to that 
:of the visibility purpose.

Yes, that's what I mean. 

Just quietly, my understanding of the word in the CS sense is gleaned solely 
from its (mis)use on Usenet. So, if I got it wrong, I can, at least, blame 
someone else. :)


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Paul says

<<(2) is an interesting possibility.  Most organisations with configuration
control have some kind of test or inspection procedure before release.
Either of these would be sufficient to enforce the existing interface.
Tests would fail with changed interfaces, and inspectors would reject
changed interfaces precisely because they will break existing software.>>

This misses the point. That is like saying, never mind we don't need CM
at all, because our integration testing will catch any errors.

You cannot rely on test and inspection to catch errors. The whole point
of high quality software production procedures, such as are enforced
by typical ISO 9000 registrations, or high CMM level organizations, is
that every element of the production process is well controlled.

If lack of proper CM has allowed interfaces to wander, then who knows
what other resultant errors have been produced.

Perhaps the real truth is that there are not many organizations using
Eiffel for large critical programs. A simple question, does anyone know
of an organization using Eiffel that is a CMM level of 3 or higher, or
which has received ISO 9000 certification (I do not mean to imply that
these are the *only* valid measures, but they are indicative.

Re: Interface/Implementation (was Re: Design by Contract)

[Matt Austern]

doylep@ecf.toronto.edu (Patrick Doyle) writes:

> Close, but IMO no cigar.  If we are faithfully to compare Ada and
> Eiffel ways of doing this, then just as an Ada package is accessed
> through its interface, so would the Eiffel class be accessed only
> through the abstract superclass.  Thus, even if the subclass
> added public features, the client couldn't use them.

Except that that's impossible.  You have to know the name of the
derived class, and the signatures of its creation functions, in order
to create objects of that class.  So the interface of the derived
class cannot be completely hidden.

(Or, alternatively, you could have a third class, a "factory" class,
that exists only to create instance of the derived implementation
class.  In that case, you could hide the derived class completely.
Even so, though, you would have to know the interfaces of at least two
classes; the abstract base class does not suffice.  And note that
Eiffel doesn't let you use this method for expanded classes or
objects.)

The bottom line: inheritance is useful for some purposes, but it is
not a panacea.  Base-derived semantics is not at all the same as
interface-implementation semantics.

Re: Interface/Implementation (was Re: Design by Contract)

[Veli-Pekka Nousiainen]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.873952419@merv>...
> Paul says
> 
> <<(2) is an interesting possibility.  Most organisations with
configuration
> control have some kind of test or inspection procedure before release.
> Either of these would be sufficient to enforce the existing interface.
> Tests would fail with changed interfaces, and inspectors would reject
> changed interfaces precisely because they will break existing software.>>
> 
> This misses the point. That is like saying, never mind we don't need CM
> at all, because our integration testing will catch any errors.
> 
> You cannot rely on test and inspection to catch errors. The whole point
> of high quality software production procedures, such as are enforced
> by typical ISO 9000 registrations, or high CMM level organizations, is
> that every element of the production process is well controlled.
> 
> If lack of proper CM has allowed interfaces to wander, then who knows
> what other resultant errors have been produced.
> 
> Perhaps the real truth is that there are not many organizations using
> Eiffel for large critical programs. A simple question, does anyone know
> of an organization using Eiffel that is a CMM level of 3 or higher, or
> which has received ISO 9000 certification (I do not mean to imply that
> these are the *only* valid measures, but they are indicative.
> 
You got me ! Please, anybody - help. More info about CM & Eiffel !!! 
For what use it is to have the best of the world - DbC 
when rest of the quality is below that !?
> 

Re: Interface/Implementation (was Re: Design by Contract)

[Nick Leaton]

Robert Dewar wrote:

> <<Ordering code bottom up a la Ada vs ordering code in any order. Does
> having the ability to freely order increase the readability of the code?
> Well I do like grouping features with a class in clusters, and
> (hopefully) being consistent between clusters. You can always order
> bottom up if you want to, but you don't have to. In other words having
> free ordering is a superset of bottom up ordering.>>
> 
> Reading some of these posts makes me wonder whether the posters have
> actually written code in Ada. Because I cannot make any sense out of
> their description of the restrictions in Ada ordering.
> 
> Nick, perhaps you could give a small example of Ada code where Ada
> forces you to write things in inconvenient order, and then we can
> better understand what you are talking about.

It looks like I got the wrong idea from some earlier postings saying
that Ada enforced some orderings. My general point is that in the past,
ordering my have been enforced for some languages to make life easier
for the compiler writer. This should now be obsolete, and you should be
allowed to put what ordering you want on your source, with the
availablity of tools to reorder and or filter the source into
appropriate forms.

I had great problems understanding a Smalltalk or Eiffel style workbench
until I used one in practice, and now find it a incredible benefit. Its
very hard to describe such a system to someone else without them using
it.


-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Patrick says

<<This seems to further diminish the value of dependency-ordered declarations.

Then we must ask, if everyone puts all the declarations at the top anyway,
why not let the computer do it for us?>>


I find this question a bit amazing. Normally I would not expect anyone
who is sufficiently familiar with the separation of spec and implementation
to ask it.

Of course the computer can derive the bare bones details about a spec, e.g.
the syntax of the subprogram declaration, from the body, but it most 
certainly cannot derive automatically appropriate high level comments that
provide the necessary information for a client to use the subprogram.

Certainly no Ada programmer would ever ask this question, the idea of
deriving specifications automatically from implementations is fundamentally
upside-down!

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don said

<<Good idea. Although I consider it a workaround, it effectively deals with
the problem. Thanks.>>

It's not AT ALL a work around. The utility of this approach is 
fundamental.

In normal good Ada practice, even though the language does not require it,
one always has separate specs for all sbprograms.


Why?

Simple, because the spec is the anchor point for the high level coments
that provide sufficient detail (but no more detail than that) for a client
to make use of the subprogram. 

Yes, you could write the comments without a copy of the subprogram
specification, but in practice, the comments will refer to the specification
so it makes excellent sense to have a copy of the spec right there.

This is not a work around, it is standard Ada style. To say it is a workaround
is like saying that in C it is a work around to have to declare int and
float separately because in mathematics they are both numbers (or choose all
sorts of other silly analogies :-)

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don Harrison says

<<Not sure who you mean when you say "we always order..", but you can't be
speaking on behalf of all Ada developers. I understand why you might have
such a preference but it's by no means common to everyone.

For those who may choose to order differently, there *is* a reason why they
may want to preserve the same ordering as the spec - consistency. If you're
familiar with the ordering in the spec, then you don't have to learn a
different ordering for the body (Yes, I know you only have to remember the
alphabet if you use alphabetic ordering; presumably, that's why you like it).>>

Sorry, I forget that we have an annoyingly cross-posted thread here :-)

We here = ACT, and the software in question is the GNAT sources. And sure,
I am just talking about our preference at ACT, we certainly do not presume
to speak for the preferences of the entire Ada community :-)

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don said

<<I think you're getting your contexts confused here. My comment was made in
the specific context of *no* prior declarations.>>

Yes, but no one writes Ada programs of any significant complexity with
no prior declarations, so your observation is about as useful as one which
notes that conditionals in Ada are awkward in the context of avoiding
the use of if statements.

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Matt Heaney wrote:

:>..  One typical coding style adopted
:>for Ada package bodies is:
:>
:>     <declarations of local subprograms>
:>
:>     <bodies for visible subprograms>
:>
:>     <bodies for local subprograms>
:>
:>Given this style, the bodies can be ordered in any way that is convenient.
:
:Funny, I didn't understand Don's comment, because I thought that everyone
:already did this.

There you go. You learn something new every day. :)

Looks like there are people out there who actually think they shouldn't have 
to repeat themselves! :)


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Nick says

<<Ordering code bottom up a la Ada vs ordering code in any order. Does
having the ability to freely order increase the readability of the code?
Well I do like grouping features with a class in clusters, and
(hopefully) being consistent between clusters. You can always order
bottom up if you want to, but you don't have to. In other words having
free ordering is a superset of bottom up ordering.>>

Reading some of these posts makes me wonder whether the posters have
actually written code in Ada. Because I cannot make any sense out of
their description of the restrictions in Ada ordering.

Nick, perhaps you could give a small example of Ada code where Ada
forces you to write things in inconvenient order, and then we can
better understand what you are talking about.

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel Mize]

Robert Dewar wrote:
> 
> Samuel Mize says
> 
> <<As several people (including Don) have pointed out, if you try to
> read an Ada unit with a lot of sub-procedures, you wind up reading
> it from the end backward.>>
> 
> Once again, I do not know what this is about.

It's about the claim that "dependency ordering" increases human
comprehension of a package or subprogram.  If we in Ada usually
defeat the default dependency ordering, for clarity, that's
hardly a stellar recommendation for its ability to increase human
comprehension.

Perhaps a better way to phrase my statement would have been:

An Ada unit -- package or subprogram -- that contains internal
declarations is read from the end backward UNLESS you use an
explicit idiom that defeats the "dependency ordering."  This is
especially true for a subprogram that contains other subprograms,
since the first code executed has to be at the end of the unit.


>I can imagine someone
> deliberately ordering a program so that it has to be read from the
> end backward, but I thankfully never encountered an Ada program
> written this way, and the suggestion that this is somehow required
> in Ada is entirely bogus.

True.  It is not required.

However, if a package contains a lot subprograms, it requires a
specific effort (pre-declaring the procedures) to enable
human-oriented rather than compiler-oriented ordering.

Sam Mize

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel T. Harris]

Robert Dewar wrote:
> 
> Samuel Mize says
> 
> <<As several people (including Don) have pointed out, if you try to
> read an Ada unit with a lot of sub-procedures, you wind up reading
> it from the end backward.>>
> 
> Once again, I do not know what this is about. I can imagine someone
> deliberately ordering a program so that it has to be read from the
> end backward, but I thankfully never encountered an Ada program
> written this way, and the suggestion that this is somehow required
> in Ada is entirely bogus.

In my world I really don't care much how an Ada package body is
ordered as far as readability is concerned. With the proliferation
of "smart" Ada browsers, editors, and preparation tools (Apex,
Emacs with the Ada stuff, ada2html for Web browsers, etc.) I judge
"readability" to be nearly insignificant. There are still
situations where code reviewers are limited (or more precisely
have limited themselves) to hard copy only but these are getting
more rare as time goes on with the explosion of intranets.
Of course, certain technical aspects of package body ordering
already identified in this thread deserve attention and I do not
mean to downplay their importance. I just want to point out that
I haven't dealt with simple ASCII text source code for years so
I'm free from the limitations of such a simple representation.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel T. Harris]

Marc Wachowitz wrote:
> 
> 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.

For Joachim's benefit, this is done via a renaming declaration for
packages, subprograms, and variables; and a subtype for types.
There are no renames declarations for types.

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

Again, to expand. It is useful to use 'use' clauses to achieve
visibility
to the operations for direct use in expressions. Conservative projects
which frown on "use" clauses in the context usually allow "use" clauses
in the limited declarative scope of subprograms and block statements.
While this does introduce multiple "use" clauses everywhere they are
needed, such a convention does limited the potential for "problems"
with global use of "use".

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <34195A46.3F08E09@hso.link.com> "Samuel T. Harris" <s_harris@hso.link.com> writes:

> For Joachim's benefit, this is done via a renaming declaration for
> packages, subprograms, and variables; and a subtype for types.
> There are no renames declarations for types.

Yes there is (though it is achieved in a not "as clear" fashion: subtype)

type T is ...

...

subtype My_New_Name_For_T is T;

/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: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

doyle says

<<>Inheritance can be inheritance of interface and/or inheritance of
>implementation.  Interface inheritance means inheriting visibility
>information.
>
>Orthogonal means that anything achieved using one technique cannot
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>be achieved using the other.  But specifying implementation (ie.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the client relationship) can be accomplished by inheritance, so I'm
>not clear on how these are orthogonal.  (Perhaps I'm mistaken about
>what "orthogonal" means?  I'm going on recollections of a book I
>read a while back.)>>


The word orthogonal came into common usage in programming languages from
the Algol-68 design, where AVW coined the use of the term to describe
features of a programming language that are essentially independent from
a semantic point of view.

The principle of orthogonality says that if two features are orthogonal,
then you can derive the semantics of the interaction of the two features
from the semantics of the individual features (much as you can derive
a position in 3 space, from independnet rules and knowledge about its
position in each separate dimension.

Words can of course mean anything you want (reference: Alice in Wonderland),
but it is usual in discussions about programming languages to adopt
AVW's usage.

Re: Interface/Implementation (was Re: Design by Contract)

[Paul Johnson]

In article <dewar.873952419@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
writes
>Paul says
>
>>is an interesting possibility.  Most organisations with configuration
>>control have some kind of test or inspection procedure before release.
>>Either of these would be sufficient to enforce the existing interface.
>>Tests would fail with changed interfaces, and inspectors would reject
>>changed interfaces precisely because they will break existing
>>software.
>
>This misses the point. That is like saying, never mind we don't need CM
>at all, because our integration testing will catch any errors.

No, I don't think it does.

>You cannot rely on test and inspection to catch errors.

I agree that automated trapping of errors is better (its one of the
reasons I like Eiffel).  I just raised the possibility that in practice
this particular catagory of error had not caused enough trouble to make
someone implement it.  The origin of this, if you recall, was that
someone had wondered why nobody was doing this.

>If lack of proper CM has allowed interfaces to wander, then who knows
>what other resultant errors have been produced.

Which is rather the point: does this lack of separate CM for interfaces
and implementation actually cause that much trouble in practice?

In another thread I was criticised for claiming that the theoretical
foundation for Eiffel exception handling made it superior to Ada
exception handling.  Now I'm being criticised for not recognising
separate interfaces as superior because they stem from another theory of
software engineering.  I agree that separate CM of interfaces is better,
but I wonder if it makes enough difference to be worth while
implementing.

Paul.

--------------------------------+---------------------------------
Paul Johnson                    | You are lost in a maze of twisty
Email: Paul@treetop.demon.co.uk | little standards, all different.
       paul.johnson@gecm.com    |

Re: Interface/Implementation (was Re: Design by Contract)

[Joachim Durchholz]

Marc Wachowitz wrote:
> 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.

Well, that's what's *never* necessary in Eiffel.
Either you inherit, then you *must* resolve name clashes by renaming (or
you can undefine one of the miscreants).
Or you use, then you *always* qualify with the entity name (not the
class name - the class is already attached to the entity, which must be
named anyway).

> 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

This is nice. If it was in the original language draft, I forgot about
it (and now I think it actually was part of the language then).

> (which
> may be local, but can also be exported by a package).

Even better. Sounds like Eiffel stole that from Ada.

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

I can understand that.

In Eiffel such a policy wouldn't be necessary. A name clash is either
accidental (then it must be resolved by renaming) or not (in which the
clashing actually refer to the same thing, which doesn't need any
resolving).

Regards,
Joachim
-- 
Please don't send unsolicited ads.

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <fxtiuw7ert4.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:

> The bottom line: inheritance is useful for some purposes, but it is
> not a panacea.  Base-derived semantics is not at all the same as
> interface-implementation semantics.

Absolutely!  And I find it rather stunning that some here can't twig
this fact (yes, this particular bit is objective fact).

/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: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <EG9wrJ.F3t@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> Ok.  I'll go for that, because my argument all along has been that
> abstract superclasses can do as much as *and more than* Ada specs.
> So let's consider just the export aspects of an abstract class.  Is
> there anything that they can't do which Ada specs can do?

Yes, _of course_ there is.  An Ada spec. can bundle and export _many_
different interfaces.  These can be abstract and/or concrete.

You're earlier remark about not saying anything more on this until
you've read up on the relevant Ada bits seems really apropos...

/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: Interface/Implementation (was Re: Design by Contract)

[Marc Wachowitz]

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>

Re: Interface/Implementation (was Re: Design by Contract)

[Joerg Rodemann]

Joachim Durchholz (joachim.durchholz@munich.netsurf.de) wrote:
> Joerg Rodemann wrote:
> > How do you prevent that the implemented class derived from an abstract
> > specification class can add public methods to those mentioned in that
> > abstract class?

> Why should I want to do that?
> (I could think of some situations where such a restriction might be
> useful, but these are rather exotic.)

> In what ways is the Ada way of doing that useful?

Because this is the essence of the spec/impl concept in languages as Ada,
Modula, the older Oberon dialects. The spec is a _complete_ specification
of everything that is exported. Well, in Ada this might be a bit obscured
by the fact that the full type and some other things have to be mentionened
in the 'private' part of the spec. But at least I understand the reason for
this decision and can life with it. On the other hand: I never understood,
why Wirth switched from the two file variant to a all-in-one solution.
Sure, it makes sense if you take into account the whole Oberon environ-
ment --- they have some really astonishing features --- but I still think
the language itself lost an important thing. (And there where lots of points
I did not like that environment also. But that's a different story.)

Well, since it was mentionened by someone else: one thing as important
as a complete spec of a package/module (perhaps class/interface) is in
my opinion a list of those things that are imported. Of course, if the
language is completely class oriented there are no name ambiguities but
I often liked to know what packages are directly relevant to a specific
package. This often gives an insight-at-a-glance what mechanisms are used.
To return to the spec issue: IMHO there should be only included those
things that are important to the spec. The body might have a much longer
'IMPORT' list.

Regards

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: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

(Sorry for not responding to you earlier. I wasn't ignoring you - just 
short on time.)

W. Wesley Groleau wrote:

:> I disagree, the short form is not code, but documentation. As such, 
:> they can't be regarded as the same thing.
:
:In Ada, a package spec is code AND documentation.  It is, in a way, 
:a contract with all clients of the package, and a precondition for
:the implementation.  

Agree. The use of "precondition" is a bit loose, however..

:However, in Eiffel, since the short form comes
:FROM the implementation, "documentation" is a good word. 

Some of us in this thread have associated Ada package specs with Eiffel short
forms. This is not strictly true. More accurate may be:

  - The human readable view of package specs is analogous to the short 
    form (hence my use of the term documentation), and

  - The software client view of package specs is analogous to the interface
    embedded in the class text, loosely called the class implementation.
    (This embedded interface is what is extracted to become the short form.)

Why bother making this distintion? Because the ability of software clients 
to use a class doesn't depend on whether a short form has been generated
but on the existence of the embedded interface. These two aspects of clientship 
which are combined in Ada are separated in Eiffel. 

Further, considering that an Eiffel class designer establishes the client 
aspects of a class first (conceiving the (embedded) interface), and then 
proceeds to implement it (probably first in stubbed form), we see that rather 
than the interface trailing the implementation, it precedes it, as in Ada.

Consequently, I disagree with John Volan's observation..

:.. Eiffel treats the notion of
:an "interface-only view of a class which describes its contract" as
:something of an afterthought.


Due to the fact that the short form is always generated from the class text,
there is a slight advantage in this approach:

  - The system is always executable, even if only with stubbed bodies. 
    Yes, I know you can generate such stubs with Ada tools, but..

  - Humans can generate more meaningful stubs, returning sensible default 
    values - zero rather than Integer'First, for example.


:In Ada, since the specification conceptually precedes and constrains the
:implementation, the word we've chosen--specification--is more 
:precise than the broader "documentation."

Strictly speaking, you could say Eiffel short forms *document* the 
specification - they are not the specification itself. The specification
is embedded in the class text and that's what is used by the compiler.

This is why I think it's important for an Eiffel environment to be able to 
freeze that embedded specification. As any Ada programmer knows, this is 
crucial in a team environment.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <dewar.874081443@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Patrick says
>
><<This seems to further diminish the value of dependency-ordered declarations.
>
>Then we must ask, if everyone puts all the declarations at the top anyway,
>why not let the computer do it for us?>>
>
>
>I find this question a bit amazing. Normally I would not expect anyone
>who is sufficiently familiar with the separation of spec and implementation
>to ask it.

It seems these subtle personal comments are getting more and more
common, especially in this thread.  Can't we just stick to the issues
without expressing our amazement at others' lack of experience?

>Of course the computer can derive the bare bones details about a spec, e.g.
>the syntax of the subprogram declaration, from the body, but it most 
>certainly cannot derive automatically appropriate high level comments that
>provide the necessary information for a client to use the subprogram.

The comments in Eiffel are written in such a way that the tools can
extract the interface comments automatically.

>Certainly no Ada programmer would ever ask this question

Objection!  Hearsay!

>the idea of
>deriving specifications automatically from implementations is fundamentally
>upside-down!

I'm not suggesting that we *derive* one from the other, just that we can
write them together, and *extract* one from the other.  I agree that
the former is backward.

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Tucker Taft]

Samuel Mize (smize@link.com) wrote:

: ...
: It's about the claim that "dependency ordering" increases human
: comprehension of a package or subprogram.  If we in Ada usually
: defeat the default dependency ordering, for clarity, that's
: hardly a stellar recommendation for its ability to increase human
: comprehension.

Putting in a separate spec is not "defeating" anything.  
Either the spec or the body of a subprogram must precede any 
use of it in Ada (and Pascal and Modula and C++ and ...).  For both the 
human and the compiler's point of view, just the spec is all you need.  
It is only if you are too lazy to write both a spec and a body that 
you push the reader into "backwards" reading.

The point of this "dependency ordering" is that *declarations* precede
use, so the reader and the compiler know the meaning of what they are reading,
in advance of reading it.  There is no need for bodies to precede use, 
and in fact, you and others have pointed out that always trying to 
have bodies precede use is 1) awkward to read, and 2) impossible in 
the presence of recursion.

: ...
: Sam Mize

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <JSA.97Sep11211209@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>
>In article <EG9wrJ.F3t@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> Ok.  I'll go for that, because my argument all along has been that
>> abstract superclasses can do as much as *and more than* Ada specs.
>> So let's consider just the export aspects of an abstract class.  Is
>> there anything that they can't do which Ada specs can do?
>
>Yes, _of course_ there is.  An Ada spec. can bundle and export _many_
>different interfaces.  These can be abstract and/or concrete.

An abstract class could have some concrete features.  Is that
similar?

>You're earlier remark about not saying anything more on this until
>you've read up on the relevant Ada bits seems really apropos...

You're right that I should be more experienced with Ada, but I'll
have to disappoint you on the "not saying anything more" front. :-)

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <5v7mhr$meo$2@flood.weeg.uiowa.edu>,
Robert S. White <nospam@somewhere.ia.us> wrote:
>In article <EG9wrJ.F3t@ecf.toronto.edu>, doylep@ecf.toronto.edu says...
>>
>>Orthogonal means that anything achieved using one technique cannot
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>be achieved using the other.  But specifying implementation (ie.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>the client relationship) can be accomplished by inheritance, so I'm
>>not clear on how these are orthogonal.  (Perhaps I'm mistaken about
>>what "orthogonal" means?  I'm going on recollections of a book I
>>read a while back.)
>
>  I just now went back to Webster's New Universal Unabridged (not quite
>the OED?) but fairly long for its 2000+ pages.  Seems to me that your
>definition of orthogonal is a bit restrictive.  In the context of 
>Don's use it seems the word orthogonal is being used to say that the 
>reason behind the functionality purpose is at "right angles" to that 
>of the visibility purpose.

  You must admit that this "right-angles" definition can't be applied
literally to programming languages.  It makes the definition very
vague and subject to interpretation.

  So let's look for an analogy.  In mathematics, two vectors are
orthogonal if their scalar product is zero.  It's not enough that
they're linearly independent.  Any n linearly independent vectors
will span n-space, but that doesn't make them orthogonal.

  Likewise, simply because every desirable objective can be expressed
as a combination of two (or more) features doesn't make them orthogonal.
That just makes them linearly independent.  To be orthogonal, as you
say, implies that they're at "right angles", so that they go in two
unrelated directions.  

  With vectors, if we want to move in the direction of one vector,
it will not help to move in the direction of an orthogonal vector.
It will not progress you whatsoever in the direction you desire.
Likewise, using one feature of a language should not take you in the
"direction" of an orthogonal language feature.

  So in summary, it's not enough that the entire "program space"
can be spanned by a set of features--that just makes them linearly
independent.  It's necessary that these features go in unrelated
directions, so that one cannot accomplish what another can.

  Also, I just remembered where I read this definition.  It was in
Object-Oriented Type Systems, by Palsberg and Schwartzbach.  So
I'm not alone in this.  :-)

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Patrick Doyle]

In article <fxtiuw7ert4.fsf@isolde.mti.sgi.com>,
Matt Austern  <austern@isolde.mti.sgi.com> wrote:
>
>doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> Close, but IMO no cigar.  If we are faithfully to compare Ada and
>> Eiffel ways of doing this, then just as an Ada package is accessed
>> through its interface, so would the Eiffel class be accessed only
>> through the abstract superclass.  Thus, even if the subclass
>> added public features, the client couldn't use them.
>
>Except that that's impossible.  You have to know the name of the
>derived class, and the signatures of its creation functions, in order
>to create objects of that class.  So the interface of the derived
>class cannot be completely hidden.

Right, we can't create an object without using its creation features.
Beyond that, we can go through the abstract interface.

The trouble is, I don't know if what I just said makes sense, because
I can't imagine a reason to want to restrict interface extension.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Interface/Implementation (was Re: Design by Contract)

[Ken Garlington]

Paul Johnson wrote:
> 
> Which is rather the point: does this lack of separate CM for interfaces
> and implementation actually cause that much trouble in practice?

Certainly, poor CM for interface definitions is one of the primary
historical reasons for problems in the integration of large systems.
I can think of at least one specific example on my last project, where
two
organizations built to different versions of an interface specification,
and caused a problem that was not detected until the final system
integration. The resulting rework was expensive in both finances and
time.

> In another thread I was criticised for claiming that the theoretical
> foundation for Eiffel exception handling made it superior to Ada
> exception handling.  Now I'm being criticised for not recognising
> separate interfaces as superior because they stem from another theory of
> software engineering.  I agree that separate CM of interfaces is better,
> but I wonder if it makes enough difference to be worth while
> implementing.

I think there is sufficient practical experience that this is much
more than a theory.

> 
> Paul.
> 
> --------------------------------+---------------------------------
> Paul Johnson                    | You are lost in a maze of twisty
> Email: Paul@treetop.demon.co.uk | little standards, all different.
>        paul.johnson@gecm.com    |

Re: Interface/Implementation (was Re: Design by Contract)

[W. Wesley Groleau x4923]

>    So Ada imposes dependency ordering that makes people list their
>    subprograms bottom-up, but everybody defeats this by means of
>    forward declarations and lists things top-down because everybody
>    knows that's the more natural way to read a program.  Does anyone
>    see an element of the bizarre in this?

No, for some personalities, the more "natural" is read the
implementation of a low-level operation, mentally synthesize it 
into an understanding of the operation, and then you can understand 
it when you later see a call to it.

For other people, the more "natural" is read the high-level
description, and understand (sort of), the low-level operations by
the context of their calls.

A compiler tends to be more like the former than the latter.
Also, the latter can be 'fooled' by wierd subprogram names.
The former can be confused by poor partitioning.

For more on such personality differences, read "Type Talk" 
by (I think) Otto Kroeger or "The Way They Learn" by Cynthia Tobias.
(Or get really erudite and read "The Manual" by Meyers & Briggs)

-- 
----------------------------------------------------------------------
    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: Interface/Implementation (was Re: Design by Contract)

[Marc Wachowitz]

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>

Re: Interface/Implementation (was Re: Design by Contract)

[Owen Fellows]

Marc Wachowitz wrote:

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

Originally I had this view too. But after some heavy use of Eiffel, and
some 
thinking about the problem I have come to the conclusion that it isn't a
problem.

The solution would be to have an extra section that is implemented in
the same
was as 'inherit'. If we call it 'use', then if you wanted access to
mathematical
functions such as sin, cosine then you would 'use' mathematician.
Internally
there would be no difference in implementation. By default the 'use'd
class
would be exported to {NONE}.

This prevents someone have a class A that 'use's MATHEMATICIAN using an
instance
of a to get access to sin, cosine etc.

eg.

	a.sin (10)

But it it more likely that you just inherit MATHEMATICIAN somewhere in
your
heirarchy to save on typing.

You can prevent the above with just inheriting by exporting to {NONE},
but I
have found in practice that this isn't a problem as if you don't have
access
to sin without using the form in the example, people just inherit
MATHEMATICIAN.

So, my argument would be what do you gain my adding something like
'uses'?
Not much.

What do you lose by not having it?
Not a lot.

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

Most people have a problem with this because of the inheirtance
corresponds to 
is-a.

In practice we have marked which classes are used for facility
inheritance by
choosing names for the classes that make sense, and by placing them at
the end
of the inheritance clause.

nickle@calfp.co.uk

Nick, via Owen Fellows account

Re: Interface/Implementation (was Re: Design by Contract)

[Samuel T. Harris]

Jon S Anthony wrote:
> 
> In article <34195A46.3F08E09@hso.link.com> "Samuel T. Harris" <s_harris@hso.link.com> writes:
> 
> > For Joachim's benefit, this is done via a renaming declaration for
> > packages, subprograms, and variables; and a subtype for types.
> > There are no renames declarations for types.
> 
> Yes there is (though it is achieved in a not "as clear" fashion: subtype)
> 
> type T is ...
> 
> ...
> 
> subtype My_New_Name_For_T is T;
> 

Excuse me!
I believe I SAID subtypes for types.
And subtype is NOT a renaming declaration.
The semantics of the two are very different.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Patrick Doyle wrote:

:In article <EG9y0E.C65@syd.csa.com.au>,
:Don Harrison <nospam@thanks.com.au> wrote:
:>
:>Matthew Heaney wrote:
:>
:>:This is not unlike saying that "strong typing"  is a helpful limitation,
:>:but a limitation nonetheless.  
:>
:>I think this is a poor analogy. While strong typing delivers some obvious 
:>benefits, I don't think the same can be said of forced dependency ordering.
:
:I think it's a fine analogy, and it's true.  It *is* a helpful limitation.

If you say so. That's not my experience.

Frankly, if I were to have forced dependency ordering inflicted on me but
could choose which scheme, I would choose *reverse* dependency ordering. 
At least then I could read listings in a sensible order - from high-level to 
low-level.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Frederic Guerin]

Robert Dewar wrote:

[ discussing about the possibility of declaring variables after using them ... ]

> 
>    int A;
>    ...
>    begin
>       int B := A * 2;
>       ...
> 
> You will almost always just assume that the A is a backward reference to
> the declaration that preceded this. In the rare case where in fact there
> is another A ahead of you, you will risk making a significant mistake in
> understanding.

For sure this would be very difficult to track down. I don't know Algol 68 
but I suppose it won't allow you to refer to a forwardly declared variable 
inside a C++ like block of sequentially executable code. Most likely it will not 
permit to redefine the same name at the same level as well. So the only case
left is something like this ( using Pascal-like ):

var A : integer; 

procedure f();
    procedure g();
    begin
	DoSomethingWith(A);	(* conterintuitive reference to forward A *)
    end;				
    var A : integer;	
begin
   ...
end;

...	

The question is : Even if the language permit such a thing, will programmers
really kill themselves often enough with the added liberty/flexibility ??

> Linear comprehension is a very important capability. All text books have
> indexes, which are of course functionally similar to hypretext links, but
> we do not say "never mind about presenting things in a logical order,
> building on what you have already presented, if you reference something
> ahead, people can just look it up in the index". Instead we expend a lot
> of effort to present things in a linear order (and indeed software for
> computing partial orderings of topics to create appropriate linear orderings
> is a standard part of the toolset for educators).

> Robert Dewar
> Ada Core Technologies

There are many *logical* possible orders in which to declare actors 
( actor stands for function/variable/constant/etc. )

(1) Sequential: actor must be declared before beeing used.

    This is what you advocate and it has many advantages. 
    Among which the pitfall previously revealed may not appear.
    Another involve unexpected recursivity, which may even be worst.

    But sometimes it is just not the optimal intuitive way to present things.
    This way to present things is almost necessarily bottom-up, starting with
    details and reaching the general functions at the end of the sequence.

    Many people prefer to understand things from the general to the details.
    Thus this other possible order.
	
(2) Sequential reversed: actor are defined after beeing used. 	
    
    But if this is enforced, it may be worst. For example, it is relatively
    easy to avoid the previous wrong-variable-referencing pitfall if variables
    are alway declared before function and procedure. Thus a sort of mixed
    paradigm seems to be the most appropriate.

(3) Mixed: Actors are grouped according to some logic.

    For exemple as hinted before variable+constant then procedure+function.
    Another example, from C++. In classes first public members, then private members.
    Each group possible subgrouped in constructors/destructors, accessors, operators,
    core-functions, attributes, etc.	     	  	
    Some others simply prefers to put the functions in alphabetical orders to
    facilitate short ranged search by mean of Page-Up Page-Down. Also, if no
    tools may help and the huge piece of code is in a book, then alphabetical
    order is almost a necessity.
    Back to an as old as the historic world technique :-). 

Just some thinking of mine,

Frederic Guerin

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert Dewar wrote:

:Don said
:
:<<I think you're getting your contexts confused here. My comment was made in
:the specific context of *no* prior declarations.>>
:
:Yes, but no one writes Ada programs of any significant complexity with
:no prior declarations, so your observation is about as useful as one which
:notes that conditionals in Ada are awkward in the context of avoiding
:the use of if statements.

Not quite. Unlike if-statements, you can actually *do without* prior 
declarations. So, the analogy is a spurious one.

(Perhaps we'll hear from someone claiming they can get by with just 
case-statements! :)


It would be interesting to study the use of analogies in Usenet discussions.
My casual observation is that they're often used to "refute" opponents' 
arguments when the user has exhausted all genuine arguments of their own.
Non-analogous analogies then fit the bill admirably by falsely associating 
the opposing position with the ridiculous.

Present company excepted, of course. :)


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert Dewar wrote:

:This is not a work around, it is standard Ada style. To say it is a workaround
:is like saying that in C it is a work around to have to declare int and
:float separately because in mathematics they are both numbers (or choose all
:sorts of other silly analogies :-)
                ^^^^^^^^^^^^^^^

I'm glad *you* said it!  :)


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Brian Rogoff]

On Sat, 13 Sep 1997, Patrick Doyle wrote:
> In article <JSA.97Sep11211209@alexandria.organon.com>,
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
> >
> >In article <EG9wrJ.F3t@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
> >
> >> Ok.  I'll go for that, because my argument all along has been that
> >> abstract superclasses can do as much as *and more than* Ada specs.
> >> So let's consider just the export aspects of an abstract class.  Is
> >> there anything that they can't do which Ada specs can do?
> >
> >Yes, _of course_ there is.  An Ada spec. can bundle and export _many_
> >different interfaces.  These can be abstract and/or concrete.
> 
> An abstract class could have some concrete features.  Is that
> similar?

No. I don't want to second-guess Jon, but one of the things you can do in 
Ada is have a (generic package) spec with no body. Read the Ada Rationale, 
in particular 12.6, for examples. After you understand this, we can discuss 
the similarities and differences between package specs and abstract classes 
at a higher level.

> You're right that I should be more experienced with Ada, but I'll
> have to disappoint you on the "not saying anything more" front. :-)

That's fine, just don't expect anyone to take what you are saying seriously 
until you've read the (easily and freely available) description of Ada 95. 
BTW, where is the free version of OOSC II that I can peruse for these 
discussions? ;-).

-- Brian

Re: Interface/Implementation (was Re: Design by Contract)

[Owen Fellows]

Marc Wachowitz wrote:
> 
> 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. 

Well, in practice I haven't found this to be a problem at all. This is
in a 800,000 line
project. Lots of names are the same in different classes, like the use
of
consistent names in the standard libraries (extend, remove etc ...)
This is a strong indication that such name clashes if they happen, are
rare events.

Visibility in all children. This can be an issue but not as much as you
think. 
It is usually indicative of having an implementation at the high level
of a heirarchy
and you should, in my opinion, use facility inheritance lower down where
necessary.
Now other Eiffel programmers would disagree with me, and use facility
inheritance at
the top of the heirarchy, as there is less typing.

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

Minimal coupling is important. But from practical experience, classes we
have
written that are used for facility inheritance tend to be very stable,
don't
have name changes (implementation varies), and are usually only
extended.
Think about the MATHEMATICIAN for an example. The clashes don't happen
any
where near the level that one may presume they would happen if you
haven't
written systems in practice.

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

Agreed, there is no is-a relationship! But is is-a the only valid use or 
description of inheritance. Read the chapter in OOSC II on the taxonomy
of
inheritance. BM writes better and clearer than I do.

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

Which is always an choice that you can make as an programmer, you are
not
forced to use the inheritance for facility inheritance, you can always
do this

feature {NONE}  -- Don't allow clients access

	Math: expanded MATHEMATICIAN -- A valid use of expanded

or


feature {NONE}  -- Don't allow clients access

	Math: MATHEMATICIAN is
	   once
              !!Result.make
           end

If MATHEMATICIAN requires some form of initialisation. 
You don't pollute name space then. Eiffel gives you the choice.

At the end of the day, with things like loops, you want to have
loops because it makes reading the code easier. The code ends up closer
to the logical view of the world, not its phsical implementation.

This was the major argument in my book for the implementation of
'precursor'.
Why should you be telling the compiler how to implement something using
double inheritance, when the compiler can do it for you, and the results
are more readable.

Now in the case of facility inheritance. You don't have to use that
method,
you can get exactly what you want (see above) meeting your criteria for
visibility and name spaces. Therefor, I don't think you need extend the 
language.

I would say that 8 months ago I had the same opinions as you have
expressed,
but I've changed my mind.

Nick (From Owen's account)

Re: Interface/Implementation (was Re: Design by Contract)

[Jon S Anthony]

In article <341D712A.64729C4F@hso.link.com> "Samuel T. Harris" <s_harris@hso.link.com> writes:

> Jon S Anthony wrote:
> > 
> > In article <34195A46.3F08E09@hso.link.com> "Samuel T. Harris" <s_harris@hso.link.com> writes:
> > 
> > > For Joachim's benefit, this is done via a renaming declaration for
> > > packages, subprograms, and variables; and a subtype for types.
> > > There are no renames declarations for types.
> > 
> > Yes there is (though it is achieved in a not "as clear" fashion: subtype)
> > 
> ...
> Excuse me!
> I believe I SAID subtypes for types.
> And subtype is NOT a renaming declaration.
> The semantics of the two are very different.

Ooops.  Might help if I learned how to read...

/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: Interface/Implementation (was Re: Design by Contract)

[Don Harrison]

Robert Dewar wrote:

:Samuel Mize says
:
:<<As several people (including Don) have pointed out, if you try to
:read an Ada unit with a lot of sub-procedures, you wind up reading
:it from the end backward.>>
:
:Once again, I do not know what this is about. I can imagine someone
:deliberately ordering a program so that it has to be read from the
:end backward, but I thankfully never encountered an Ada program
:written this way, and the suggestion that this is somehow required
:in Ada is entirely bogus.

Nonsense! It's dictated by the language unless you specifically *override*
it by providing redundant information.


Tucker Taft wrote:

:It is only if you are too lazy to write both a spec and a body that 
:you push the reader into "backwards" reading.

It's only laziness to the extent that the developer has to waste time and 
effort providing and maintaining redundant information. In my book, that's 
*justifiable* laziness.

IMO, its rarely the "right" thing to compromise uniqueness even if consistency 
between the two is guaranteed by the compiler, as it is here. On rare 
occasions, it's hard to avoid duplicating information but this isn't one of 
them, IMHO.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don said

<<Not quite. Unlike if-statements, you can actually *do without* prior
declarations. So, the analogy is a spurious one.

(Perhaps we'll hear from someone claiming they can get by with just
case-statements! :)>>


No you can't, you lose critical functionality if you do not have prior
declarations, namely the capability of mutual recursion. 

And in actual practice, the likelihood of finding Ada written without
prior declarations is NOT in fact any greater than that of finding
Ada with no if statements. I don't know if you have written Ada or not,
if you have, and have really tried to write without prior declarations,
then all I can say is that your style is

(a) peculiar
(b) undesirable
(c) dissimilar to any other Ada code I have seen

I would make the same statement about lack of if statements ( it is of
COURSE possible to use case statements everywhere instead of if statements,
but no one would do it, to me it is a perfect analogy).

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don said

<<:This is not a work around, it is standard Ada style. To say it is a workaround
:is like saying that in C it is a work around to have to declare int and
:float separately because in mathematics they are both numbers (or choose all
:sorts of other silly analogies :-)
                ^^^^^^^^^^^^^^^

I'm glad *you* said it!  :)>>


Um Don, I think you misparsed what I said here. My silly analogy, I meant
analogies that are accurate and equally as silly as the original! So if
you are glad I said it fine, but I hope you understand the sense, and
agree that the original was silly!

Re: Interface/Implementation (was Re: Design by Contract)

[Shmuel (Seymour J.) Metz]

Robert Dewar wrote:
> 
> Don said
> 
> <<Frankly, if I were to have forced dependency ordering inflicted on me but
> could choose which scheme, I would choose *reverse* dependency ordering.
> At least then I could read listings in a sensible order - from high-level to
> low-level.>>
> 
> Can you clarify your experience with Ada here. it is sounding more and more
> as though you are talking from imagination rather than experience.

Although I find the ordering requirements in Ada to be a nuisance, I
have to
agree with you that the specifications should be done before the body.
In all
of the Ada that I wrote, the specifications had to pass a design review
before we
were allowed to start writing the body, and everything that I saw
convinced me
that not only was the requiring reasonable but that it was necessary.

In an earlier article you drew an anology with reading a book. Well, I
read
novels in a linear fashion, but I skip around in text books. In
particular,
technical literature frequently refers the reader to an appendix for
details. I 
believe that most people read code the same way: the choice of what to
read and 
in what order depends on what they are attempting to learn.

In language with an arbitrary declaration order, I find the declarations
at the 
end more often than the beginning. In some cases the code is more
readable if the 
declarations are split. The acid test is to throw it at someone who's
never seen
it before and see if he has trouble understanding it.

I can't comment on Eiffel, but I definitely consider Ada to be more
readable and
maintainable than C, Pascal or FORTRAN.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don said

<<Nonsense! It's dictated by the language unless you specifically *override*
it by providing redundant information.>>


Now it really becomes clear that you are unfamiliar with Ada if you
regard speecifications as "redundant information",

I recommend familiarizing yourself more with Ada, and typical Ada code,
then you will see why your comments on this subject are irrelevant.

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Don said

<<Frankly, if I were to have forced dependency ordering inflicted on me but
could choose which scheme, I would choose *reverse* dependency ordering.
At least then I could read listings in a sensible order - from high-level to
low-level.>>

Can you clarify your experience with Ada here. it is sounding more and more
as though you are talking from imagination rather than experience.

Re: Interface/Implementation (was Re: Design by Contract)

[Robert Dewar]

Shmuel said

<<Although I find the ordering requirements in Ada to be a nuisance, I
have to
agree with you that the specifications should be done before the body.
In all
of the Ada that I wrote, the specifications had to pass a design review
before we
were allowed to start writing the body, and everything that I saw
convinced me
that not only was the requiring reasonable but that it was necessary.>>

(can you keep lines under 80 chars, makes things a lot more readable in
many environments)

I don't understand the above. If you agree that it is reasonable to always
require specs, then how do you find the ordering requirements in Ada a
nuisance. Please give an example. if you are talking about the basic vs
later ordering rules in Ada 83, just clarify that this is what you are
talking about, because we all agree on that, and it has been fixed for
years in Ada 95.

Re: Interface/Implementation (was Re: Design by Contract)

[Bill Foote]

In article <341D4AC2.8470493F@calfp.co.uk>,
Owen Fellows  <ofellows@calfp.co.uk> wrote:
(On the subject of Eiffel's use of inheritance to get functions like
sin, cos, etc.)
>
>So, my argument would be what do you gain my adding something like
>'uses'?
>Not much.
>
>What do you lose by not having it?
>Not a lot.

IMHO you lose clarity, self-documentation, and potential tool support.

When I was using Eiffel, I found the nest of things that I saw in the
inheritance tree while browsing confusing -- I would much rather have
inheritance restricted to "isa" relationships, and something else for
importing facilities (like constants and "global" methods).

Inheritance for isa is semantically different from this kind of implementation
inheritance; I think that explicitly recognizing this with a language
construct is a Good Thing.

But this is a minor point -- IMHO there's a *lot* more to like in Eiffel
than there is to dislike!

Regards,
-- 
Bill Foote				bill.foote@eng.sun.com
HotJava Developer, JavaSoft		http://java.sun.com/people/billf/