Subject: Re: OT: how many venomous posts (Ex: Re: hashtable w/o keys stored...)
From: Erik Naggum <>
Date: 1999/01/17
Newsgroups: comp.lang.lisp
Message-ID: <>

* David Bakhash <>
| Isn't this why OO language designers originally wanted data hidden in
| the first place?

  since "originally" may well refer to the SIMULA work in the late 1960s
  and I was, uh, fortunate enough to have SIMULA as my freshman language at
  the University of Oslo, maybe I should recognize it, but I don't.  in
  fact, I haven't found the _one_ argument or the _one_ set of arguments
  for data hiding that would have made it so prevailing.  there are lots of
  arguments, some of them mutually contradictory, for why you don't want to
  share some of your slots or want to control the way they are accessed or
  inherited.  in practice, people aren't able to charter the consequences,
  either, and they make serious mistakes in what's hidden and what's not,
  but rather than to see that who's owning what is a late-binding property
  of a class, they set out to assume ownerships from the very beginning.
  all I have gotten out of this is that "it's mine!  all mine!" somehow
  explains everything.

  if ownership were so important, why does it change so much?  the one
  property that changes the most in class definitions is who can access the
  slot directly, according to some report I read in 1994 when I was trying
  to figure out why C++ hurt so much.  and why do people go to such lengths
  to violate the access barriers when there's something in there that they
  actually need to get at?  remember that this is stuff that happens inside
  a team, not something you do to keep outsiders out.  although 2/3 of all
  goods stolen from shops are reportedly stolen by its employees, I don't
  see the need to _make_ "information criminals" out of team members.

  imagine people who behave like compilers: "do you sell thiocyanates?" (to
  take something that you might legitimately want to hide from the public.)
  "no."  that's, OK, isn't it?  you just go elsewhere, right?  "yes, but
  not to you."  do you ask why?  do you get just a wee bit annoyed?

  what I think would make sense in this data hiding business is _real_
  hiding.  in C++, the compiler complains about access violations, not that
  the name is effectively _undefined_.  if you inherit from two different
  classes that have public and private slots with the same name, what
  happens?  I think the obvious answer is that the private slot would only
  be visible to the methods of the class to which it was private.  my
  reading of the C++ standard says that slot-merging occurs no matter what
  the status of the slot is.  _that's_ annoying.

  indicentally, I remember that I thought very early on that all this type
  declaration nonsense was really a half-measure: if the compiler _knew_
  what the type of something was, why was it so bitchy about declarations?
  in today's Common Lisp terms, I wanted to declare everything of type T
  first, but still use only one type per variable.  the compiler should
  then tell me which types I had used (and could complain about multiple
  types stored in the same variable), and that could be part of exported
  interfaces.  anyway.

  so, I don't think the desire to see data hidden was really well founded
  _before_ it was invented, because a number of clearly distinct reasons
  for wanting it that way have emerged after the fact, none really
  explaining why somebody came _up_ with the idea.  the needs it covers are
  probably mostly a personal preference, or perhaps fear.  fear is a great
  motivator for protecting stuff that doesn't need protecting.

  SIGTHTBABW: a signal sent from Unix to its programmers at random
  intervals to make them remember that There Has To Be A Better Way.