* Re: Interface/Implementation (was Re: Design by Contract) [not found] <01bcb389$24f579d0$1c10d30a@ntwneil> @ 1997-08-28 0:00 ` Tucker Taft 1997-08-29 0:00 ` Paul Johnson 1997-09-01 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 2 replies; 185+ messages in thread From: Tucker Taft @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Interface/Implementation (was Re: Design by Contract) Tucker Taft @ 1997-08-29 0:00 ` Paul Johnson 1997-08-29 0:00 ` Jon S Anthony 1997-09-01 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1 sibling, 1 reply; 185+ messages in thread From: Paul Johnson @ 1997-08-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-29 0:00 ` Paul Johnson @ 1997-08-29 0:00 ` Jon S Anthony [not found] ` <EFqDC8.342@ecf.toronto.edu> 0 siblings, 1 reply; 185+ messages in thread From: Jon S Anthony @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <EFqDC8.342@ecf.toronto.edu>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFqDC8.342@ecf.toronto.edu> @ 1997-09-02 0:00 ` Samuel Mize 1997-09-03 0:00 ` Paul Johnson ` (4 more replies) 0 siblings, 5 replies; 185+ messages in thread From: Samuel Mize @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Samuel Mize @ 1997-09-03 0:00 ` Paul Johnson 1997-09-03 0:00 ` Patrick Doyle ` (3 subsequent siblings) 4 siblings, 0 replies; 185+ messages in thread From: Paul Johnson @ 1997-09-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Samuel Mize 1997-09-03 0:00 ` Paul Johnson @ 1997-09-03 0:00 ` Patrick Doyle 1997-09-03 0:00 ` Samuel Mize [not found] ` <EFyrH2.7z2@syd.csa.com.au> ` (2 subsequent siblings) 4 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-03 0:00 ` Patrick Doyle @ 1997-09-03 0:00 ` Samuel Mize 0 siblings, 0 replies; 185+ messages in thread From: Samuel Mize @ 1997-09-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <EFyrH2.7z2@syd.csa.com.au>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFyrH2.7z2@syd.csa.com.au> @ 1997-09-04 0:00 ` Joerg Rodemann 1997-09-05 0:00 ` Don Harrison 1997-09-06 0:00 ` Joachim Durchholz 1997-09-04 0:00 ` W. Wesley Groleau x4923 ` (2 subsequent siblings) 3 siblings, 2 replies; 185+ messages in thread From: Joerg Rodemann @ 1997-09-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` Joerg Rodemann @ 1997-09-05 0:00 ` Don Harrison [not found] ` <340fdb9f.0@news.uni-ulm.de> 1997-09-06 0:00 ` Joachim Durchholz 1 sibling, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <340fdb9f.0@news.uni-ulm.de>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <340fdb9f.0@news.uni-ulm.de> @ 1997-09-06 0:00 ` Joachim Durchholz 0 siblings, 0 replies; 185+ messages in thread From: Joachim Durchholz @ 1997-09-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` Joerg Rodemann 1997-09-05 0:00 ` Don Harrison @ 1997-09-06 0:00 ` Joachim Durchholz 1 sibling, 0 replies; 185+ messages in thread From: Joachim Durchholz @ 1997-09-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFyrH2.7z2@syd.csa.com.au> 1997-09-04 0:00 ` Joerg Rodemann @ 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Don Harrison ` (2 more replies) 1997-09-05 0:00 ` Matthew Heaney 1997-09-07 0:00 ` Robert Dewar 3 siblings, 3 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-04 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 @ 1997-09-05 0:00 ` Don Harrison 1997-09-05 0:00 ` W. Wesley Groleau x4923 ` (3 more replies) 1997-09-05 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Patrick Doyle 2 siblings, 4 replies; 185+ messages in thread From: Don Harrison @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Don Harrison @ 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Joachim Durchholz 1997-09-09 0:00 ` Robert Dewar 1997-09-05 0:00 ` Jon S Anthony ` (2 subsequent siblings) 3 siblings, 2 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-05 0:00 UTC (permalink / raw) > :> 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` W. Wesley Groleau x4923 @ 1997-09-06 0:00 ` Joachim Durchholz 1997-09-09 0:00 ` Robert Dewar 1 sibling, 0 replies; 185+ messages in thread From: Joachim Durchholz @ 1997-09-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Joachim Durchholz @ 1997-09-09 0:00 ` Robert Dewar 1997-09-09 0:00 ` Richard Kenner 1997-09-10 0:00 ` Tucker Taft 1 sibling, 2 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-09 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Robert Dewar @ 1997-09-09 0:00 ` Richard Kenner 1997-09-10 0:00 ` Tucker Taft 1 sibling, 0 replies; 185+ messages in thread From: Richard Kenner @ 1997-09-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Robert Dewar 1997-09-09 0:00 ` Richard Kenner @ 1997-09-10 0:00 ` Tucker Taft 1997-09-10 0:00 ` One pass compilation? W. Wesley Groleau x4923 ` (3 more replies) 1 sibling, 4 replies; 185+ messages in thread From: Tucker Taft @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: One pass compilation? 1997-09-10 0:00 ` Tucker Taft @ 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Interface/Implementation (was Re: Design by Contract) Joachim Durchholz ` (2 subsequent siblings) 3 siblings, 0 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-10 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Tucker Taft 1997-09-10 0:00 ` One pass compilation? W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Joachim Durchholz 1997-09-10 0:00 ` Nick Leaton 1997-09-11 0:00 ` Robert Dewar 3 siblings, 0 replies; 185+ messages in thread From: Joachim Durchholz @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Tucker Taft 1997-09-10 0:00 ` One pass compilation? W. Wesley Groleau x4923 1997-09-10 0:00 ` Interface/Implementation (was Re: Design by Contract) Joachim Durchholz @ 1997-09-10 0:00 ` Nick Leaton 1997-09-10 0:00 ` W. Wesley Groleau x4923 ` (2 more replies) 1997-09-11 0:00 ` Robert Dewar 3 siblings, 3 replies; 185+ messages in thread From: Nick Leaton @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Nick Leaton @ 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-11 0:00 ` Code ordering Steve Furlong 1997-09-12 0:00 ` Interface/Implementation (was Re: Design by Contract) Robert Dewar 2 siblings, 0 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-10 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Code ordering 1997-09-10 0:00 ` Nick Leaton 1997-09-10 0:00 ` W. Wesley Groleau x4923 @ 1997-09-11 0:00 ` Steve Furlong 1997-09-12 0:00 ` Interface/Implementation (was Re: Design by Contract) Robert Dewar 2 siblings, 0 replies; 185+ messages in thread From: Steve Furlong @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Nick Leaton 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-11 0:00 ` Code ordering Steve Furlong @ 1997-09-12 0:00 ` Robert Dewar 1997-09-12 0:00 ` Nick Leaton 2 siblings, 1 reply; 185+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Interface/Implementation (was Re: Design by Contract) Robert Dewar @ 1997-09-12 0:00 ` Nick Leaton 0 siblings, 0 replies; 185+ messages in thread From: Nick Leaton @ 1997-09-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Tucker Taft ` (2 preceding siblings ...) 1997-09-10 0:00 ` Nick Leaton @ 1997-09-11 0:00 ` Robert Dewar 3 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Don Harrison 1997-09-05 0:00 ` W. Wesley Groleau x4923 @ 1997-09-05 0:00 ` Jon S Anthony 1997-09-06 0:00 ` Fergus Henderson 1997-09-08 0:00 ` Robert Dewar 1997-09-08 0:00 ` Robert Dewar 3 siblings, 1 reply; 185+ messages in thread From: Jon S Anthony @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Jon S Anthony @ 1997-09-06 0:00 ` Fergus Henderson 1997-09-06 0:00 ` Jon S Anthony 0 siblings, 1 reply; 185+ messages in thread From: Fergus Henderson @ 1997-09-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-06 0:00 ` Fergus Henderson @ 1997-09-06 0:00 ` Jon S Anthony 0 siblings, 0 replies; 185+ messages in thread From: Jon S Anthony @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Don Harrison 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Jon S Anthony @ 1997-09-08 0:00 ` Robert Dewar 1997-09-11 0:00 ` Don Harrison 1997-09-08 0:00 ` Robert Dewar 3 siblings, 1 reply; 185+ messages in thread From: Robert Dewar @ 1997-09-08 0:00 UTC (permalink / raw) <<: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! ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` Robert Dewar @ 1997-09-11 0:00 ` Don Harrison 0 siblings, 0 replies; 185+ messages in thread From: Don Harrison @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Don Harrison ` (2 preceding siblings ...) 1997-09-08 0:00 ` Robert Dewar @ 1997-09-08 0:00 ` Robert Dewar 1997-09-11 0:00 ` Don Harrison 3 siblings, 1 reply; 185+ messages in thread From: Robert Dewar @ 1997-09-08 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` Robert Dewar @ 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Don Harrison @ 1997-09-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Don Harrison @ 1997-09-05 0:00 ` Jon S Anthony 1997-09-06 0:00 ` Patrick Doyle 1997-09-05 0:00 ` Patrick Doyle 2 siblings, 1 reply; 185+ messages in thread From: Jon S Anthony @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Jon S Anthony @ 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Jon S Anthony 0 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-06 0:00 ` Patrick Doyle @ 1997-09-06 0:00 ` Jon S Anthony 0 siblings, 0 replies; 185+ messages in thread From: Jon S Anthony @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Don Harrison 1997-09-05 0:00 ` Jon S Anthony @ 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` W. Wesley Groleau x4923 2 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Patrick Doyle 0 siblings, 1 reply; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-05 0:00 UTC (permalink / raw) > >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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` W. Wesley Groleau x4923 @ 1997-09-06 0:00 ` Patrick Doyle 0 siblings, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFyrH2.7z2@syd.csa.com.au> 1997-09-04 0:00 ` Joerg Rodemann 1997-09-04 0:00 ` W. Wesley Groleau x4923 @ 1997-09-05 0:00 ` Matthew Heaney 1997-09-06 0:00 ` Joachim Durchholz ` (4 more replies) 1997-09-07 0:00 ` Robert Dewar 3 siblings, 5 replies; 185+ messages in thread From: Matthew Heaney @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Matthew Heaney @ 1997-09-06 0:00 ` Joachim Durchholz 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) ` (3 subsequent siblings) 4 siblings, 0 replies; 185+ messages in thread From: Joachim Durchholz @ 1997-09-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Matthew Heaney 1997-09-06 0:00 ` Joachim Durchholz @ 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-06 0:00 ` Jon S Anthony 1997-09-06 0:00 ` Patrick Doyle ` (2 subsequent siblings) 4 siblings, 1 reply; 185+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-06 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-06 0:00 ` Jon S Anthony 0 siblings, 0 replies; 185+ messages in thread From: Jon S Anthony @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Matthew Heaney 1997-09-06 0:00 ` Joachim Durchholz 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Matthew Heaney 1997-09-06 0:00 ` Matthew Heaney 1997-09-08 0:00 ` John G. Volan [not found] ` <dewar.873826570@merv> 4 siblings, 2 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-06 0:00 ` Patrick Doyle @ 1997-09-06 0:00 ` Matthew Heaney 1997-09-07 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Matthew Heaney 1 sibling, 1 reply; 185+ messages in thread From: Matthew Heaney @ 1997-09-06 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-06 0:00 ` Matthew Heaney @ 1997-09-07 0:00 ` Patrick Doyle 1997-09-07 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Robert Dewar 0 siblings, 2 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-07 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-07 0:00 ` Patrick Doyle @ 1997-09-07 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Don Harrison 1997-09-10 0:00 ` Robert Dewar 1 sibling, 1 reply; 185+ messages in thread From: Matthew Heaney @ 1997-09-07 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-07 0:00 ` Matthew Heaney @ 1997-09-10 0:00 ` Don Harrison 1997-09-10 0:00 ` Patrick Doyle ` (4 more replies) 0 siblings, 5 replies; 185+ messages in thread From: Don Harrison @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Don Harrison @ 1997-09-10 0:00 ` Patrick Doyle 1997-09-16 0:00 ` Don Harrison 1997-09-10 0:00 ` Samuel Mize ` (3 subsequent siblings) 4 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-16 0:00 ` Don Harrison 1997-09-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-16 0:00 ` Don Harrison @ 1997-09-18 0:00 ` Robert Dewar 1997-09-18 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 1 reply; 185+ messages in thread From: Robert Dewar @ 1997-09-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-18 0:00 ` Robert Dewar @ 1997-09-18 0:00 ` Shmuel (Seymour J.) Metz 1997-09-20 0:00 ` Robert Dewar 0 siblings, 1 reply; 185+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-09-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-18 0:00 ` Shmuel (Seymour J.) Metz @ 1997-09-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Don Harrison 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-10 0:00 ` Samuel Mize 1997-09-10 0:00 ` Samuel Mize ` (2 more replies) 1997-09-10 0:00 ` Tucker Taft ` (2 subsequent siblings) 4 siblings, 3 replies; 185+ messages in thread From: Samuel Mize @ 1997-09-10 0:00 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Samuel Mize @ 1997-09-10 0:00 ` Samuel Mize 1997-09-11 0:00 ` Don Harrison 1997-09-11 0:00 ` Robert Dewar 2 siblings, 0 replies; 185+ messages in thread From: Samuel Mize @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Samuel Mize 1997-09-10 0:00 ` Samuel Mize @ 1997-09-11 0:00 ` Don Harrison 1997-09-11 0:00 ` Robert Dewar 2 siblings, 0 replies; 185+ messages in thread From: Don Harrison @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Samuel Mize 1997-09-10 0:00 ` Samuel Mize 1997-09-11 0:00 ` Don Harrison @ 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Samuel T. Harris ` (2 more replies) 2 siblings, 3 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert Dewar @ 1997-09-12 0:00 ` Samuel T. Harris 1997-09-12 0:00 ` Samuel Mize 1997-09-17 0:00 ` Don Harrison 2 siblings, 0 replies; 185+ messages in thread From: Samuel T. Harris @ 1997-09-12 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Samuel T. Harris @ 1997-09-12 0:00 ` Samuel Mize 1997-09-13 0:00 ` Tucker Taft 1997-09-17 0:00 ` Don Harrison 2 siblings, 1 reply; 185+ messages in thread From: Samuel Mize @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Samuel Mize @ 1997-09-13 0:00 ` Tucker Taft 0 siblings, 0 replies; 185+ messages in thread From: Tucker Taft @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Samuel T. Harris 1997-09-12 0:00 ` Samuel Mize @ 1997-09-17 0:00 ` Don Harrison 1997-09-18 0:00 ` Robert Dewar 2 siblings, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-17 0:00 ` Don Harrison @ 1997-09-18 0:00 ` Robert Dewar 0 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Don Harrison 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Samuel Mize @ 1997-09-10 0:00 ` Tucker Taft 1997-09-10 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Don Harrison 1997-09-10 0:00 ` Matthew Heaney 1997-09-11 0:00 ` Robert Dewar 4 siblings, 2 replies; 185+ messages in thread From: Tucker Taft @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Tucker Taft @ 1997-09-10 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Patrick Doyle ` (2 more replies) 1997-09-10 0:00 ` Don Harrison 1 sibling, 3 replies; 185+ messages in thread From: Matthew Heaney @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Matthew Heaney @ 1997-09-10 0:00 ` Patrick Doyle 1997-09-12 0:00 ` Robert Dewar 1997-09-11 0:00 ` Lee Webber 1997-09-12 0:00 ` Don Harrison 2 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Patrick Doyle 0 siblings, 1 reply; 185+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Robert Dewar @ 1997-09-13 0:00 ` Patrick Doyle 0 siblings, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-11 0:00 ` Lee Webber 1997-09-15 0:00 ` W. Wesley Groleau x4923 1997-09-12 0:00 ` Don Harrison 2 siblings, 1 reply; 185+ messages in thread From: Lee Webber @ 1997-09-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Lee Webber @ 1997-09-15 0:00 ` W. Wesley Groleau x4923 0 siblings, 0 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-15 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Lee Webber @ 1997-09-12 0:00 ` Don Harrison 2 siblings, 0 replies; 185+ messages in thread From: Don Harrison @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Tucker Taft 1997-09-10 0:00 ` Matthew Heaney @ 1997-09-10 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 1 sibling, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Don Harrison @ 1997-09-12 0:00 ` Robert Dewar 1997-09-16 0:00 ` Don Harrison 0 siblings, 1 reply; 185+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Robert Dewar @ 1997-09-16 0:00 ` Don Harrison 1997-09-17 0:00 ` Robert Dewar 0 siblings, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-16 0:00 ` Don Harrison @ 1997-09-17 0:00 ` Robert Dewar 0 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-17 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Don Harrison ` (2 preceding siblings ...) 1997-09-10 0:00 ` Tucker Taft @ 1997-09-10 0:00 ` Matthew Heaney 1997-09-11 0:00 ` Robert Dewar 4 siblings, 0 replies; 185+ messages in thread From: Matthew Heaney @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Don Harrison ` (3 preceding siblings ...) 1997-09-10 0:00 ` Matthew Heaney @ 1997-09-11 0:00 ` Robert Dewar 4 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) <<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? ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-07 0:00 ` Patrick Doyle 1997-09-07 0:00 ` Matthew Heaney @ 1997-09-10 0:00 ` Robert Dewar 1997-09-10 0:00 ` Nick Leaton 1997-09-16 0:00 ` Frederic Guerin 1 sibling, 2 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Robert Dewar @ 1997-09-10 0:00 ` Nick Leaton 1997-09-16 0:00 ` Frederic Guerin 1 sibling, 0 replies; 185+ messages in thread From: Nick Leaton @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Robert Dewar 1997-09-10 0:00 ` Nick Leaton @ 1997-09-16 0:00 ` Frederic Guerin 1 sibling, 0 replies; 185+ messages in thread From: Frederic Guerin @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Matthew Heaney @ 1997-09-06 0:00 ` Matthew Heaney 1 sibling, 0 replies; 185+ messages in thread From: Matthew Heaney @ 1997-09-06 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Matthew Heaney ` (2 preceding siblings ...) 1997-09-06 0:00 ` Patrick Doyle @ 1997-09-08 0:00 ` John G. Volan 1997-09-09 0:00 ` Nick Leaton 1997-09-09 0:00 ` Paul Johnson [not found] ` <dewar.873826570@merv> 4 siblings, 2 replies; 185+ messages in thread From: John G. Volan @ 1997-09-08 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` John G. Volan @ 1997-09-09 0:00 ` Nick Leaton 1997-09-09 0:00 ` John G. Volan 1997-09-09 0:00 ` Paul Johnson 1 sibling, 1 reply; 185+ messages in thread From: Nick Leaton @ 1997-09-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Nick Leaton @ 1997-09-09 0:00 ` John G. Volan 1997-09-10 0:00 ` Nick Leaton 0 siblings, 1 reply; 185+ messages in thread From: John G. Volan @ 1997-09-09 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` John G. Volan @ 1997-09-10 0:00 ` Nick Leaton 1997-09-10 0:00 ` Samuel Mize 0 siblings, 1 reply; 185+ messages in thread From: Nick Leaton @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Nick Leaton @ 1997-09-10 0:00 ` Samuel Mize 0 siblings, 0 replies; 185+ messages in thread From: Samuel Mize @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` John G. Volan 1997-09-09 0:00 ` Nick Leaton @ 1997-09-09 0:00 ` Paul Johnson 1 sibling, 0 replies; 185+ messages in thread From: Paul Johnson @ 1997-09-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <dewar.873826570@merv>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <dewar.873826570@merv> @ 1997-09-09 0:00 ` Matthew Heaney 1997-09-11 0:00 ` Robert Dewar 0 siblings, 1 reply; 185+ messages in thread From: Matthew Heaney @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Matthew Heaney @ 1997-09-11 0:00 ` Robert Dewar 0 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFyrH2.7z2@syd.csa.com.au> ` (2 preceding siblings ...) 1997-09-05 0:00 ` Matthew Heaney @ 1997-09-07 0:00 ` Robert Dewar 1997-09-08 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Don Harrison 3 siblings, 2 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-07 0:00 ` Robert Dewar @ 1997-09-08 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Don Harrison 1 sibling, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-07 0:00 ` Robert Dewar 1997-09-08 0:00 ` Patrick Doyle @ 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Robert Dewar 1 sibling, 2 replies; 185+ messages in thread From: Don Harrison @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Don Harrison @ 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Robert Dewar 1 sibling, 0 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-09 0:00 UTC (permalink / raw) > 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? ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Robert Dewar 1997-09-11 0:00 ` Don Harrison 1 sibling, 1 reply; 185+ messages in thread From: Robert Dewar @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Robert Dewar @ 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Don Harrison @ 1997-09-12 0:00 ` Robert Dewar 1997-09-16 0:00 ` Don Harrison 0 siblings, 1 reply; 185+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Robert Dewar @ 1997-09-16 0:00 ` Don Harrison 1997-09-17 0:00 ` Robert Dewar 0 siblings, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-16 0:00 ` Don Harrison @ 1997-09-17 0:00 ` Robert Dewar 0 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-17 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Samuel Mize ` (2 preceding siblings ...) [not found] ` <EFyrH2.7z2@syd.csa.com.au> @ 1997-09-04 0:00 ` Erik Ernst 1997-09-05 0:00 ` Robert Dewar 4 siblings, 0 replies; 185+ messages in thread From: Erik Ernst @ 1997-09-04 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Samuel Mize ` (3 preceding siblings ...) 1997-09-04 0:00 ` Erik Ernst @ 1997-09-05 0:00 ` Robert Dewar 4 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-05 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Interface/Implementation (was Re: Design by Contract) Tucker Taft 1997-08-29 0:00 ` Paul Johnson @ 1997-09-01 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-02 0:00 ` Nick Leaton 1 sibling, 1 reply; 185+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-01 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-01 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-02 0:00 ` Nick Leaton 1997-09-03 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 1 reply; 185+ messages in thread From: Nick Leaton @ 1997-09-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Nick Leaton @ 1997-09-03 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 0 replies; 185+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-03 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) @ 1997-09-15 0:00 Marc Wachowitz 1997-09-16 0:00 ` Owen Fellows 0 siblings, 1 reply; 185+ messages in thread From: Marc Wachowitz @ 1997-09-15 0:00 UTC (permalink / raw) Nick <nickle@calfp.co.uk> wrote via Owen Fellows <ofellows@calfp.co.uk> about supposedly "pure" OO a la Eiffel vs. Ada-like modules and types as different concepts and non-method procedures: > But it it more likely that you just inherit MATHEMATICIAN somewhere in > your heirarchy to save on typing. I find that totally unacceptable, as it creates much too strong coupling between library modules and their clients. Adding new features to a library module shouldn't force even the smallest change in any previously existing clients. The same applies to unavoidable visibility of every parent feature in children - to avoid potential clashes, one is forced to revert to using long_feature_names_saying_they_are_only_for_class_X_and_not_for_children, which is a shame for a somewhat recent language like Eiffel (even in old K&R C you had private - aka static - functions/variables), in my view. The point isn't so much about children touching conceptually private features of parents where they shouldn't do that (though that does get "interesting" in large projects with say, 50 to 100 programmers of varying quality, and I'd rather have that checked, too), but about clean separation of concerns and minimal coupling. > Having the same implementation as inherits is a hint that it probably is > inherits! No more than the implementation of loops via conditional goto is a hint to drop explicit loops from the language and only provide conditional goto (and perhaps call/return) as control structure. I expect most people wouldn't follow the latter reasoning (nor do I), and likewise I disagree with your above suggestion. In fact, I'd already use inheritance much less than what seems to be usual in the Eiffel world (if Bertrand Meyer's books are a hint about general usage): Even if it means more writing, I prefer having a mere client for an object via a field over implementation inheritance: As long as the representation type can be used unchanged via its abstract interface, I'll do so. If it's mostly right, but still no proper "is-a" relation holds, I'll also seriously consider a different subclass with some small changes for the different need, and then using this adaption as client in that new type which really isn't a proper subtype. I find this to be much better at decoupling, more explicit about the essential relations between those types, and more readable for my taste. The counter-argument about inefficiency due to another indirection doesn't hold, as the above is only about source level stuff: If performance is critical, make the compiler sufficiently clever to inline the respective data and operations for such cases, which should be quite trivial. The counter-argument about needing all the facilities which are used for inheritance again for import doesn't really work either, since the usage of library modules with qualified names for feature access doesn't need things like renaming, redefinition, re-export or hiding; simply write e.g. Math.Sin(X) and stop worrying about name space pollution. (Well, you do have to think about module names, which should ideally be a hierarchical name space, similar to Ada child packages or Java packages, but it reduces the amount of relevant names dramatically.) -- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de> ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-15 0:00 Marc Wachowitz @ 1997-09-16 0:00 ` Owen Fellows 0 siblings, 0 replies; 185+ messages in thread From: Owen Fellows @ 1997-09-16 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract)
@ 1997-09-12 0:00 Marc Wachowitz
1997-09-12 0:00 ` Joachim Durchholz
1997-09-12 0:00 ` Samuel T. Harris
0 siblings, 2 replies; 185+ messages in thread
From: Marc Wachowitz @ 1997-09-12 0:00 UTC (permalink / raw)
Joachim Durchholz <joachim.durchholz@munich.netsurf.de> wrote:
> Ada, if we have a name clash, we're forced to
> type the full module name wherever a clashing name is used (at least
> that's what I remember, corrections welcome!).
If you merely import a package, by means of a "with" clause, you cannot
get any name clashes at all, no matter what's in the package, since every
reference is qualified with the package name.
If you don't like some name, e.g. of a package or a type or a variable or
a routine or an exception, you can introduce another name for it (which
may be local, but can also be exported by a package). This can as well be
used to introduce non-qualified names specifically for that imported stuff
which you want, without being bothered by whatever else the package exports,
or might export in the future.
Only if you really call for it, by means of a "use" clause, all the stuff
exported by an imported package will become visible in the client's scope,
and thus be a potential source for name clashes (for routines only where
overloading can't resolve the conflict). Many people don't like use-clauses,
and some projects don't allow them. They are never necessary at all, only a
way to reduce typing (i.e. on the keybord, this isn't about type checking).
-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 Marc Wachowitz @ 1997-09-12 0:00 ` Joachim Durchholz 1997-09-12 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 185+ messages in thread From: Joachim Durchholz @ 1997-09-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 Marc Wachowitz 1997-09-12 0:00 ` Joachim Durchholz @ 1997-09-12 0:00 ` Samuel T. Harris 1997-09-12 0:00 ` Jon S Anthony 1 sibling, 1 reply; 185+ messages in thread From: Samuel T. Harris @ 1997-09-12 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Samuel T. Harris @ 1997-09-12 0:00 ` Jon S Anthony 1997-09-15 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 185+ messages in thread From: Jon S Anthony @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Jon S Anthony @ 1997-09-15 0:00 ` Samuel T. Harris 1997-09-16 0:00 ` Jon S Anthony 0 siblings, 1 reply; 185+ messages in thread From: Samuel T. Harris @ 1997-09-15 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-15 0:00 ` Samuel T. Harris @ 1997-09-16 0:00 ` Jon S Anthony 0 siblings, 0 replies; 185+ messages in thread From: Jon S Anthony @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract)
@ 1997-09-09 0:00 Marc Wachowitz
1997-09-15 0:00 ` Owen Fellows
0 siblings, 1 reply; 185+ messages in thread
From: Marc Wachowitz @ 1997-09-09 0:00 UTC (permalink / raw)
"John G. Volan" <johnv@ac3i.dseg.ti.com> wrote:
> Eiffel doesn't care about the order in which things are declared, but it
> also lacks this notion of elaboration order. So how does it handle
> intializing classwide globals? I seem to recall something about "once"
> methods -- routines that get executed just once, the first time they are
> called. The results are cached, and all subsequent calls just return
> the cached results. Supposedly you can initialize classwide globals
> inside such methods. Do I have that right?
There aren't any classwide (or other) "global variables" in the usual sense,
only once-methods. The cached result of a once-method acts as a kind of global
object; i.e. if you want a true "variable" to which you can assign later, you
use a once-method containing (directly or indirectly) a field which acts as
your variable; if you do only need the initial value again and again, you can
use it directly as result of the once-method. Note that a once-method, as any
other method in Eiffel, has to be invoked on some instance of its class, or
any of its subclasses.
This is based on the Eiffel philosophy that every computation must be based
on a method invocation for some object, and that independent variables or
routines would be bad. Even the creation methods must be called in relation
to an already created instance. The work-around (in my view - Eiffel fans
might praise it as something logical) for library-functions is to have clients
inherit from some class (or use other quite absurd tricks, based on classes
without fields) to get at something like mathematical functions which do in
fact only depend on their arguments, not on any "receiver". Thus the use of a
routine library tends to be modeled as inheriting from a class providing them.
(To Eiffel fans: Yes, I've read Bertrand Meyer's arguments for a "pure" object
oriented view, where classes are the only modules and where there aren't any
non-instance-related routines. Having pondered these things for some time now,
I don't agree at all, and prefer having non-class modules and some routines
which aren't related to any instances.)
-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 Marc Wachowitz @ 1997-09-15 0:00 ` Owen Fellows 1997-10-13 0:00 ` Bill Foote 0 siblings, 1 reply; 185+ messages in thread From: Owen Fellows @ 1997-09-15 0:00 UTC (permalink / raw) To: Marc Wachowitz 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-15 0:00 ` Owen Fellows @ 1997-10-13 0:00 ` Bill Foote 0 siblings, 0 replies; 185+ messages in thread From: Bill Foote @ 1997-10-13 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) @ 1997-09-06 0:00 Ell 1997-09-06 0:00 ` Samuel Mize 0 siblings, 1 reply; 185+ messages in thread From: Ell @ 1997-09-06 0:00 UTC (permalink / raw) W. Wesley Groleau x4923 (wwgrol@pseserv3.fw.hac.com) wrote: : : ... I was responding : to those who want to deny that a good feature language X is not : an advantage because language Y can accomplish the same thing by : an unintended use of features it DOES have. Those are the folks : that first brought up the idea. : : It happens on the Ada side, too. "Multiple inheritance is not : important because we can simulate it this way." What the Ada advocate : should say is one of (1) "We think MI is bad because" OR (2) "We : looked at the _goal_ of multiple inheritance and decided that _goal_ : could be better acheived by..." OR (3) "OK, we'll let you have that : as an advantage of your language." What's invalid about saying not saying (1), (2), or (3) and leaving things "equal". Certainly that situation _does_ exist. Elliott -- "The domain object model is the foundation of OOD." "We should seek out proven optimal practices and use them." See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-06 0:00 Ell @ 1997-09-06 0:00 ` Samuel Mize 0 siblings, 0 replies; 185+ messages in thread From: Samuel Mize @ 1997-09-06 0:00 UTC (permalink / raw) >W. Wesley Groleau x4923 (wwgrol@pseserv3.fw.hac.com) wrote: >: >: ... I was responding >: to those who want to deny that a good feature language X is not >: an advantage because language Y can accomplish the same thing by >: an unintended use of features it DOES have. Those are the folks >: that first brought up the idea. >: >: It happens on the Ada side, too. "Multiple inheritance is not >: important because we can simulate it this way." What the Ada advocate >: should say is one of (1) "We think MI is bad because" OR (2) "We >: looked at the _goal_ of multiple inheritance and decided that _goal_ >: could be better acheived by..." OR (3) "OK, we'll let you have that >: as an advantage of your language." 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) ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <EForKz.FJ7@ecf.toronto.edu>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] <EForKz.FJ7@ecf.toronto.edu> @ 1997-09-01 0:00 ` Don Harrison 1997-09-02 0:00 ` Don Harrison 0 siblings, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-01 0:00 ` Don Harrison @ 1997-09-02 0:00 ` Don Harrison 0 siblings, 0 replies; 185+ messages in thread From: Don Harrison @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Safety-critical development in Ada and Eiffel @ 1997-08-07 0:00 Ken Garlington 1997-08-12 0:00 ` Don Harrison 0 siblings, 1 reply; 185+ messages in thread From: Ken Garlington @ 1997-08-07 0:00 UTC (permalink / raw) Don Harrison wrote: > > Ken Garlington wrote: > > :Don Harrison wrote: > :> > :> Ken Garlington wrote: > :> > :> :Don Harrison wrote: > :> :> > :> :> What we want is a way to signal to the caller that they've made a mistake and > :> :> need to take corrective action. > :> : > :> :If they don't know to check that they might have made a mistake, > :> > :> They *do* know because they get an exception. > : > :Not when they're _writing_ the code, unfortunately. > > Yes, but we're not talking about writing the code. We're talking about execution. > Even Smalltalkers can't write and execute at the same time. :) Eiffel advocates need to decide: Is the primary value of assertions for documentation (as Meyer maintains) or to raise errors during execution (which has a number of drawbacks, including potentially postponing the detection of the problem until well after it is delivered). > > :> :how do they know what corrective action they should take? > :> > :> To determine the right corrective action, they determine which specific > :> (sub-)expression triggered the violation and work out the cause by conventional > :> means, namely logical deduction. > : > :This brings up the second point. Why would a methodology/language go to > :great lengths to _detect_ errors, but completely punt ("use conventional > :means") to determine what to do _afterwards_? > > DBC won't fix the errors for you. :) No, but other methodologies do discuss error recovery techniques, and how to apply them. This is particularly important if the error won't be uncovered until after it is delivered. > No tool can *think* for you. DBC does help identify and localise errors, but > you're the one who must solve them. > > :> :If the erroneous code is reused in another application, doesn't it carry > :> :its error along with it? > :> > :> Yes, that's why it's important to fix it. :) > : > :Doesn't this erode the argument of using Eiffel to support reuse, if > :errors > :are so easily ported between applications? > > No. If an error doesn't exist, it can't be ported. Consider the Ariane case. The error didn't exist in the original environment (Ariane IV). The error only occured during execution in the Ariane 5 environment (a little too late to fix, unfortunately). Basing your argument on execution means that any latent error in the system, which might be caught in other methodologies through the use of analysis and reviews, will be missed using DBC/Eiffel. > > :> :What if the mistake is in your code, not the calling code? > :> > :> The context we're dicussing is a precondition, so I assume you mean a mistake > :> in the precondition. This will be obvious from the fact that the call is valid. > : > :Your code thinks the call is invalid. Who decides otherwise? > > The developer running the program - by thinking. Which is completely contradicted by the abve statements of using assertions for execution purposes. The whole point of a methodology is to guide the thinking of an analyst. It doesn't sound like DBC/Eiffel has given you much in the way of guidance. > > :> This is what I mean about the code proper validating assertions. (See my previous > :> posts for details). > :> > :> :> What about case 2)? Here, we want to check that the work we delegated was > :> :> done properly and acheived what we set out to do. In this case, we can > :> :> perform some checks and raise and exception against ourselves to force us > :> :> to fix the problem (possibly by delegating).. > :> :> > :> :> procedure Assume_Control (Aircraft: Aircraft_Type) is > :> :> require not My_Aircraft.Mine (Aircraft) > :> :> begin > :> :> ... > :> :> My_Aircraft.Add (Aircraft); > :> :> ensure My_Aircraft.Mine (Aircraft) > :> :> end; > :> :> > :> :> which is our final solution. What we are now left with is a component of > :> :> software that we know can only be executed under the intended conditions and > :> :> can guarantee producing the required results. > :> : > :> :Assuming... > :> : > :> :1. My_Aircraft.Mine is correct. (How is this determined? > :> > :> Joachim has already mentioned code inspection. > : > :See my arguments related to manual inspection as the only safeguard > :against > :errors in large systems. > > I'm not suggesting it should be. More to the point, you haven't given any evidence that DBC/Eiffel has any particular advantage in this area. > :> Also, if Mine is called anywhere in the code proper of the system and it has > :> its own assertions, it will be validated by them. > : > :However, other posts have said that assertions shouldn't have > :assertions. > > We're talking about different things. See the OOSC-2 reference and my comments > following for details.. > > :> However, these lower-level > :> assertions won't be evaluated as part of higher-level assertion evaluation. > :> > :> (For details, see OOSC-2, Chapter 11 - "Design by Contract: Building Reliable > :> Software", Page 400 ff.) > :> > :> In this sense, I suppose you could say there are "assertions about assertions" (meta-assertions). They help where they're needed most - where assertions are > :> abstracted using boolean functions. > > :> :2. Assume_Control is not called again with the same aircraft between the > :> : pre-condition and My_Aircraft.Add. > :> : > :> :3. Release_Control (I propose this as the opposite of Assume_Control) is > :> : not called between My_Aircraft.Add and the post-condition. > :> > :> Neither of these concurrency issues exist under SCOOP because the runtime system > :> automatically locks objects on behalf of the thread using them. It's simply > :> impossible to have concurrent access to an object by multiple threads. > : > :So, if an object is referenced by a thread, no other operations > :associated with > :the object can be called (object-locking, as opposed to > :operation-locking)? > > In theory, yes. In practice, I would expect SCOOP implementations to provide > greater flexibility through optimisations (See below). > > :Doesn't this cause a few latency problems? For example, it's usually OK > :for > :multiple reads to occur concurrently, so long as no write is in process. > :SCOOP only permits sequential reads? > > Optimisations could allow multiple concurrent queries (reads). The important > is that exclusive access is *theoretically* guaranteed. What happens in practice > doesn't matter so long as it's safe. Has such automated optimization been done in practice? Isn't such an optimization on the same difficulty level as the toolset automatically generating the correct assertions for each interface? > > :> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 - > :> "Accessing separate objects", Page 982 ff.) > :> > :> Ada, in contrast, does allow this - for example, if tasking is used in isolation. > :> To overcome this deficiency, you have to either roll-your-own object protection > :> (using semaphores, for example) or use protected objects. Using Ada protected > :> objects is fine, but they lack the flexibility of Eiffel separate objects. > : > :Just the opposite! > > Incorrect. Eiffel separate objects always lock the object. Ada protected records can lock the object for a given operation or not (at the designer's preference), can requeue requests, etc. More choices for the designer usually means additional flexibility, I would think. > > :Protected objects, for example, would allow concurrent reads > :if no timing issues result! > > See above. You lose flexibility with protected types because they're not > inheritable and can't be used polymorphically. But you gain flexibility in their timing capabilities (which is what we were discussing, remember? :). Given that the purpose of a protected type is to define time-based aspects the system, isn't this the more valuiable flexibility for this type of object? > > :> :4. There are no errors from other sources (e.g. extraneous code, > :> :higher-tier > :> : documentation miscommunications). > :> > :> I've already covered the case of extraneous code in a previous post. > : > :Right - you said that you assume this won't happen. > > No, I said something else. You said that you did not provide exhaustive coverage via assertions. If that doesn't mean that you assume the condition will not occur, what does it mean? That you assume it will occur, but do not address it? > > :> WRT documentation-related problems, these are outside the scope of any runtime > :> error checking mechanism. DBC is *almost* a silver bullet but not quite. :) > : > :Is DBC a methodology, or a "runtime error checking mechanism"? > > Both. Then what does it matter what a "runtime error checking mechanism" does? The question remains: How does DBC address documentation-related problems? > > :I certainly know > :methodologies that will help uncover extraneous code, and > :requirements/design > :issues. In fact, some methodologies emphasize the ability to manage > :requirements > :and design, since that's where many of the really difficult errors > :emerge. > > I agree this is an important area. Given that, then if DBC does not address this area, it must be deficient. > > :Someone needs to decide if DBC is a coding guideline or a software > :development > :methodology. My concern is that it is touted as the former, but used as > :the latter. > > I don't see any problem with using it as both. However, there is a serious problem when practitioners use it (and discuss it) in terms of the former. Note the number of times in this post, for example, that DBC has been described in terms of concrete capabilities when the subject is code execution, but only vaguely (if at all) when described as a methodology. For example: 1. How, specifically, does DBC support error detection prior to execution? (Not writing down potential error sources, but actually determining if the error exists in the particular application.) 2. By extension, how does DBC support error detection after reuse? 3. For those errors not discovered (which will presumably cause run-time exceptions), how does DBC guide the designer to handle these exceptions (which were not expected to occur)? 4. How does DBC help detect inconsistencies between code and requirements, or for that matter internal consistencies within the requirements? Given that we both agree (as noted earlier in the post) that the key is for the designer to think, how does a coding convention support such thinking - not in terms of general OO concepts like polymorphism and inheritance (which other languages, including Ada, have) but in terms of error detection and correction? > > :> :Also: If the post-condition fails, who provides the corrective action? > :> > :> During development, you, the designer of the code (or your delegate) by fixing > :> the problem. Additionally, in the case of critical software, you can add a > :> rescue clause (exception handler) to keep the show on the road in production. > : > :So, the client has to figure out what to do if your code fails? > > Who said anything about clients? I said the designer of the code containing > the postcondition - that is, the *supplier* in Eiffel parlance. Wait a minute! Here's the possible scenarios: 1. The post-condition fails during initial development. In this case, the developer of the code fixes the problem (or changes the post-condition, as unfortunately sometimes happens). However, how often is the post-condition going to fail at this point? The developer writes both the code and the post-condition, so it's likely that they will match at that point. 2. The post-condition fails after delivery. The developer may no longer be around to fix the problem. Furthermore, if there is a rescue clause, what does it do? What guidance does DBC provide. 3. The post-condition fails during reuse development. Same outcome as #2. This is the most likely case for a post-condition failing - where the environment in which the module is used changes. Any methodology that postpones finding errors until the code is reused is going to be difficult to sell as "reuse-friendly". > > My original example, reinserted.. > > : procedure Assume_Control (Aircraft: Aircraft_Type) is > : require not My_Aircraft.Mine (Aircraft) > : begin > : ... > : My_Aircraft.Add (Aircraft); > : ensure My_Aircraft.Mine (Aircraft) > : end; > > :> :Also: If My_Aircraft.Add is provided by a different programmer/team than > :> :Assume_Control, does it call My_Aircraft.Mine (or a subset thereof)? > :> > :> It doesn't matter. What's your point?.. > : > :It matters a lot! Again, if each team assumes the other does the call, > :this is bad news. > > Correct me if I have this wrong, but you seem to be worried about too few checks > and too many checks. > > WRT too few checks, it's always the responsibility of the client to make sure > the precondition is met. So, a check will always be made. Hasn't this whole discussion been in terms of how to detect errors in the code? Isn't it a little naive to assume that the code will be written correctly as a precondition for finding errors in the code? For that matter, if it's the client's responsibility, and it doesn't hurt if the assertion is not performed by the object being used, then doesn't this cut the legs out of an argument of Eiffel's power? Pretty much any language can provide assertions for the client to manually call prior to using an operation. > > WRT too many checks, an implementation may optimise out any redundant checks > - for example if a precondition check is already done by a caller. This minimises > the number of redundant checks. You're assuming a lot about automated optimizations across object interface boundaries. Is there evidence that Eiffel compilers do such optimizations successfully? Worse, you're again in the "proof by execution" mode. What does this extra code do in terms of readability, for example? > :If both teams do the call, this is not nice from a > :efficiency standpoint. > > See above. Ditto. Any methodology that says, "Write as much code as you want, the compiler will optimize it" doesn't seem to be a strong methodology, in my opinion. > > :> Other classes of error may be identified through other means that > :> you're already well acquanted with. > : > :Furthermore, the classes of error to which DBC is limited are > :well-covered > :through other means (beat to death, in fact). > > The difference is it does a better job of it. We'll just have to agree to disagree on this one. Again, I would rather have a methodology that helps me think about the issues vs. coding them. > > :So, I'm still at a loss to > :see what DBC brings to the table here. It doesn't address my main > :problem (requirements/design faults), > > Not entirely true. DBC can highlight specification/design inconsistencies. > (See my previous posts). Otherwise, I agree. I saw your previous posts. I quote from the line above: "WRT documentation-related problems, these are outside the scope of any runtime error checking mechanism. DBC is *almost* a silver bullet but not quite." Please summarize your arguments/evidence that DBC helps find documentation- related problems. > > :it has limitations with respect to implementation language, > > More accurate is to say that most languages provide limited support for it. Two responses: 1. I was discussing limitations in Eiffel, and 2. Other Eiffel experts disagree with you with regard to other languages: See the post on Internet newsgroup comp.lang.eiffel "Re: Papers on the Ariane-5 crash and Design by Contract," Jean-Marc Jezequel, 1997/03/18: "Ada's subtype declarations are a kind of contract, that could be documented as such. Design by contract is not specific to Eiffel. You can do it with any language, just because it is a way of designing!" > > :it's not clear that it scales well, > > Not true. Can you provide evidence to the contrary? See Internet newsgroup comp.lang.eiffel post "Re: Papers on the Ariane-5 crash and Design by Contract," Jean-Marc Jezequel, 1997/03/18: "...at least in the case of Ariane 501, simple assertions (a la Eiffel and other languages) would have been expressive enough to specify the fatal hidden assumption. Whether the last point scales up to a full sized mission critical system is still an open question. I'm quite confident it is so, but I've only my own experience with telco systems to back it up." > > :and it doesn't appear to be internally complete (big on error detection > :mechanisms, not much on how to derive the particular error sources, > > That's because they're typically blindingly obvious! Why? Because error detection > is more localised. But interface errors, by definition, are not localized. They are generated due to the interaction between objects (in some cases, a long thread of object interactions). The Ariane 5 case is a perfect example of this. Requirements/design mismatches, similarly, are not localized since the requirements are usually not written in terms of objects. One of the designer's jobs is to map the requirements to objects. Even for requirements that are object-oriented, they are usually a much higher level than the implementation. Again, you're thinking of run-time error detection. This is the worst place to detect errors. Consider, for example, the errors made in the Eiffel implementation of the scaling routine presented in their Ariane paper. If these errors were "blindingly obvious", why did it take a year for anyone to say anything about them? > > :and not much on what to do after the error is detected, for example). > > Again, this is usually blindingly obvious. Any time someone says something is obvious, without any evidence or argument to support it, I pretty much assume that the point is ceded. I will say that if error recovery is blindingly obvious, then there's a lot of work in the fault tolerance world that's apparently just a waste of money. :) > > All of these points have been made before. Unfortunately, I think you're right. It doesn't seem as though we're communicating very effectively. I'll concede the argument to you. > > Don. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Don Harrison donh@syd.csa.com.au ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Safety-critical development in Ada and Eiffel 1997-08-07 0:00 Safety-critical development in Ada and Eiffel Ken Garlington @ 1997-08-12 0:00 ` Don Harrison 1997-08-25 0:00 ` Design by Contract Bertrand Meyer 0 siblings, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-08-12 0:00 UTC (permalink / raw) Ken Garlington wrote (with deletions): :Don Harrison wrote: [...] :> No. If an error doesn't exist, it can't be ported. : :Consider the Ariane case. The error didn't exist in the original :environment :(Ariane IV). The error only occured during execution in the Ariane 5 :environment (a little too late to fix, unfortunately). Basing your :argument :on execution means that any latent error in the system, which might be :caught in other methodologies through the use of analysis and reviews, :will :be missed using DBC/Eiffel. I disagree. I'll explain below.. [...] :> :> (For details of object locking under SCOOP, see OOSC-2, Section 30.6 - :> :> "Accessing separate objects", Page 982 ff.) :> :> :> :> Ada, in contrast, does allow this - for example, if tasking is used in isolation. :> :> To overcome this deficiency, you have to either roll-your-own object protection :> :> (using semaphores, for example) or use protected objects. Using Ada protected :> :> objects is fine, but they lack the flexibility of Eiffel separate objects. :> : :> :Just the opposite! :> :> Incorrect. : :Eiffel separate objects always lock the object. Ada protected records :can lock the :object for a given operation or not (at the designer's preference), IMO, this is something the designer is better off leaving to the compiler as it can be expected to do a better job of it. If Ada protected types allow the designer to explicitly leave objects unlocked (which doesn't appear to be supported by the Ada95 Rationale), then they are more permissive but in a detrimental way, IMO. :can requeue requests, IMO, the situations in which you would use "requeue" are better handled by designing differently - perhaps by using an additional class. If anything, "requeue" probably encourages poor design. :etc. What are these? More choices for the designer usually means additional :flexibility, I would think. Drawing some inspiration from Robert Dewar, "flexibility" and "permissiveness" have at their root the same meaning but differ wrt the user perceives a benefit or detriment respectively. [...] :> :Someone needs to decide if DBC is a coding guideline or a software :> :development :> :methodology. My concern is that it is touted as the former, but used as :> :the latter. :> :> I don't see any problem with using it as both. : :However, there is a serious problem when practitioners use it (and :discuss it) in terms of the former. Note the number of times in this :post, for example, that DBC has been described in terms of concrete :capabilities when the subject is code execution, but only vaguely :(if at all) when described as a methodology.. Your basic worry seems to be that DBC doesn't appear to be an all-embracing, formal software engineering methodology. At this stage, I think you're right. I think the reason why is that DBC probably hasn't been used in the context of *formal* software engineering. If it had, then it would have been integrated with other complementary reliability-enhancing techniques. IMO, a methodology centred on DBC, would also include stuff about systematic testing of components. In the Ariane case, this might involve bolting an IRS onto some test bench and stimulating it with Ariane 5 data. This may require simulating the surrounding environment. Then, any assertions assuming Ariane 4 inputs would be violated (as would the Ada constraint_error). In general, the extra checking afforded by DBC would mean more bugs would be identified than if it wasn't used. (Yes, I know there is no difference wrt the one that caused the failure.) [...] :> :So, I'm still at a loss to :> :see what DBC brings to the table here. It doesn't address my main :> :problem (requirements/design faults), :> :> Not entirely true. DBC can highlight specification/design inconsistencies. :> (See my previous posts). Otherwise, I agree. : :I saw your previous posts. I quote from the line above: : : "WRT documentation-related problems, these are outside the scope of : any runtime error checking mechanism. DBC is *almost* a silver bullet : but not quite." Right person, wrong quote and wrong context. If it's any help to you, the comments I'm referring to were about mutually validating requirements. I acknowledged not all documentation errors were covered. [...] :> :it's not clear that it scales well, :> :> Not true. : :Can you provide evidence to the contrary? I've already covered this. Nick's experience also endorses it. [...] :> :and not much on what to do after the error is detected, for example). :> :> Again, this is usually blindingly obvious. :> :Any time someone says something is obvious, without any evidence or :argument to support it, I pretty much assume that the point is ceded. No, it just means I'm just getting impatient. :( Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Design by Contract @ 1997-08-25 0:00 ` Bertrand Meyer [not found] ` <3402d123.0@news.uni-ulm.de> 0 siblings, 1 reply; 185+ messages in thread From: Bertrand Meyer @ 1997-08-25 0:00 UTC (permalink / raw) on S Anthony wrote: > Isn't this simply amazing? I mean, really - what do these people > think they are saying anyway? To me this has long since pushed my > "boggo-meter" off the scale and crossed into the mind-numbingly > fatuous. where "these people", if I understand properly, means advocates of Design by Contract. Insulting the other side is not a substitute for rational argument (but tends to suggest fragility of one's case). In a related message, W. Wesley Groleau writes > I say again: If [Design by Contract] > is defined as "Associating specifications > with software elements", then Eiffel indeed directly > supports a SUBSET of DBC. Ada directly supports another > subset of DBC. C++ (shudder) directly supports yet > another subset of DBC. And with a little extra work, > the user of any of these languages can handle a larger > subset. But none of them can completely support > the whole thing. And the intersection of the subsets > is not empty. which the 3 or 4 strident Ada advocates in this thread now repeat in all tunes to assert that, after all, Ada supports Design by Contract just as much as Eiffel, only differently. This is a sophism. Of course in any typed language you can express some specification elements; e.g. by declaring f (x: INTEGER) in Pascal or the equivalent in Fortran, C, Ada etc. you are placing some restrictions on what kind of argument f admits. But this is a far cry from what you need to express useful specifications: - Routine preconditions -- semantic conditions (not just type constraints). - Routine postconditions (how do you state that at the end of the procedure `withdraw' the balance must have been decreased by `sum'?). - Class invariants, expressing general integrity constraints. - The relationship with inheritance (precondition weakening and postcondition strengthening in redeclaration; invariant accumulation). - The relationship with documentation tools. - The relationship with exception handling. Common languages support at most a minute subset of the 1st and 3rd items. To use this observation to justify a Turing-tarpit kind of argument -- "all languages support Design by Contract, only in various ways" -- is a fallacy. So huge a "difference of degree" becomes a difference of nature. Just take any of the assertions of the classes of EiffelBase and try to express them in C, Ada, C++ or Java. You will be able to write almost nothing. What *is* true is that in such languages without assertions you can and should still apply Design by Contract purely as a methodological discipline. Although you won't get the language and tool support, you will still get some of the benefits. But, no, declaring variables with interval types as in Pascal or Ada is not Design by Contract. The rear-guard battle waged by a few people against Design by Contract on comp.lang.ada and comp.lang.eiffel -- oscillating between "it's useless", "it can all be done in Ada", "it's nothing new", "it's irrelevant to the real problems", "it's not enough", "it's snake oil" and other endless if often contradictory variations -- is saddening. Saddening because as soon as Design by Contract is applied systematically (whether as pure methodology, or better yet in a language like Eiffel that directly supports them) the benefits in reliability are immediate and huge. We constantly hear from our customers and our own work of major potential bugs that are caught before they have had time to strike, simply thanks to contracts. And bug avoidance is only one of the applications. The ability to do serious object-oriented analysis, for example, is just as important. All the rhetoric in the world fades away when assessed against the potential for dramatic improvements in software quality. That's what counts -- not who shouts louder. -- Bertrand Meyer, President, ISE Inc. ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117 805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com> http://www.eiffel.com, with instructions for download ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <3402d123.0@news.uni-ulm.de>]
* Re: Design by Contract [not found] ` <3402d123.0@news.uni-ulm.de> @ 1997-08-26 0:00 ` Nick Leaton [not found] ` <3402e51d.0@news.uni-ulm.de> 0 siblings, 1 reply; 185+ messages in thread From: Nick Leaton @ 1997-08-26 0:00 UTC (permalink / raw) To: Joerg Rodemann Joerg Rodemann wrote: > And exactly for that reason I would like to join the opinion that source > seperation of specification and implementation is very useful as well. > As far as I can tell this is a feature that Eiffel seems to be missing, as > many other language. E. g. I rather liked Oberon for quite a while for its > clean and simple concept. But the merging of definition and module files (as > spec and implementation are called there) I found somewhat annoying. Surely > I could see some benefits of this 'new' mechanism if Oberon is used within > that graphical Oberon System. But I used an implementation of Oberon > developped at the University of Ulm that simply sat on top of a Unix system. > I thinks this mixin of spec and body would have messed up things a lot. > > My experience with C++ and C supports this believe as well (note: this is > just MY experience.) for people often do not care about this seperation. > the craziest thing IMO is the inlining of methods within the class header > in C++. If the code is not very well structured you can spend hours and days > about just searching for the specifications. (And the debugger won't be of > much help either... *sigh*) > > As I see it a separation of spec and body is VERY useful and indeed some > kind of contract as well. If it has to be counted among the constructs for > DBC depends of this term's actual definition... There are different ways of approaching the separation. I suspect the majority of people agree that separation is a good thing, but there are more than one way of achieving the aim. Approach one is the C++ way, separate files. The problem here is keeping them in line, consistent names etc. The other approach is to have one file, but have the ability to view the files in different ways. Extract the spcification, view everything. I believe the second way to be the better way as it is simpler, and you use the machine for something it is good at doing. The drawbacks are if you want to publish a specification that won't compile. Why is my immediate response. You need a means to publish specifications for libraries where you only release the compiled code, thereby hiding the implementation. -- Nick ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <3402e51d.0@news.uni-ulm.de>]
[parent not found: <3402E8C9.3384D976@calfp.co.uk>]
[parent not found: <dewar.872631036@merv>]
[parent not found: <3403F668.F6B57D97@calfp.co.uk>]
[parent not found: <34041331.0@news.uni-ulm.de>]
[parent not found: <3404696D.4487EB71@eiffel.com>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <3404696D.4487EB71@eiffel.com> @ 1997-08-27 0:00 ` Bertrand Meyer [not found] ` <34048FDC.13728473@eiffel.com> 1997-08-28 0:00 ` Tucker Taft 0 siblings, 2 replies; 185+ messages in thread From: Bertrand Meyer @ 1997-08-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <34048FDC.13728473@eiffel.com>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <34048FDC.13728473@eiffel.com> @ 1997-08-27 0:00 ` Bertrand Meyer 1997-08-28 0:00 ` Jon S Anthony 1997-08-28 0:00 ` Patrick Doyle 0 siblings, 2 replies; 185+ messages in thread From: Bertrand Meyer @ 1997-08-27 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-27 0:00 ` Bertrand Meyer @ 1997-08-28 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Robert Dewar [not found] ` <EForsv.Fqo@ecf.toronto.edu> 1997-08-28 0:00 ` Patrick Doyle 1 sibling, 2 replies; 185+ messages in thread From: Jon S Anthony @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Jon S Anthony @ 1997-08-29 0:00 ` Robert Dewar [not found] ` <EForsv.Fqo@ecf.toronto.edu> 1 sibling, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-08-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <EForsv.Fqo@ecf.toronto.edu>]
[parent not found: <JSA.97Aug29191413@alexandria.organon.com>]
[parent not found: <EFqDAG.2zn@ecf.toronto.edu>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFqDAG.2zn@ecf.toronto.edu> @ 1997-08-30 0:00 ` Jon S Anthony 1997-09-02 0:00 ` Don Harrison 1 sibling, 0 replies; 185+ messages in thread From: Jon S Anthony @ 1997-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFqDAG.2zn@ecf.toronto.edu> 1997-08-30 0:00 ` Jon S Anthony @ 1997-09-02 0:00 ` Don Harrison 1997-09-02 0:00 ` Jon S Anthony [not found] ` <EFwuzD.BxE@ecf.toronto.edu> 1 sibling, 2 replies; 185+ messages in thread From: Don Harrison @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Don Harrison @ 1997-09-02 0:00 ` Jon S Anthony 1997-09-03 0:00 ` Don Harrison [not found] ` <EFwuzD.BxE@ecf.toronto.edu> 1 sibling, 1 reply; 185+ messages in thread From: Jon S Anthony @ 1997-09-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-02 0:00 ` Jon S Anthony @ 1997-09-03 0:00 ` Don Harrison 0 siblings, 0 replies; 185+ messages in thread From: Don Harrison @ 1997-09-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <EFwuzD.BxE@ecf.toronto.edu>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFwuzD.BxE@ecf.toronto.edu> @ 1997-09-04 0:00 ` Don Harrison 1997-09-05 0:00 ` Patrick Doyle 1997-09-04 0:00 ` John G. Volan 1 sibling, 1 reply; 185+ messages in thread From: Don Harrison @ 1997-09-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` Don Harrison @ 1997-09-05 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Don Harrison 0 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Patrick Doyle 0 siblings, 2 replies; 185+ messages in thread From: Don Harrison @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Don Harrison @ 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Veli-Pekka Nousiainen 1997-09-12 0:00 ` Don Harrison 1997-09-10 0:00 ` Patrick Doyle 1 sibling, 2 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-09 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Veli-Pekka Nousiainen 1997-09-10 0:00 ` Samuel Mize 1997-09-12 0:00 ` Don Harrison 1 sibling, 1 reply; 185+ messages in thread From: Veli-Pekka Nousiainen @ 1997-09-10 0:00 UTC (permalink / raw) 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! > ---------------------------------------------------------------------- > ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Veli-Pekka Nousiainen @ 1997-09-10 0:00 ` Samuel Mize 0 siblings, 0 replies; 185+ messages in thread From: Samuel Mize @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Veli-Pekka Nousiainen @ 1997-09-12 0:00 ` Don Harrison 1 sibling, 0 replies; 185+ messages in thread From: Don Harrison @ 1997-09-12 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 @ 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann ` (2 more replies) 1 sibling, 3 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joachim Durchholz 1997-09-11 0:00 ` Robert S. White 1997-09-12 0:00 ` Jon S Anthony 2 siblings, 2 replies; 185+ messages in thread From: Joerg Rodemann @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Joerg Rodemann @ 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Matt Austern 1997-09-10 0:00 ` Joachim Durchholz 1 sibling, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-11 0:00 ` Matt Austern 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 0 siblings, 2 replies; 185+ messages in thread From: Matt Austern @ 1997-09-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Matt Austern @ 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 1 sibling, 0 replies; 185+ messages in thread From: Jon S Anthony @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Matt Austern 1997-09-12 0:00 ` Jon S Anthony @ 1997-09-13 0:00 ` Patrick Doyle 1 sibling, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Patrick Doyle @ 1997-09-10 0:00 ` Joachim Durchholz 1997-09-12 0:00 ` Joerg Rodemann 1 sibling, 1 reply; 185+ messages in thread From: Joachim Durchholz @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Joachim Durchholz @ 1997-09-12 0:00 ` Joerg Rodemann 0 siblings, 0 replies; 185+ messages in thread From: Joerg Rodemann @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann @ 1997-09-11 0:00 ` Robert S. White 1997-09-11 0:00 ` Don Harrison ` (2 more replies) 1997-09-12 0:00 ` Jon S Anthony 2 siblings, 3 replies; 185+ messages in thread From: Robert S. White @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert S. White @ 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Patrick Doyle 2 siblings, 0 replies; 185+ messages in thread From: Don Harrison @ 1997-09-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert S. White 1997-09-11 0:00 ` Don Harrison @ 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Patrick Doyle 2 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert S. White 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar @ 1997-09-13 0:00 ` Patrick Doyle 2 siblings, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann 1997-09-11 0:00 ` Robert S. White @ 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 2 siblings, 1 reply; 185+ messages in thread From: Jon S Anthony @ 1997-09-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Jon S Anthony @ 1997-09-13 0:00 ` Patrick Doyle 1997-09-16 0:00 ` Brian Rogoff 0 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-13 0:00 ` Patrick Doyle @ 1997-09-16 0:00 ` Brian Rogoff 0 siblings, 0 replies; 185+ messages in thread From: Brian Rogoff @ 1997-09-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFwuzD.BxE@ecf.toronto.edu> 1997-09-04 0:00 ` Don Harrison @ 1997-09-04 0:00 ` John G. Volan 1997-09-04 0:00 ` W. Wesley Groleau x4923 ` (2 more replies) 1 sibling, 3 replies; 185+ messages in thread From: John G. Volan @ 1997-09-04 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` John G. Volan @ 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle ` (2 more replies) 1997-09-05 0:00 ` Franck Arnaud 1997-09-05 0:00 ` Patrick Doyle 2 siblings, 3 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-04 0:00 UTC (permalink / raw) > 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 @ 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Jon S Anthony 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 2 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Paul Johnson 1997-09-06 0:00 ` Jon S Anthony 1 sibling, 2 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-09-05 0:00 UTC (permalink / raw) 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` W. Wesley Groleau x4923 @ 1997-09-06 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Paul Johnson 1 sibling, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Patrick Doyle @ 1997-09-08 0:00 ` Paul Johnson 1 sibling, 0 replies; 185+ messages in thread From: Paul Johnson @ 1997-09-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` W. Wesley Groleau x4923 @ 1997-09-06 0:00 ` Jon S Anthony 1 sibling, 0 replies; 185+ messages in thread From: Jon S Anthony @ 1997-09-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle @ 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Patrick Doyle ` (2 more replies) 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 2 siblings, 3 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` Robert Dewar @ 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Matthew Heaney 1997-09-09 0:00 ` Paul Johnson 1997-09-09 0:00 ` Robert S. White 2 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Patrick Doyle @ 1997-09-09 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Patrick Doyle 0 siblings, 1 reply; 185+ messages in thread From: Matthew Heaney @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Matthew Heaney @ 1997-09-10 0:00 ` Patrick Doyle 0 siblings, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Patrick Doyle @ 1997-09-09 0:00 ` Paul Johnson 1997-09-11 0:00 ` Robert Dewar 1997-09-09 0:00 ` Robert S. White 2 siblings, 1 reply; 185+ messages in thread From: Paul Johnson @ 1997-09-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Paul Johnson @ 1997-09-11 0:00 ` Robert Dewar 1997-09-11 0:00 ` Veli-Pekka Nousiainen 1997-09-12 0:00 ` Paul Johnson 0 siblings, 2 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert Dewar @ 1997-09-11 0:00 ` Veli-Pekka Nousiainen 1997-09-12 0:00 ` Paul Johnson 1 sibling, 0 replies; 185+ messages in thread From: Veli-Pekka Nousiainen @ 1997-09-11 0:00 UTC (permalink / raw) 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 !? > ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-11 0:00 ` Robert Dewar 1997-09-11 0:00 ` Veli-Pekka Nousiainen @ 1997-09-12 0:00 ` Paul Johnson 1997-09-14 0:00 ` Ken Garlington 1 sibling, 1 reply; 185+ messages in thread From: Paul Johnson @ 1997-09-12 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-12 0:00 ` Paul Johnson @ 1997-09-14 0:00 ` Ken Garlington 0 siblings, 0 replies; 185+ messages in thread From: Ken Garlington @ 1997-09-14 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Paul Johnson @ 1997-09-09 0:00 ` Robert S. White 2 siblings, 0 replies; 185+ messages in thread From: Robert S. White @ 1997-09-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Robert Dewar @ 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-10 0:00 ` John Viega 2 siblings, 1 reply; 185+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-09 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-10 0:00 ` John Viega 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 1 reply; 185+ messages in thread From: John Viega @ 1997-09-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-10 0:00 ` John Viega @ 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 0 siblings, 0 replies; 185+ messages in thread From: Matt Kennel (Remove 'NOSPAM' to reply) @ 1997-09-10 0:00 UTC (permalink / raw) 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. * ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` John G. Volan 1997-09-04 0:00 ` W. Wesley Groleau x4923 @ 1997-09-05 0:00 ` Franck Arnaud 1997-09-05 0:00 ` Patrick Doyle 2 siblings, 0 replies; 185+ messages in thread From: Franck Arnaud @ 1997-09-05 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-09-04 0:00 ` John G. Volan 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Franck Arnaud @ 1997-09-05 0:00 ` Patrick Doyle 2 siblings, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-27 0:00 ` Bertrand Meyer 1997-08-28 0:00 ` Jon S Anthony @ 1997-08-28 0:00 ` Patrick Doyle 1997-08-28 0:00 ` W. Wesley Groleau x4923 1 sibling, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Patrick Doyle @ 1997-08-28 0:00 ` W. Wesley Groleau x4923 0 siblings, 0 replies; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-08-28 0:00 UTC (permalink / raw) 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-27 0:00 ` Interface/Implementation (was Re: Design by Contract) Bertrand Meyer [not found] ` <34048FDC.13728473@eiffel.com> @ 1997-08-28 0:00 ` Tucker Taft 1997-08-28 0:00 ` W. Wesley Groleau x4923 [not found] ` <3406A707.787D@dmu.ac.uk> 1 sibling, 2 replies; 185+ messages in thread From: Tucker Taft @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Tucker Taft @ 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-08-28 0:00 ` Jon S Anthony [not found] ` <3406A707.787D@dmu.ac.uk> 1 sibling, 1 reply; 185+ messages in thread From: W. Wesley Groleau x4923 @ 1997-08-28 0:00 UTC (permalink / raw) 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! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` W. Wesley Groleau x4923 @ 1997-08-28 0:00 ` Jon S Anthony [not found] ` <EFnK8D.Lsv@ecf.toronto.edu> ` (2 more replies) 0 siblings, 3 replies; 185+ messages in thread From: Jon S Anthony @ 1997-08-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <EFnK8D.Lsv@ecf.toronto.edu>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <EFnK8D.Lsv@ecf.toronto.edu> @ 1997-08-29 0:00 ` Jon S Anthony 1997-08-30 0:00 ` Patrick Doyle 0 siblings, 1 reply; 185+ messages in thread From: Jon S Anthony @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-29 0:00 ` Jon S Anthony @ 1997-08-30 0:00 ` Patrick Doyle 1997-08-30 0:00 ` Jon S Anthony 0 siblings, 1 reply; 185+ messages in thread From: Patrick Doyle @ 1997-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-30 0:00 ` Patrick Doyle @ 1997-08-30 0:00 ` Jon S Anthony 1997-09-01 0:00 ` Patrick Doyle 0 siblings, 1 reply; 185+ messages in thread From: Jon S Anthony @ 1997-08-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-30 0:00 ` Jon S Anthony @ 1997-09-01 0:00 ` Patrick Doyle 0 siblings, 0 replies; 185+ messages in thread From: Patrick Doyle @ 1997-09-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-28 0:00 ` Jon S Anthony [not found] ` <EFnK8D.Lsv@ecf.toronto.edu> @ 1997-08-29 0:00 ` Suzanne Zampella 1997-08-29 0:00 ` Jon S Anthony [not found] ` <340E9BA2.32B3@rbgg252.rbg1.siemens.de> 2 siblings, 1 reply; 185+ messages in thread From: Suzanne Zampella @ 1997-08-29 0:00 UTC (permalink / raw) 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} ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-29 0:00 ` Suzanne Zampella @ 1997-08-29 0:00 ` Jon S Anthony 0 siblings, 0 replies; 185+ messages in thread From: Jon S Anthony @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <340E9BA2.32B3@rbgg252.rbg1.siemens.de>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <340E9BA2.32B3@rbgg252.rbg1.siemens.de> @ 1997-09-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 185+ messages in thread From: Robert Dewar @ 1997-09-07 0:00 UTC (permalink / raw) <<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!) ^ permalink raw reply [flat|nested] 185+ messages in thread
[parent not found: <3406A707.787D@dmu.ac.uk>]
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <3406A707.787D@dmu.ac.uk> @ 1997-08-29 0:00 ` Joerg Rodemann 1997-08-29 0:00 ` Ralph Paul 1997-09-01 0:00 ` Don Harrison 1 sibling, 1 reply; 185+ messages in thread From: Joerg Rodemann @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) 1997-08-29 0:00 ` Joerg Rodemann @ 1997-08-29 0:00 ` Ralph Paul 0 siblings, 0 replies; 185+ messages in thread From: Ralph Paul @ 1997-08-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: Interface/Implementation (was Re: Design by Contract) [not found] ` <3406A707.787D@dmu.ac.uk> 1997-08-29 0:00 ` Joerg Rodemann @ 1997-09-01 0:00 ` Don Harrison 1 sibling, 0 replies; 185+ messages in thread From: Don Harrison @ 1997-09-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 185+ messages in thread
end of thread, other threads:[~1997-10-13 0:00 UTC | newest] Thread overview: 185+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <01bcb389$24f579d0$1c10d30a@ntwneil> 1997-08-28 0:00 ` Interface/Implementation (was Re: Design by Contract) Tucker Taft 1997-08-29 0:00 ` Paul Johnson 1997-08-29 0:00 ` Jon S Anthony [not found] ` <EFqDC8.342@ecf.toronto.edu> 1997-09-02 0:00 ` Samuel Mize 1997-09-03 0:00 ` Paul Johnson 1997-09-03 0:00 ` Patrick Doyle 1997-09-03 0:00 ` Samuel Mize [not found] ` <EFyrH2.7z2@syd.csa.com.au> 1997-09-04 0:00 ` Joerg Rodemann 1997-09-05 0:00 ` Don Harrison [not found] ` <340fdb9f.0@news.uni-ulm.de> 1997-09-06 0:00 ` Joachim Durchholz 1997-09-06 0:00 ` Joachim Durchholz 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Don Harrison 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Joachim Durchholz 1997-09-09 0:00 ` Robert Dewar 1997-09-09 0:00 ` Richard Kenner 1997-09-10 0:00 ` Tucker Taft 1997-09-10 0:00 ` One pass compilation? W. Wesley Groleau x4923 1997-09-10 0:00 ` Interface/Implementation (was Re: Design by Contract) Joachim Durchholz 1997-09-10 0:00 ` Nick Leaton 1997-09-10 0:00 ` W. Wesley Groleau x4923 1997-09-11 0:00 ` Code ordering Steve Furlong 1997-09-12 0:00 ` Interface/Implementation (was Re: Design by Contract) Robert Dewar 1997-09-12 0:00 ` Nick Leaton 1997-09-11 0:00 ` Robert Dewar 1997-09-05 0:00 ` Jon S Anthony 1997-09-06 0:00 ` Fergus Henderson 1997-09-06 0:00 ` Jon S Anthony 1997-09-08 0:00 ` Robert Dewar 1997-09-11 0:00 ` Don Harrison 1997-09-08 0:00 ` Robert Dewar 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 1997-09-05 0:00 ` Jon S Anthony 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Jon S Anthony 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Patrick Doyle 1997-09-05 0:00 ` Matthew Heaney 1997-09-06 0:00 ` Joachim Durchholz 1997-09-06 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-06 0:00 ` Jon S Anthony 1997-09-06 0:00 ` Patrick Doyle 1997-09-06 0:00 ` Matthew Heaney 1997-09-07 0:00 ` Patrick Doyle 1997-09-07 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Don Harrison 1997-09-10 0:00 ` Patrick Doyle 1997-09-16 0:00 ` Don Harrison 1997-09-18 0:00 ` Robert Dewar 1997-09-18 0:00 ` Shmuel (Seymour J.) Metz 1997-09-20 0:00 ` Robert Dewar 1997-09-10 0:00 ` Samuel Mize 1997-09-10 0:00 ` Samuel Mize 1997-09-11 0:00 ` Don Harrison 1997-09-11 0:00 ` Robert Dewar 1997-09-12 0:00 ` Samuel T. Harris 1997-09-12 0:00 ` Samuel Mize 1997-09-13 0:00 ` Tucker Taft 1997-09-17 0:00 ` Don Harrison 1997-09-18 0:00 ` Robert Dewar 1997-09-10 0:00 ` Tucker Taft 1997-09-10 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Patrick Doyle 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Lee Webber 1997-09-15 0:00 ` W. Wesley Groleau x4923 1997-09-12 0:00 ` Don Harrison 1997-09-10 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 1997-09-16 0:00 ` Don Harrison 1997-09-17 0:00 ` Robert Dewar 1997-09-10 0:00 ` Matthew Heaney 1997-09-11 0:00 ` Robert Dewar 1997-09-10 0:00 ` Robert Dewar 1997-09-10 0:00 ` Nick Leaton 1997-09-16 0:00 ` Frederic Guerin 1997-09-06 0:00 ` Matthew Heaney 1997-09-08 0:00 ` John G. Volan 1997-09-09 0:00 ` Nick Leaton 1997-09-09 0:00 ` John G. Volan 1997-09-10 0:00 ` Nick Leaton 1997-09-10 0:00 ` Samuel Mize 1997-09-09 0:00 ` Paul Johnson [not found] ` <dewar.873826570@merv> 1997-09-09 0:00 ` Matthew Heaney 1997-09-11 0:00 ` Robert Dewar 1997-09-07 0:00 ` Robert Dewar 1997-09-08 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Robert Dewar 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 1997-09-16 0:00 ` Don Harrison 1997-09-17 0:00 ` Robert Dewar 1997-09-04 0:00 ` Erik Ernst 1997-09-05 0:00 ` Robert Dewar 1997-09-01 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-02 0:00 ` Nick Leaton 1997-09-03 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-15 0:00 Marc Wachowitz 1997-09-16 0:00 ` Owen Fellows -- strict thread matches above, loose matches on Subject: below -- 1997-09-12 0:00 Marc Wachowitz 1997-09-12 0:00 ` Joachim Durchholz 1997-09-12 0:00 ` Samuel T. Harris 1997-09-12 0:00 ` Jon S Anthony 1997-09-15 0:00 ` Samuel T. Harris 1997-09-16 0:00 ` Jon S Anthony 1997-09-09 0:00 Marc Wachowitz 1997-09-15 0:00 ` Owen Fellows 1997-10-13 0:00 ` Bill Foote 1997-09-06 0:00 Ell 1997-09-06 0:00 ` Samuel Mize [not found] <EForKz.FJ7@ecf.toronto.edu> 1997-09-01 0:00 ` Don Harrison 1997-09-02 0:00 ` Don Harrison 1997-08-07 0:00 Safety-critical development in Ada and Eiffel Ken Garlington 1997-08-12 0:00 ` Don Harrison 1997-08-25 0:00 ` Design by Contract Bertrand Meyer [not found] ` <3402d123.0@news.uni-ulm.de> 1997-08-26 0:00 ` Nick Leaton [not found] ` <3402e51d.0@news.uni-ulm.de> [not found] ` <3402E8C9.3384D976@calfp.co.uk> [not found] ` <dewar.872631036@merv> [not found] ` <3403F668.F6B57D97@calfp.co.uk> [not found] ` <34041331.0@news.uni-ulm.de> [not found] ` <3404696D.4487EB71@eiffel.com> 1997-08-27 0:00 ` Interface/Implementation (was Re: Design by Contract) Bertrand Meyer [not found] ` <34048FDC.13728473@eiffel.com> 1997-08-27 0:00 ` Bertrand Meyer 1997-08-28 0:00 ` Jon S Anthony 1997-08-29 0:00 ` Robert Dewar [not found] ` <EForsv.Fqo@ecf.toronto.edu> [not found] ` <JSA.97Aug29191413@alexandria.organon.com> [not found] ` <EFqDAG.2zn@ecf.toronto.edu> 1997-08-30 0:00 ` Jon S Anthony 1997-09-02 0:00 ` Don Harrison 1997-09-02 0:00 ` Jon S Anthony 1997-09-03 0:00 ` Don Harrison [not found] ` <EFwuzD.BxE@ecf.toronto.edu> 1997-09-04 0:00 ` Don Harrison 1997-09-05 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Don Harrison 1997-09-09 0:00 ` W. Wesley Groleau x4923 1997-09-10 0:00 ` Veli-Pekka Nousiainen 1997-09-10 0:00 ` Samuel Mize 1997-09-12 0:00 ` Don Harrison 1997-09-10 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joerg Rodemann 1997-09-10 0:00 ` Patrick Doyle 1997-09-11 0:00 ` Matt Austern 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 1997-09-10 0:00 ` Joachim Durchholz 1997-09-12 0:00 ` Joerg Rodemann 1997-09-11 0:00 ` Robert S. White 1997-09-11 0:00 ` Don Harrison 1997-09-12 0:00 ` Robert Dewar 1997-09-13 0:00 ` Patrick Doyle 1997-09-12 0:00 ` Jon S Anthony 1997-09-13 0:00 ` Patrick Doyle 1997-09-16 0:00 ` Brian Rogoff 1997-09-04 0:00 ` John G. Volan 1997-09-04 0:00 ` W. Wesley Groleau x4923 1997-09-05 0:00 ` Patrick Doyle 1997-09-05 0:00 ` W. Wesley Groleau x4923 1997-09-06 0:00 ` Patrick Doyle 1997-09-08 0:00 ` Paul Johnson 1997-09-06 0:00 ` Jon S Anthony 1997-09-08 0:00 ` Robert Dewar 1997-09-09 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Matthew Heaney 1997-09-10 0:00 ` Patrick Doyle 1997-09-09 0:00 ` Paul Johnson 1997-09-11 0:00 ` Robert Dewar 1997-09-11 0:00 ` Veli-Pekka Nousiainen 1997-09-12 0:00 ` Paul Johnson 1997-09-14 0:00 ` Ken Garlington 1997-09-09 0:00 ` Robert S. White 1997-09-09 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-10 0:00 ` John Viega 1997-09-10 0:00 ` Matt Kennel (Remove 'NOSPAM' to reply) 1997-09-05 0:00 ` Franck Arnaud 1997-09-05 0:00 ` Patrick Doyle 1997-08-28 0:00 ` Patrick Doyle 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-08-28 0:00 ` Tucker Taft 1997-08-28 0:00 ` W. Wesley Groleau x4923 1997-08-28 0:00 ` Jon S Anthony [not found] ` <EFnK8D.Lsv@ecf.toronto.edu> 1997-08-29 0:00 ` Jon S Anthony 1997-08-30 0:00 ` Patrick Doyle 1997-08-30 0:00 ` Jon S Anthony 1997-09-01 0:00 ` Patrick Doyle 1997-08-29 0:00 ` Suzanne Zampella 1997-08-29 0:00 ` Jon S Anthony [not found] ` <340E9BA2.32B3@rbgg252.rbg1.siemens.de> 1997-09-07 0:00 ` Robert Dewar [not found] ` <3406A707.787D@dmu.ac.uk> 1997-08-29 0:00 ` Joerg Rodemann 1997-08-29 0:00 ` Ralph Paul 1997-09-01 0:00 ` Don Harrison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox