Subject: Re: OT: how many venomous posts (Ex: Re: hashtable w/o keys stored...) From: Erik Naggum <erik@naggum.no> Date: 1999/01/17 Newsgroups: comp.lang.lisp Message-ID: <3125569294842212@naggum.no> * David Bakhash <cadet@mit.edu> | 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. #:Erik -- SIGTHTBABW: a signal sent from Unix to its programmers at random intervals to make them remember that There Has To Be A Better Way.