Path: utzoo!mnetor!uunet!husc6!umix!rutgers!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: A bad design decision early on in A
Message-ID: <47000028@uxe.cso.uiuc.edu>
Date: 2 Jan 88 15:45:00 GMT
References: <1322@sugar.UUCP>
Lines: 25
Nf-ID: #R:sugar.UUCP:1322:uxe.cso.uiuc.edu:47000028:000:1336
Nf-From: uxe.cso.uiuc.edu!mcdonald    Jan  2 09:45:00 1988


>	But they do - they add data hiding.  A library can provide
>	types such as time_t and addr_t for data that is generated by
>	some library routines and used by others, and *you* don't have
>	to know what the type is.  If the variable won't fit in a
>	scalar on your machine (either because it's too big, or because
>	you've got a segmented architecture or perverse operating system),
>	and you've disallowed structure assignment, *you* may have to
>	know what the structure looks like inside.

Data hiding is the worst idea ever invented. I really hate it when I find
something declared as a "time_t", or , worse, those awful structures
used by VMS C for system calls. Then one has to go back through some long
chain of garbage to find what they really mean. Luckily, this sort of
stuff is not rampant in the C community; if you want to experience it
in its full hideousness, write a program for the Macintosh; the notorious
system manuals are written in (ugh!) Pascal, with EVERYTHING a different,
useless, type. Horrible.

time_t itself is a rather ok idea, and I think one should be able to pass
structures. What I object to is the actual "hiding" of the definition
(in the sense of making it hard to find - it's usually in some 50 kilobyte
header file that bogs down the compilation of every program that uses it.)

Doug McDonald