Python is wierd!

[Alex Martelli]

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

That is, of course, different.  But when I see the _assignment_, I (think I)
know it's an instance variable -- unless strange tricks are being played
with __setattr__, of course (and *those* CAN indeed get weird).


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


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

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

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 operations,
you still can't beat Lippmann's "Inside the C++ Object Model".  For best
usage
and style, Meyers' "Effective C++", CD-ROM edition, is a good start.  A good
general-purpose introduction is Eckel's "Thinking in C++", which has the
advantage of being downloadable by the net; Robert Martin's site also has
many excellent articles on OO design and its implementation in C++, but
you should also get Martin's book (Eckel and Martin are among the many C++
aficionados and super-experts who are also Python fans -- I may not be in
their class, but I'm basically the same type:-).


Alex