esg@mtx5a.UUCP (ed gokhman) (06/27/86)
Hi: I am working on a fairly large project that involves about 40 software engineers. What I would like to do is to simulate data abstraction facilities as a design guideline. Note, for various reasons we HAVE to use C for time being. The draft-proposal is to use file scoping and conditional preprocessor clauses to stop private members of a class of data/functions/types from external linkage. I understand that this is far from C++, but, again, for reasons beyong my control C++ is out of reach for now. I read some semi-optimistic semi-pessimistic opinions on such approach. What does the network think about it ? I would appreciate any opinions, suggestions, critics, examples, etc. Thanx in advance, Ed Gokhman
john@frog.UUCP (John Woods, Software) (07/01/86)
> What I would like to do is to simulate data abstraction > facilities as a design guideline. Note, for various > reasons we HAVE to use C for time being. The draft-proposal > is to use file scoping and conditional preprocessor > clauses to stop private members of a class of data/functions/types > from external linkage. > I have bad news for you. This will not simulate data abstraction. This will _be_ data abstraction. Unless, of course, you use the phrase "Data Abstraction (TM)" in the way that people who do research into it do, where you MUST be wrapped in compiler provided straight jackets and given a crayon to hold in your teeth with which to write. But this approach (discipline added to an existing language) was what was used when I took "6.170 Software Engineering" at MIT, from Barbara Liskov (of CLU fame): we used a garden-variety PL/1 compiler with some stylistic rigor to provide protected data types, because the CLU compiler hadn't been finished yet. (And in my opinion, from having to work with the CLU compiler itself a couple of years later, it was easier to do it in PL/1, because (A) the CLU compiler still does not prevent programming mistakes, just certain classes of them, and (B) the CLU compiler prevents certain reasonable programming constructs, just simply because they didn't occur to the compiler designers. After all, look at fopen() and friends in the standard C library -- when was the last time you ripped the top off a FILE * to look inside it (that is, if you aren't a UCB or Bell Labs programmer [*])? * Some notable programs from each of these caused me to have to rewrite a from-scratch stdio library that otherwise worked perfectly well (even better than the original in many respects) to use a structure that was similar to the regular FILE structure, with much anguish being added to preserve the old (improved) functionality while making sure that the structure fields were manipulated the same way that these excremential programs expected!). -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." Jeff Raskin, interviewed in Doctor Dobb's Journal
esg@mtx5a.UUCP (ed gokhman) (07/04/86)
* I understand that this is far from C++, but, again, for * reasons beyong my control C++ is out of reach for now. Noted degree of flaming over this phrase promptly mailed to me by Bjarne, pointed to a need for clarification. The "reasons beyong my control //..." do not have ANY hidden devaluation of C++. We're talking about limited and/or cosmetic changes to the existing monsterous state-of-the-art revolutionary "if (tu5_lL == 3)" C-project over the "aggressive marketting schedules". The last phrase has hidden non-C-related devaluation. Thus, THE TIME IS THE REASON ABOVE IT ALL. Sorry, Bjarne, and thanx for your comments, anyhow. Ed