🚀 go-pugleaf

In article <1992Dec29.213057.14290@news.mentorg.com>,
bcohen@scherzo.NoSubdomain.NoDomain (Bruce Cohen) writes:
> Damn! He hit one of my hot buttons!

You too!

> In fact, you can (or at least should be able to) understand a framework
> without knowing the details of the implementation, or even the syntax of
> the implementing language.  

You are correct. At least, in theory. Unfortunately....

> A framework is an organization of parts and
> a description of how they work together; 

Indeed. And, in the case of MacApp and the TCL, the developers of these
frameworks have only shipped half of the product. They have shipped the parts,
but when it comes to delivering the description -- what little they have
shipped is woefully inadequate. 

Take for example the TCL. The shipped a significant number of classes with
the TCL 1.1 for which there is next to no documentation. Sure, there's a
little read.me file that has a brief description of the classes. But no one
at Symantec has bothered to write a description equal to the other classes
that appear in the manual.

Part of the problem is the character of the implementation languages used 
for these frameworks -- it isn't entirely the fault of the developers.

Until documentation and languages appear that are conducive to producing
concise frameworks, we'll have to continue to struggle along with wading
through the source code.

> In many situations all
> you really *need* (as opoposed to what you might want to have) to write
> an overriding method in a subclass is the signature of the method and
> a set of assertions which describe the pre- and post-conditions for the
> method.  Sure it's easier if you have some code to look at and maybe
> reuse, but you could do without that.

Sounds like you are suggesting people build frameworks in Eiffel, which
has formal mechanisms for defining pre and post conditions for all routines.

Too bad there isn't such an Eiffel implementation for the Mac.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve
Hackett.


------ Internet Message Header Follows ------
Path:
wupost!crcnis1.unl.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!olivea!uunet!hayes!bcoleman
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.oop.misc
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
Message-ID: <6606.2b41845f@hayes.com>
Date: 30 Dec 92 15:13:35 GMT
References: <1992Dec1.220344.234@physc1.byu.edu>
<1992Dec3.064131.23364@reed.edu>
<Dec.3.13.57.31.1992.18090@gandalf.rutgers.edu>
<1992Dec4.081456.13906@reed.edu> <1992Dec29.213057.14290@news.mentorg.com>
Organization: Hayes Microcomputer Products, Norcross, GA
Lines: 51