Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.misc
Subject: Re: From Modula to Oberon (Really data abstraction in C)
Message-ID: <1220@PT.CS.CMU.EDU>
Date: 24 Mar 88 22:59:34 GMT
References: <2827@enea.se> <1557@pasteur.Berkeley.Edu> <3764@bloom-beacon.MIT.EDU> <1217@PT.CS.CMU.EDU>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 35


 > I agree with your first point, but it's not so simple to do things
 > in a language that wasn't designed to support them cleanly.  The Guttag &
 > Liskov book spends a chapter or so discussing doing data abstraction
 > in Turbo Pascal.
 > I'd rather spend my time writing code than worrying about how to map my
 > programming methodology onto a language that doesn't support it neatly.
 >

	In my opinion there's just one misfeature that makes data abstraction
   ugly in C - scoping.  C only has two levels, global and local.  I
   would prefer a much finer control. Such as what is provided by module-2
   and Common Lisp.

 > 
 > When I make my own mapping, it also makes it harder for someone else to
 > come along later and understand what I did, unless I document my
 > techniques and experiences.

	You have to map abstract structures to actual structures at some point
	in time whether it's C or CLU.  As long as you adhere to the
	access interface, you gain/lose nothing in either language.
	If this sentences refers to operand over loading as a means of
	clearity of the access interface, well operand over loading has
	its pitfalls as well as gains.  

 > 
 > [I must admit to some bias here, I feel much more productive using CLU
 > than C.  Other than interoperability with certain existing code, I can't
 > see any reason to use C when CLU is available.]

  Try code speed, progaming tools, debugger ....  
-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu