Python Productivity over C++ (Encapsulation)

[Gordon McMillan]

Hung Jung Lu wrote: 

>Type strictness is fine. It has all to do with performance: small, fast,
>efficient machine code. Encapsulation is a totally different story.
>
>One of the biggest lies in modern computer language theory is that 
>encapsulation is there for a good technical reason.

Whew! That's quite a rant <omitted>.

But I can think of at least 3 different meanings for "encapsulation".

One is that the object is well designed, so I don't have to worry about 
it's internals. It just does what I want. Nothing to do with language, just 
a good API.

Another is they've made it so I can't (nicely) override the way the thing 
works. Like C++'s "private". Unless the object is *also* an example of the 
first kind of encapsulation, this sucks. Personally, "protected" is the 
strongest I use in C++.

Then there's binary only (including C++ libs where the headers define only 
virtual classes and no source included). Unless it's free and works the 
first time, I don't bother.

But there's nothing wrong with the *goal* of encapsulation. There's just a 
lot of stuff with bad API's and no sensible way to fix it.

- Gordon