🚀 go-pugleaf

In article <1992Sep2.045715.5803@panix.com> you write:
>In <19385@ector.cs.purdue.edu> kane@cs.purdue.edu (Christopher Kane) writes:
>Although the quoted passage is incorrectly edited, it is usually NOT
>a good idea to repeat the interface in the implementation.

The quoted recommendation in our book reflects the voice of pragmatic
experience, not theoretical necessity. Healthy code is read more than it is
changed/written. And having to read two files, one for data & procedural
interfaces and the other for procedural implementations, really is a
hassle.

There was a time when the compiler didn't allow data declarations in the
interface file, but I started putting data declarations in the .m file
enclosed in ifdefs, solely as a readibility aid. The new scheme is much
better because it at least warns if the two are out of sync.

Finally, on theoretical grounds alone, data declarations is implementation,
not interface. Putting it in the .h file was a compromise, bowing to the 
compiler and not staying pure to the concept.

The very earliest versions of Objective-C (circa 1982) didn't make this
compromise. Everything went into a single file, and the compiler
derived an interface database from that.

We eventually retreated from this
posotion when it became painfully obvious that the compiler could never
be omniscient about how to maintain its database, and by hiding this,
users failed to understand the implications of
deleting/renaming/changing class info, especially in multi-person
projects.

Brad Cox, Ph.D.
Information Age Consulting
bradcox@infoage.com
703 968 8229 voice
703 968 8798 fax

Program on Social and Organizational Learning
George Mason University
Fairfax VA 22030
703 993-1142