Darren New <dne### [at] sanrrcom> wrote:
> CLOS doesn't do this, because people who use LISP are usually pretty good 
> programmers.

  No. Crappy programmers (self-taught "hackers") want everything exposed and
can't understand the reasoning behind data hiding. Good programmers understand
this reasoning and for that reason use data hiding and abstraction.

> > If the
> > internal structure of the object is exposed to the outside, you lose most
> > of the benefits of modularity.

> Like, in unsafe languages, where a stray pointer can change private 
> variables without going thru the class methods? :-)

  No. The reasoning behind data hiding in modular thinking is completely
independent of the language used. It has to do with program design.

  If you expose the internal structure of a module to the outside, then
there's a big chance that outside will start making *assumptions* about
this internal structure. As an example, a module describing the concept
of a "color" might have four integral variables as members, one for each
color component. If this fact is exposed to the outside, then there's a
big chance that some code somewhere will assume that the "color" module
has four integral member variables with certain names.

  If this happens, then you can't change the internal implementation of
this module without breaking existing code. For example, if you wanted
to change the color components to floats, or you would want to pack the
color components into one single integral value, you will most probably
break existing code (especially probable in the latter case, as the
amount and names of the member variables will change drastically).

  If you can design the absolutely perfect module which will never change
its contents and will suffice for years to come, then by all means make
all members public. Us mortals will try smarter techniques.

> C# and Java both have reflection that let you get to private members from 
> outside.

  Thus it's one reason why the design of these languages is badly broken.

> C++ not only lets you return pointers to private members

  Only if the class itself explicitly does so. You can't get to the private
members *from the outside*. (Well, at least not without some serious
hacking.)

  It's usually considered bad design in C++ to return pointers to members.

> Now, ya see, I see the point of modularity is to let me reason about the 
> code. If I have a private integer X, and the only things I set it to are 0, 
> 1, or 2, then I should be able to have a switch with those three cases and 
> never miss one. Or, for a better example, if I have a buffer, and my class 
> is the only thing that writes to the buffer, I can ensure I never have a 
> buffer overflow. This isn't the case in C++ any more than it is in LISP or 
> Python. The only difference is, in LISP it's much harder to break by 
> accident.  I don't see the advantage of making variables private if the 
> privacy isn't enforced well enough to give me more guarantees about the 
> program's execution. It's like having type declarations that aren't checked 
> at compile time or runtime - what's the point?

  I don't understand what you are saying. If a class in C++ does not expose
a member array, then you can't get to that member array from the outside,
and if the class' own functions are properly designed, no buffer overflow
is possible (precisely because you *can't* access the array from the
outside).

> What do *you* think modularity is good for, that simply saying "stuff that 
> starts with an underline is private to the class" isn't adequate? I'm 
> seriously asking, because I'm wondering if I'm missing something.

  You might be able to control your *own* code from not misusing public
variables (and you might never make mistakes), but it's more difficult to
control someone else.

  If you need to tell someone else "don't access member variables whose
name start with an underscore", that's just plain stupid. You should be
able to tell that by making the *compiler* enforce it.

-- 
                                                          - Warp

Post a reply to this message

I'm sorry, but that simply doesn't follow.  If the guy is stupid enough 
to use things not in the interface I give him, it's his problem if he's 
f*cked down the road.  But I agree with you:  dumb programmers like that 
should wear a straight jacket, no doubt.

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Yes.  Straight-jackets are generally viewed as a limiting "feature" by 
> people who actually know how to program rather than being a low-paid 
> drone.

  No, data hiding is seen as "limited" by self-taught hackers who don't
know jack s**t about programming. Those people just can't understand what's
the idea, and want everything to be accessible.

>  What really amazes me is when very smart programmers actually 
> enjoy being in the jacket and ask for more. :P

  I enjoy being able to create modules which I can safely improve later
without the fear of breaking existing code. And I'm talking from actual
experience, rather than theorethical handwaving.

> The best I've ever read on the subject comes from Larry Wall:
> "The trend over the last 25 years or so has been to design computer 
> languages that enforce a state of paranoia. You're expected to program 
> every module as if it were in a state of siege.

  What a load of BS.

> Of course, such attitude would not stand the barbarism going on in 
> enterprise by thousands of code monkeys typing a bad rerun of 
> Shakespeare, but for one guy or 2 in the know alone working on a private 
> project, giving up all bureacratic measures for you not to shoot your 
> own foot may lead to an increased productivity with no sensible bug issues.

  Increased productivity... until the day that you actually need to heavily
change some module because of new requirements or improvements, and you end
up breaking thousands of lines of code which are carelessly using public
members as they please.

  Of course rather than admit their design mistake, they will just use some
fancy term for this, such as "refactoring".

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> I'm sorry, but that simply doesn't follow.

  Why not? Having the compiler check for breaking of agreements (eg. "don't
access these variables") is much better than oral agreements. The compiler
is much better at catching mistakes than you are.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>   No, data hiding is seen as "limited" by self-taught hackers who don't
> know jack s**t about programming. Those people just can't understand what's
> the idea, and want everything to be accessible.

It's not because it's accessible that it is going to be used.  It is 
only accessible because the implementation didn't care to bother putting 
loads of chains and belts and bureaucratic measures that are there only 
for the sake of bad programmers who can't understand the concept of 
interfaces and have to have their knees broken so they can't jump the fence.

For people who know it better, the lack of such measure does not mean 
irrestrict access to things, it simply means less stupid typing to make 
the compiler happy.  Modularity is conserved.

>   I enjoy being able to create modules which I can safely improve later
> without the fear of breaking existing code.

Why would you fear breaking your own modular code with clear interface? 
  Are you yourself using things you shouldn't?  Why are you blaming the 
implementation then?

>   Increased productivity... until the day that you actually need to heavily
> change some module because of new requirements or improvements, and you end
> up breaking thousands of lines of code which are carelessly using public
> members as they please.

It's all about scope.  If it's public, it should be used.  If it's not, 
you shouldn't.

Scheme/Lisp has no problem with any of that though.  First because of 
lexical scoping:  if you need to use an accessory function, you can 
simply declare a local lambda in the outer function and no outside 
functions will reach it.  Second, because modules are truly modules and 
though you may declare many functions, you only explicitely export some 
of them.  And functions not exported are truly not exported, you can't 
reach them, using whatever dirty hacks you wish.

Post a reply to this message

Warp wrote:
>   Increased productivity... until the day that you actually need to heavily
> change some module because of new requirements or improvements, and you end
> up breaking thousands of lines of code which are carelessly using public
> members as they please.

In languages other than LISP (say, Python or PHP or whatever), this is 
handled by having a naming convention saying what variables are to be 
treated as private.

I'm not sure I see the benefit of "I use private: in my C++ classes" to "I 
put an underscore before private names in my classes."  Other than a touch 
of readability (which many C++/Java/etc programs violate by tacking things 
like "m_" to the front of every member variable) I don't see a whole lot of 
difference.

Certainly if should-be-private members are exposed as public but don't 
document to the user which are private, that's a problem.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

Fredrik Eriksson wrote:
> Except that the compiler is not required to generate the same layout in 
> those two cases, so you would still depend on compiler-specific knowledge.

You still get subclasses. And of course there's always the hack of declaring 
a subclass. Or just using compiler-specific hackage to access the variables. 
or the infamous "#define private public". But correction noted. It's just 
irrelevant to the point I was making. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Warp escreveu:
> > nemesis <nam### [at] gmailcom> wrote:
> >   No, data hiding is seen as "limited" by self-taught hackers who don't
> > know jack s**t about programming. Those people just can't understand what's
> > the idea, and want everything to be accessible.

> It's not because it's accessible that it is going to be used.

  Yeah, sure. If you are the *only* person making the entire program, then
perhaps that might be the case.

>  It is 
> only accessible because the implementation didn't care to bother putting 
> loads of chains and belts and bureaucratic measures that are there only 
> for the sake of bad programmers who can't understand the concept of 
> interfaces and have to have their knees broken so they can't jump the fence.

  So in your opinion the concept of "interface" is a verbal agreement about
what should and shouldn't be used from a module? *That* is what sounds like
bureaucracy to me.

  And why is a verbal agreement better than telling the compiler about the
interface?

> For people who know it better, the lack of such measure does not mean 
> irrestrict access to things, it simply means less stupid typing to make 
> the compiler happy.  Modularity is conserved.

  In Utopia, maybe. In the read world, not so.

  And I don't consider having to write "private:" once to be significantly
more typing. If I had to document what you should and should not access
in the module, *that* would be significantly more typing. And the kind of
text which most people will not read anyways.

> >   I enjoy being able to create modules which I can safely improve later
> > without the fear of breaking existing code.

> Why would you fear breaking your own modular code with clear interface? 

  Maybe you, Mr. Perfect, never make mistakes. I like the compiler telling
me possible mistakes, especially since telling the compiler what the interface
of my module is, is rather simple.

  Also, if I make a module for others to use, how can I guarantee that
I can change the implementation later without breaking code others have
written? There are two options:

1) I write "private:" once in my class definition.

2) I write extensive documentation about the subject and hope people will
   read it and obey it. Many people won't.

  Which one of these two options is easier and less trouble?

> >   Increased productivity... until the day that you actually need to heavily
> > change some module because of new requirements or improvements, and you end
> > up breaking thousands of lines of code which are carelessly using public
> > members as they please.

> It's all about scope.  If it's public, it should be used.  If it's not, 
> you shouldn't.

  And what's wrong with the compiler telling you if you try to use it
regardless? I really can't understand that.

  The compiler is not limiting anything that you aren't *already* limiting
by your verbal agreement. The only thing the compiler is doing is checking
that the agreement is not broken. Why that is a bad thing is beyond my
comprehension.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Certainly if should-be-private members are exposed as public but don't 
> document to the user which are private, that's a problem.

  I thought you were old enough to know some basic facts of life:

Rule #1: People *don't* read documentation.
Rule #2: Read rule #1.
Rule #3: Even if people read documentation, they do not have photographic
         memory and they forget.
Rule #4: Humans are imperfect and make mistakes.

  Why is it a bad thing to make the compiler check interface breaches is
beyond my comprehension. It's enormously easier to do than writing some
documentation and *hoping* that people will read and obey it, and never
make mistakes.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> I'm sorry, but that simply doesn't follow.
> 
>   Why not? Having the compiler check for breaking of agreements (eg. "don't
> access these variables") is much better than oral agreements. The compiler
> is much better at catching mistakes than you are.

Now I (think I) understand the root of our disagreement.  I'm thinking 
about functional programming here with only functions accessible per 
interface, you're thinking about what variable can be accessed and 
whatnot in a severely mutable setting.  It all becomes really hard when 
you allow state to dominate.  So hard that even very experienced 
programmers can face dificulty handling it all, thus having to invent 
all sorts of levels of accessibility rather than just rely on lexical scope.

Post a reply to this message