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

If you're using an underscore-prefixed member in Python, you *know* it's
private. It's not "done by mistake".

Plus, those aren't in the documentation, so you'd have to read the source
code to figure out their names.

Post a reply to this message

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

It's an underscore or something else clearly visible in the offending
(= private-data-using-) code, not an oral agreement.

Post a reply to this message

Nicolas Alvarez wrote:
> If you're using an underscore-prefixed member in Python, you *know* it's
> private. It's not "done by mistake".

Actually, to use C++ terminology, that makes it protected. Two underscores 
makes it private. :-)

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

Darren New wrote:
> Warp wrote:
>>   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;

Undefined behavior.

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

Undefined behavior.

Post a reply to this message

Warp wrote:
>   Deliberately hacking yourself around the compiler checks requires more
> malice than using a public member variable which simply "shouldn't"
> access.

Deliberately accessing a private member through reflection is harder too.
And it's not "malice".

Deliberately accessing a private member by typing its name with the
underscore is not hard at all, but you'll know you're doing it, and if it
breaks it's your fault :)

Post a reply to this message

Nicolas Alvarez wrote:
> Undefined behavior.
> Undefined behavior.

Certainly. And that's my point. The C++ standard doesn't say "you can't get 
to private members of a class."  It says "We're not going to tell you a 
reliable and portable way of doing so."  That doesn't mean you can't access 
private variables - otherwise, we wouldn't have buffer overflows clobbering 
private variables in exploits, would we?

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

Darren New <dne### [at] sanrrcom> wrote:
> >   You are nitpicking, and you know it.

> No, I really don't understand. You seem to be arguing that a universal 
> naming convention isn't sufficient to say you have encapsulation, but a lack 
> of ability to keep others from changing your private variables by accident 
> is not a hindrance to encapsulation.

> You seem to be saying that it's "unmodular" to say you can only violate 
> encapsulation on purpose via complex library routines intentionally designed 
> for metaprogramming, but it's modular to let people violate encapsulation by 
> accident?

  Actually I'm not saying that. I have nowhere saying that.

  I started by defending data hiding principle in the object-oriented/modular
programming paradigm, and stressed that this principle is completely
independent of the language used.

  Then somehow you started talking about C++ in particular and somehow the
conversation was drifted from a programming paradigm in general to the quirks
in C++ in particular. I have nowhere defended C++ in particular, but data
hiding in general, as a programming technique.

  Your argument against this technique seems to be "since you can't completely
guard against it in C++, it's as good as not having data hiding at all". As
if C++ had anything to do with this issue.

> >   If you write normal, standard-conforming C++, you can perfectly well
> > enforce access rights.

> Um, no, really, you can't. How do you prevent me from corrupting your 
> private variables with a wild pointer?

  If you write standard-conforming C++, you won't have a wild pointer
(unless you have a bug, of course).

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Instead of using private:, you could just add an underscore to internal
> variables.

  But why would I want to do that? There's no benefit. There are only
potential disadvantages.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Warp wrote:
> >   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).

> Tons of existing code are intentionally accessing stuff they know is subject
> to change?

  I still can't comprehend what's so bad in the compiler doing the check
that you don't access the private members.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I disagree. Now you've got a naming convention that isn't enforced that 
> would mean something to people trying to read your code.

  You mean the naming convention *is* enforced by languages which do not
explicitly support private data?

-- 
                                                          - Warp

Post a reply to this message