Darren New <dne### [at] sanrrcom> wrote:
> >   What other half-dozen "unsafe languages, where a stray pointer can change
> > private variables" were you talking about there?

> C, for one.

  Except that C doesn't have private variables.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> Warp wrote:
>>>   It breaks modularity badly. The whole idea of data hiding is that the
>>> private part should be completely opaque to the outside. The second it
>>> isn't, outside code will start making assumptions, and you can't change
>>> the implementation of the class anymore.
> 
>> You CAN change the implementation of the class. It's not your problem if you
>> break code that made assumptions.
> 
>   I don't think that's a good programming principle.

Me neither.  But that's a bad programming principle by the dumbass 
accessing stuff it shouldn't.  It's not your fault as the module 
provider and is beyond your control.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> - C#. Regardless of the name, has nothing to do with C++.
> 
>> C# is only unsafe if you specifically tell it "hey, I'm doing something 
>> unsafe."  That doesn't really count
> 
>   Of course it doesn't.

Or, at least, it falls into the same category as using reflection. :-)

-- 
   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:
>>>   What other half-dozen "unsafe languages, where a stray pointer can change
>>> private variables" were you talking about there?
> 
>> C, for one.
> 
>   Except that C doesn't have private variables.

Sure it does. Everything in a FILE structure is a private variable. 
Everything on the stack is private variables. You're reading things too 
narrowly.

-- 
   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:
>   You are seriously claiming that when you wrote "like, in unsafe languages,
> where a stray pointer can change private variables without going thru the
> class methods? :-)" as a reply to my post you were not directly and
> exclusively referencing C++, especially with that smiley?

BTW, I think it's at least as realistic a claim as

 >  The connection between my usage of the word "kludge" and your usage
 > of the words "unsafe" and "reflection" is purely your invention.

Seriously, I'm willing to admit we seem to miscommunicate a lot. But telling 
me I'm always misinterpreting you, then telling me I'm lying when I tell you 
you're misinterpreting me is a bit unpleasant.

-- 
   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:
> He's saying that putting "private:" before the variables in a class 
> declaration is equivalent to naming private variables with an underscore. In 
> the first case, the compiler warns you if you use a private variable by 
> mistake. In the second case, it's obvious from inspection. If you have
>     x._y
> in your code, you're doing something wrong. :-)

  Btw (not flaming here), what would be the naming convention for nested
classes? Take, for example, this kind of situation, in C++ code:

class OuterClass
{
 public:
    // Public interface here.

 private:
    // Outside code should not access anything from this point forwards.
    // This includes the 'InnerClass' class below.

    class InnerClass
    {
     public:
        // Public interface for OuterClass to use.

     private:
        // Private members of InnerClass. OuterClass should not access.
    };
};

  While it becomes complex, it's possible to have even a *third* nested
class, inside 'InnerClass', with the equivalent access rules.

  (Defining 'InnerClass' outside of 'OuterClass' is not a viable solution
if I really want 'InnerClass' to be strictly inside the scope of
'OuterClass' and nowhere else, because my class design calls for this.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> He's saying that putting "private:" before the variables in a class 
>> declaration is equivalent to naming private variables with an underscore. In 
>> the first case, the compiler warns you if you use a private variable by 
>> mistake. In the second case, it's obvious from inspection. If you have
>>     x._y
>> in your code, you're doing something wrong. :-)
> 
>   Btw (not flaming here), what would be the naming convention for nested
> classes? Take, for example, this kind of situation, in C++ code:

Python is kind of funky in this respect. Nested classes (or functions, or 
etc) don't have access to the private variables of the classes they're 
nested in.  They can only get locals, globals, or built-ins. A lambda 
expression can, but that's not a separate class as such, but just an unnamed 
function.

Depending on which naming convention you're talking about, class beta nested 
inside class alpha would be alpha.beta (if it's a public class), or 
alpha._beta if it's a private class.

In python, classes are values just like strings and lists and such. You can 
even instantiate classes without using the normal syntax, just by invoking 
the appropriate constructor for type "class". The syntax
    class abc:
       ...
just invokes that constructor and assigns the result to the variable abc 
(which creates the variable in that namespace if it doesn't already exist).

So if you nest alpha within beta like this
class beta:
    static_one = 1
    static_two = 2
    def beta_add(self,x,y):
       return x + y
    class alpha:
      root = 27
      def alpha_add(self,x,y):
         return x + y + root
then you get beta.static_one and beta.static_two and beta.beta_add and 
beta.alpha. You also get beta.alpha.root and beta.alpha.alpha_add.
Alpha can't access beta.static_one without using a dot. Beta can access 
alpha (as in "new alpha" sort of thing) without a dot, because alpha is a 
static variable of class beta.

But the namespaces that routines in alpha can access don't include the 
namespace that beta uses, and vice versa.

Hence, to get to alpha from outside of beta there, you need to say beta.alpha.

If you want alpha to be private to beta, so beta is (say) your linked-list 
class and alpha is a single link, you use "class _alpha:" instead, which 
indicates that beta._alpha is meant to be private to beta.

If you want alpha to be public, you name it "class alpha:" and others refer 
to it as beta.alpha.

Does that answer it? I probably gave way more details than you were actually 
asking about. :-)

The same naming convention holds for what you'd call "member variables" in 
C++, member functions, static variables/functions, nested classes, etc. 
Everything gets assigned to a variable. If you want gamma to implement the 
same foobar function as delta does, you can just write
    gamma.foobar = delta.foobar
and they're both the same function afterwards.

-- 
   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:
> Does that answer it? I probably gave way more details than you were actually 
> asking about. :-)

  I actually didn't understand your answer. There might have been some
miscommunication.

  Let me restate:

  There's a class named 'OuterClass', which has a public interface for
everything else to use, and a private part which is used only by 'OuterClass'
itself, and should be accessed by anything else.

  This private part declares another class named 'InnerClass'. This class
in question is part of the private implementation of 'OuterClass', and thus
should not be used in any way from the outside. However, 'OuterClass' itself
can, naturally, use it as usual.

  However, 'InnerClass' itself also has a public and a private part: The
public part defines the interface for 'OuterClass' to use. The private
part is for the internal implementation of 'InnerClass' itself, and shouldn't
be accessed by 'OuterClass'.

  The question is: If we are using a naming convention to denote public
and private data, how do you name 'InnerClass' and its private members?

  Since 'InnerClass' is part of the private implementation of 'OuterClass'
and thus should be used from the outside, I assume that the convention is
to call it '_InnerClass' (or whatever). The underscore denotes "don't
use this class from outside 'OuterClass', because it's private".

  How how do you name the members of this '_InnerClass'? All of its
members, even those in the public interface, are part of the private
implementation of 'OuterClass' and thus shouldn't be used from outside,
so do you put underscores in all the members, even public ones?

  What about the private members of '_InnerClass'? How do you differentiate
them from the private members of 'OuterClass'?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The question is: If we are using a naming convention to denote public
> and private data, how do you name 'InnerClass' and its private members?

Got it.

OuterClass
OuterClass._private_static_of_OC
OuterClass.public_static_of_OC
OuterClass._InnerClass
OuterClass._InnerClass.used_by_outerclass
OuterClass._InnerClass._Used_only_by_innerclass

Does that clarify?

OuterClass could invoke
    x = _InnerClass.used_by_outerclass

The trick is you shouldn't write "._" as part of a reference. :-)

>   How how do you name the members of this '_InnerClass'? All of its
> members, even those in the public interface, are part of the private
> implementation of 'OuterClass' and thus shouldn't be used from outside,
> so do you put underscores in all the members, even public ones?

Oh, no. InnerClass isn't really "part" of outer class. It's just a class 
that happens to be created while creating InnerClass and assigned to a 
static variable of InnerClass.

Python doesn't have declarations, even of classes and functions and methods. 
It has statements that have lumps of code in them and creates an instance of 
a function object or an instance of a class object, and then assigns it to 
the name you gave the statement.  So there's no real relationship between 
InnerClass and OuterClass, any more than you have a relationship between a 
sphere object and the texture on the sphere. There's a relationship there, 
but it's not a relationship having to do with types, but rather with 
pointers to instance objects.  Kind of like javascript in that respect.

>   What about the private members of '_InnerClass'? How do you differentiate
> them from the private members of 'OuterClass'?

The private members of _InnerClass have _ on the front. _InnerClass can't 
access OuterClass's private or public variables without going through the 
class or instance dot-notation.

InnerClass and OuterClass are two 100% separate and independent classes. You 
could get *exactly* the same result by declaring it this way:

class InnerClass:
    .....

class OuterClass:
    ...
    _InnerClass = InnerClass
    ...
(Except of course now InnerClass has a global name also)

A nested class definition says "Create a new instance of type 'class' and 
assign it to this name in my namespace."  But that doesn't give the nested 
class any access that any other class could have, and vice versa. It's just 
a different name for a class. InnerClass doesn't have anything that points 
to the parent class, so there's no way to get to anything in the parent 
class directly from InnerClass. If the parent class has a global name like 
"OuterClass", then you can refer to that, of course, but there's nothing 
that tells InnerClass it's "part of" outerclass.

-- 
   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:
> Warp wrote:
> >   The question is: If we are using a naming convention to denote public
> > and private data, how do you name 'InnerClass' and its private members?

> Got it.

> OuterClass
> OuterClass._private_static_of_OC
> OuterClass.public_static_of_OC
> OuterClass._InnerClass
> OuterClass._InnerClass.used_by_outerclass
> OuterClass._InnerClass._Used_only_by_innerclass

> Does that clarify?

> OuterClass could invoke
>     x = _InnerClass.used_by_outerclass

> The trick is you shouldn't write "._" as part of a reference. :-)

  But an outside code could do something along the lines of:

OuterClass::_InnerClass obj; // Assuming the compiler doesn't restrict this

obj.someFunction();

  The first line clearly breaks the privacy contract, but with the second
line it's not so obvious anymore. It's calling a public member of _InnerClass,
but it's intended to be "public" only for OuterClass (because _InnerClass is
part of the private implementation of OuterClass), not for anything else.

-- 
                                                          - Warp

Post a reply to this message