Python is wierd!

[Mark Baker]

In article <8lma5602i08 at news1.newsguy.com>, "Alex Martelli"
<alex at magenta.com> wrote:
> "Mark Baker" <mbaker at 0x7a69.net> wrote in message
> news:l8rf5.1529$ck7.387235 at nntp1.onemain.com...
>     [snip]
>> > I see a "self.something=23", I know "self" is an instance variable;
>> > no
>     [snip]
>> Er....sort of.
> 
> Not really:
> 
>> def sum(self): return self.x + self.y + self.a # Scope within class,
>> but accessible via
> self
> 
> Ah, but here you're not *assigning* to self.a; you're just *accessing*
> it.

Yes, but simply because it's accessed via 'self' doesn't mean it's an instance
binding.
Which getting back to his commentary, isn't always very revealing.
With an assignment this is the case, but I wanted to clarify the actual rules
involved for the person.

The added benefit of overriding __getattr__ and __setattr__ can be even less
obvious.
But in the end, if the implementation is important to the user, then this should
be in the documentation anyway.


>> > have free-standing functions in their stead, and grouping by-module
>> > is more productive than by-class (the class is not the natural unit
>> > of encapsulation, an issue that is also acknowledged by the package
>> > concept of Java and the friend keyword in C++).
>>
>> friend is simply an evil way of violating encapsulation. It's not
> analogous to
> 
> Absolutely false, although people with a superficial understanding of
> C++ do tend to think that way.  The proper use of 'friend' is to split
> an encapsulated, cohesive functionality among more than one class,
> *because the class is NOT the natural unit of encapsulation*.  friend
> ENFORCES encapsulation, by only allowing access to certain object
> features to a carefully designed set of co-operating classes, designed
> together, to work together, and expose exactly that functionality that
> the designer of the package wants to expose.

I've been writing in C++ for many years now, but this isn't a matter of
who has a larger penis...

If an object's internals are to be accessed externally, then methods should
be provided to this inside of the object itself. It should not indicate that
it's alright for "some" people to violate its encapsulation.

If another object needs access to the internals of another object, then this
should solely be provided by the accessor/mutator pattern.

Friends, if attempted for use as "encapsulation" suffer from issues regarding
protecting implementation details, in a paradoxial and limitedly extendable way.
It is rare to be used in this manner.

They are used quite often to violate real encapsulation principles, for the sake
of performance. Methods that are declared inline may or may not end up as
such with any given compiler. Plus depending on the complexity of accessors,
one may not wish to have this code inlined in every case. In the end, the
compiler and not the programmer should be concerned with these, in any event.
But now I'm diverging...

In the real world, people do use friend to violate encapsulation.


> 
>> modules, packages, or anything else. It simply provides a means of
> violating
>> C++'s encapsulation (usually for speed purposes, since you should be
>> able to use the accessor/mutator pattern to work with object
>> properties)
> 
> Again, absolutely false, and, again, suggesting rather superficial
> understanding of C++'s working.  A public accessor/mutator can be, and
> generally is, written in-line, with no speed penalty whatsoever over
> access to an instance variable.

Unless of course you're not simply returning a primitive instance variable.
And then perhaps, as I said, you aren't inclined to want it inlined, or have
it inlined automatically by the compiler.

Friend, though, is also used rather often to execute private methods.

 
> The problem is, this lets ANYBODY read/write that property (through the
> accessor and mutator); what if you only want ONE OTHER, SPECIFIC CLASS,
> to have that ability?  Answer: you use friend, which lets you ENFORCE
> encapsulation
> (and keep the accessor and/or mutator private, so that only the friend
> class
> can make use of them -- if it still makes sense to have them, which it
> often does, essentially for purposes of convenience).

This allows you to partially violate encapsulation, in order to maintain it
elsewhere. This doesn't really increase it, it decreases the violation of it.
To claim otherwise is amusing, at best.

More often than not, if you need access to some part of an object's
information, there are chances that someone else will. If you need
access to someone's private implementation, then their framework
lacks much to be desired. Encapsulation is meant to protect mostly the
latter.


> If you're interested enough in C++ to make such comments, you owe it to
> yourself to understand a little bit more about this extremely complex,
> though powerful, language.  For the mechanisms underlying its typical

The Design and Evolution of C++ and The C++ Programming Language are
also good in that Bjarne is more than willing to say where C++ could have been
better, or why a "bad" decision was made.
Multi-Paradigm Designs for C++, Generic Programming and the STL, and other
such books are also interesting as far as C++ goes.

Even better than strictly C++ books are things such as Design Patterns, 
Analysis Patterns: Reusable Object Models, Smalltalk 80: The Language,
Understanding CLOS, and some others. It's much more interesting to look
at language, framework, and pattern designs for a multitude of things, and
then look at any one language's specific features, instead of accepting the
decisions or beliefs of one faction of programmers.