Rule #5:  Best documentation is the code. ;)

Post a reply to this message

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

Exactly.  Lexical scoping takes care of that. For languages which allow 
conveniently-definable lambdas, that is.

Post a reply to this message

Warp escreveu:
> And again, you are hacking on
> purpose, trying to bypass the compiler checks, rather than using those
> checks to catch your mistakes.

How this is any different from someone breaking a contract on purpose is 
beyond me.

Post a reply to this message

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

You missed this one:
   3) You name your private variables with the naming convention used by
      every other package ever implemented in that language, including
      the ones that define the runtime, and which every programmer knows
      bypassing means future incompatibility.

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

You already know you're using a private variable, if you're bypassing either 
global naming conventions or using reflection or something.

If the compiler actually *prevents* it, then you're locking yourself out of 
a whole bunch of metaprogramming techniques that templates aren't adequate 
to handle.

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

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

Sure. "Don't read documentation" or "forget documentation" is as bad as 
"don't document it". But if it's a naming convention used throughout the 
language, people don't do it.

How many people name their own function to add a list of numbers as
   __builtin_addlist()
in C or C++?  Why not?  Because everyone who is even a little knowlegable 
knows that two underscore names are reserved for the compiler.

>   Why is it a bad thing to make the compiler check interface breaches is
> beyond my comprehension.

First, the whole "dynamic languages" bit at the start should indicate not 
everyone has a compiler for these languages. Secondly, it eliminates a whole 
raft of useful mechanisms.  Where's the C++ library to which I pass a class 
and it generates a SOAP interface parser for that class?

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

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

Yeah, "protected" slipped my mind. It's still not hard to do if you're trying.

>> Or just using compiler-specific hackage to access the variables. 
> 
>   That has been made rather difficult in practice.

Err, has it? I can't say something like
   int * p = (int*) ((void*)(&yourInstance) + 32);
if I want access to whatever integer is 32 past the start of your class?

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

While I agree, I fail to see why using reflection as intended isn't "normal 
usage" and not "a mistake". It's not something you accidentally do. You know 
very well you're bypassing encapsulation. Not the least of which is that you 
need to give the name of the variable you want to access as a string.

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

Right. Since you said reflection violates encapsulation hard enough to make 
a program not "OO", I'm trying to figure out allowing type casts and 
assignment of arbitrary memory addresses to pointers doesn't.

Now, if the statement is "the compiler should be able to warn of external 
access to private variables, with the ability of the caller to easily 
indicate they know what they're doing," I'm 100% with you.

If the statement is "the compiler should error on external access to private 
variables, with no way to get around it," I'm 95% with you, with the caveat 
that "that's a pain in the ass way to write generic code that isn't type 
specific, because you have to write code generators instead of using the 
compiler you already have."

If the statement is "the compiler should error out on external access to 
private variables, but there should be a non-portable hacky and error-prone 
way to bypass it anyway, so you can't rely in your debugging efforts on what 
your code actually says," I'll just have to disagree with you there. :-)

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

  I really fail to see how that is different from using a *real* interface
specification, rather than just a verbal one. Except for the fact that with
a real interface the compiler can make sanity checks, of course.

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

  Yes, and these people put everything in the public part of their classes
because they don't have any idea what they are doing. In the same way as
those self-taught hackers who detest all programming paradigms.

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

  In fact, in C++ you don't even have to necessarily write "private:" at
all because members are by default private (when not inside any access
specifier block).

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

  What source?

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

  Don't write such BS. I am talking about experience. For example I have
totally changed the internal implementation of this class of mine several
times, and the public interface has always remained the same regardless,
and thus the changes have never broken any existing code:

http://warp.povusers.org/FunctionParser/

  And by "totally" I mean literally write everything from scratch. And
no external code breaks. That's the nice thing about modularity. It allows
me to do that safely.

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

  Thinking that brevity in programming is a good thing is a really common
beginner mistake. Those are the beginners who, for example, in C++ always
write "using namespace std;" to dump *everything* in the standard libraries
to global namespace because it saves them from typing 5 extra characters
later. Then you get code like this:

    i = search(first1, last1, first2, last2);

  "Woohoo! I saved typing 5 characters!" And now it's completely unclear
what this "search()" is. Is it a local function somewhere? Is it an external
function defined in some header? Perhaps it's a class which is being
instantiated? Is it a standard library function?

  Compare to:

    i = std::search(first1, last1, first2, last2);

  Now it's completely unambiguous that this is a standard library function
being called.

  Brevity is *not* always the answer. Even if I had to write "private" in
front of every single function and variable declaration (as you have to do
in some languages), I would still do it. (Fortunately I don't have to.)

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

  I disagree. There's no modularity if you can't enforce access rights.
Data hiding is an integral part of modular design. Verbal agreements are
worth absolutely nothing.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > 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.

> You missed this one:
>    3) You name your private variables with the naming convention used by
>       every other package ever implemented in that language, including
>       the ones that define the runtime, and which every programmer knows
>       bypassing means future incompatibility.

  I still prefer option #1. It's not like it would exclude option #3, so
you get the best of both worlds: Clarity in naming conventions, *and* the
compiler checking the integrity of the interface.

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

> You already know you're using a private variable, if you're bypassing either 
> global naming conventions or using reflection or something.

> If the compiler actually *prevents* it, then you're locking yourself out of 
> a whole bunch of metaprogramming techniques that templates aren't adequate 
> to handle.

  And if you don't prevent it, you are locking yourself out of ever trying
to improve your module (without breaking tons of existing code).

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Rule #5:  Best documentation is the code. ;)

  In fact, precisely. If the code supports telling "this is the public
interface", what better documentation.

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Warp escreveu:
> > And again, you are hacking on
> > purpose, trying to bypass the compiler checks, rather than using those
> > checks to catch your mistakes.

> How this is any different from someone breaking a contract on purpose is 
> beyond me.

  It's different because if you do it by mistake, nothing will tell you.
(Except when your code breaks when you update the library.)

-- 
                                                          - Warp

Post a reply to this message