From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: kennel@msr.epm.ornl.gov (Matt Kennel) Subject: Re: C/C++ knocks the .... Date: 1996/02/22 Message-ID: <4gicoc$cqi@stc06.ctd.ornl.gov> X-Deja-AN: 140637793 references: <4g2r2r$ded@stc06.ctd.ornl.gov> organization: Oak Ridge National Lab, Oak Ridge, TN newsgroups: comp.lang.ada Date: 1996-02-22T00:00:00+00:00 List-Id: Tucker Taft (stt@henning.camb.inmet.com) wrote: > Matt Kennel (kennel@msr.epm.ornl.gov) wrote: > : ... > : As for Ada, I'm not yet fully convinced abou the package vs > : type thing. C++ might be ugly because you can have all sorts of > : elements outside classes, but in Eiffel you cannot. > : Eiffel intentionally makes the unit of namespace and of type > : the same. > : The question is, do the benefits of having them completely separate > : make up for the extra work and complexity of having to double the > : number of 'mental units' in most idiomatic programs. (and without > : MI you have to go a bit further) > : Yes, Ada has them on orthogonal axes. Eiffel only has "one axis" > : but it may empirically be along the major princpal component with > : only a small deviation in other directions. > On the other hand, various Eiffel implementations have felt the > need to add yet another language on top for doing "configuration" > of large systems (I think it is called "GRACE"?). This seems > to indicate that programmers have a need to deal with larger groupings > than that represented by a single class. Although one could conceivably > just create larger and larger classes, at some point the model of a "type" > breaks down, whereas the notion of a package scales nicely to the > notion of a subsystem, as in Ada 95. No argument. However, Eiffel programmers won't have to deal with these much much less often than an Ada programmer will have to deal with packages. Perhaps only when the # of classes starts to exceed a few hundred. You can write many substantial eiffel programs without needing class categories. Quick test. Your boss' boss comes in unexpectedly. He(she) asks out of the blew "so what is the structural organization of your program?" hands you a felt pen and points you at the white board. Do you draw most blobs for packages, or for types? Don't think. What was your reflexive response? I'm guessing that most Ada programs would be described as packages not types. The 'intellectual unit' in A95 feels like packages more than types. Suppose you wanted to have 'invariants' as in Eiffel. Where would they go? In Eiffel, when you combine package and type, it becomes very clear whose routines are "mine" and whose routines are "theirs", and hence it's clear exactly where and when all the preconditions and postconditions and invariants ought to be checked. This is a major point of "programming by contract." For instance, take class invariants. These are checked after somebody *outside* the type makes a call; but if a method owned by the type makes a call to another method owned by the type that MUST NOT generate an invariant check. Why? Because that other method might be 'preparing' the internal state to be acceptable by the invariant, but non-trivial invariants cannot be expected to hold everywhere during the execution of a class method. (otherwise you can't do anything). Would an Ada95 + pre/postconditions + invariants put them with types or with packages? > It is interesting to note that Java has the notion > of "package" for defining groups of classes. This seems > like a reasonable compromise, though it still loses out on some of the > other advantages of defining abstractions using a package rather than a > class, such as symmetry of parameters in binary operations, and elimination > of the pesky "once" or "static" qualifiers of Eiffel/C++/Java that are > needed to turn a "component" of a type into a component of a module. Why are these 'pesky'? C++'s name of "static" is dopey, "once" is better, Sather calls them "shared". I agree about the binary operations. I have an alternative syntax proposal for eiffel like langauges though to help with the binary operator problem: "object.method(argument)" should have the alternate syntax "(object method argument)" with required parentheses. No different semantics from ordinary function call. So "(vector cross vector)" would be OK with very little change to the language. > -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ > Intermetrics, Inc. Cambridge, MA USA