Newsgroups: comp.object,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!hudson.lm.com!newsfeed.pitt.edu!dbisna.com!psinntp!psinntp!psinntp!psinntp!merlin.hgc.edu!jcm
From: jcm@hgc.edu (James McKim)
Subject: Re: Has C++ had its day?
Message-ID: <1995Jun19.142952.326@merlin.hgc.edu>
Sender: usenet@merlin.hgc.edu (Action News Central)
Organization: The Hartford Graduate Center
References: <3rdco8$5ve@hgc.edu> <3rsnp8$bqj@wally2.hti.net>
Date: Mon, 19 Jun 1995 14:29:52 GMT
Lines: 62
Xref: glinda.oz.cs.cmu.edu comp.object:33100 comp.lang.smalltalk:24778

In article <3rsnp8$bqj@wally2.hti.net> gharvey@news.neosoft.com (Greg Harvey) writes:
>James McKim (jcm@hgc.edu) wrote:
>: This is certainly true of Eiffel, but my understanding was that Smalltalk
>: did not have a designable public interface. I thought that in Smalltalk
>: all methods were automatically public and all attributes automatically
>: private. If this is true then I guess the tool described above would just
>: extract the method signatures. Of course the typical Eiffel tool does
>: much more than that. It extracts the full public interface consisting of
>: the signatures and specifications (preconditions, postconditions, and 
>: invariants) plus selected comments. Further the browser will "flatten"
>: classes so that the programmer can see the whole class, including the
>: parts defined in ancestors. And much more.
>
>: If I'm wrong about Smalltalk's public interface, please set me straight.
>
>The base Smalltalk language works as you've described.  GUI builders like
>Visualworks and WinBuilder and "Parts" builders like in VisualAge provide
>SOME extra-language segmentation between interface and implementation.

Ok. Thanks for the clarification.

>
>Someone else commented that Eiffel is like Ada in its interface specification.
>I need to add that the compilation requirements for Ada make it a very strange
>bird when you discuss the spec v. body relationship.  For example, the
>Rational Delta environment implements a configuration table that relates the
>exported specification of a set of packages to the implementation behind those
>set of packages.  Sounds great, and it is intended to minimize recompiles and
>maximize the Delta environments incremental compilation.  One fallacy.  If
>the specification changes for even one package in the set, the transitive
>closure of ALL bodies dependent on that set must be recompiled.  Rational

Hmm.. The Eiffel implementations that I heve seen work on a per class basis
rather than a per set-of-classes basis. That is, if you change the spec
of class C only those classes that depend on C will be recompiled. I don't
think any of them work perfectly in this regard, but generally a small
change in the spec of one class does not result in a major recompile.

>employees admitted that limited changes, in essence, to comment changes and
>code changes that did not modify any of the spec-dependent information.
>
>The caveat is:  beware the cohesion between interface and implementation.

Hmmm... Well the Ada and Eiffel implementations could be better but surely
you _want_ to recompile the code that truly depends on a modified spec, yes?
After all this is code that may well have to change in response to the 
change in spec.

>
>Greg Harvey
>(gharvey@rwi.com)

Hope this helps,
-- Jim

[..]

-- 

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     Co-editor of Eiffel Outlook 
Internet:  jcm@hgc.edu        Subscribe early and often!
