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

Darren New <dne### [at] sanrrcom> wrote:
> You still get subclasses. And of course there's always the hack of declaring 
> a subclass.

  A subclass can't access the private members of the base class.

> Or just using compiler-specific hackage to access the variables. 

  That has been made rather difficult in practice. If you are *intentionally*
trying to break your program, then that's your choice, of course. However,
in normal usage it's useful if the compiler checks that you don't make
mistakes.

> or the infamous "#define private public".

  Whether your program will link after that can depend on the compiler.
It's certainly not standard-conforming. And again, you are hacking on
purpose, trying to bypass the compiler checks, rather than using those
checks to catch your mistakes.

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> 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.

  Not all member functions have to be public either. It's extremely common
for a class to have private member functions which are part of its internal
implementation and not even intended to be part of the public interface.

  I would say that being able to define private member functions is equally
important as being able to define private member variables.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> 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.

Like I said, if the dumbass wants to use things not in the interface, 
it's his risk.

>   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.

Not bureaucracy at all.  Just a list of names of functions a module 
provides.

>> 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.

Indeed.  In real enterprise world we got people who don't enjoy nor know 
how to program, programming.  Or, should I say?, fill up a few forms and 
allow an IDE to generate the code.  It will spill shit all over, true.

>   And I don't consider having to write "private:" once to be significantly
> more typing.

Indeed, Delphi and C++ are yet more zippy at that, not so much for those 
poor Java souls... you also forgot the data type declarations.

> If I had to document what you should and should not access
> in the module, *that* would be significantly more typing.

This coming from a guy whose favorite language needs for one to provide 
the source and the header file.

 > And the kind of
 > text which most people will not read anyways.

It's usually the first thing one sees when opening a module.  (export 
foo bar boz frob etc)

>   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?

Don't change the interface.  Of course, if the implementation is changed 
in such a buggy way as to totally alter the behaviour, same interface 
doesn't mean jack.

>> 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.

Nothing wrong except quite a few more tiresome and bureaucratic measures 
before actually writing anything.

>   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.

I was not saying that is bad.  I was just reacting to this:  "Your 
definition of object-oriented programming may vary, but in my view
data hiding, ie. modularity, is an integral part of OO programming."

Modularity is still there regardless of dumb programmers ripping their 
contracts and no middleman to prevent them doing so.  But I'm thinking 
here on a typical Scheme module of old, before true modules, and where 
all you had was a list of functions and lexical scoping, not a C plain 
text file with lots of variables and variable-dependent functions lying 
all around.

Post a reply to this message

Warp wrote:
>> 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.

OK. I guess you look it as "if you bypass the documentation and access 
members not documented, I have to support your brokenness forever." I look 
at it as "if you're coding from the implementation instead of the 
documentation, you get what you deserve" combined with "don't make me debug 
my code when the bug is in your code."

>   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.

Sure. Most of these languages (a) document what's public and what isn't, and 
(b) have a language-wide naming convention for it.  That is, after all, what 
C++'s 'private' tag is - a naming convention.

>   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.

I think it's more a trade-off than you make it out to be.

>> 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*.

That's why I said it wasn't much of a breakage in my view.

> (Well, at least not without some serious hacking.)

Running off the end of an array is "serious hacking"? I wouldn't think so.

>   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,

int * p = (int *) 0x123456;
*p = 27;

Find the bug in your code that's setting that member variable to 27.

How about
// Your code...
class xyz {
   public: int[10] x;
   private int y = 0;
}

// My code
  xyz pdq;
  pdq.x[10] = 27;


>   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.

Sure. See above examples.

>   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.

I agree, except for the fact that you're using C++ as an example. :) C++ has 
it's own different lack-of-modularity problems. If the compiler actually 
*enforces* that the member variables you declare private can only be changed 
by your own methods, that's great.

"don't access member variables whose name starts with an underscore" is the 
kind of rule that's enforced all through a codebase or a programming 
language. The little extra warning the compiler is going to give you is 
generally not of much benefit if someone's going to violate that rule 
anyway, IME.  In other words, if they really need to violate the privacy of 
your class, they're going to do it in C++ almost as easily as they do it in 
something like Python or LISP.  The compiler doesn't enforce the 
encapsulation in C++ - it just gives warnings when you use a variable name 
that's private. There's no enforcement at runtime, and plenty of back doors 
at compile time. Contrast with, say, C#, where you don't even know what the 
private variables are named, and you couldn't access them if you did, 
because the runtime enforces that - there, the only backdoor is the 
reflection libraries that specifically are bypassing the privacy checking 
system. Using reflection (or explicitly assigning to _private members) isn't 
any more common or more prone to abuse than ((int*)0x12345)=27; is, 
particularly because the user has to explicitly know they're violating 
encapsulation when they write the code.

Granted, if you don't *document* in a universal kind of way what's public 
and what isn't, you're leaving yourself open to abuse.

But there are a lot of people who don't want to write a ton of boilerplate 
code for a function that could be automated, so they're willing to say "if 
you use introspection  to read and write my structure over the wire, be 
aware it may change in other versions."  It's better to say "this will break 
with future versions" than to say "I'm going to write 5000 lines of 
boilerplate code to allow clients to send my values over the internet or 
into databases."

There are also a whole bunch of assumptions in your classes that someone is 
going to rely on that you're not going to be able to prevent. SimCity 
assumed memory you called free() on would still be valid until the next 
malloc(), which is obviously a bad assumption yet still has to be supported 
by the infrastructure if you expect to run simcity on later versions of the 
OS. If you store your object outside of memory or interact with any other 
objects, you're also going to have random dependencies created - someone is 
going to have to change database schemas to store your objects in a 
database, or change buffer sizes if you switch from JSON serializiation to 
XML serialization without otherwise changing your interface. There will be 
people who assume your class only invokes their getter method once, if 
that's how you first code it, and if you change to invoking it twice, they 
may very well fail out (because they're pulling the next row from a database 
for each invocation, say). Or, in short, you can't protect against bad 
programmers, and anyone half-decent isn't going to be frobbing private 
variables to start with, IME.

-- 
   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