(This is getting quite off-topic. Let's keep this brief.)

From: Hung Jung Lu [mailto:hungjunglu@hotmail.com] Sent: Sunday, March 12, 2000 3:19 AM To: faassen@vet.uu.nl; alex@mop.no; zope@zope.org Subject: Re: [Zope] Zope needs this (and Dynamo has it)

...

alexander staubo <ale-@mop.no> wrote: > I think Zope's source code is one huge, glowing argument in favour of

...

having protected members.

Having worked with C++ for a long time, and later with Java, I can tell you just how much I hated the whole thing about data "encapsulation."

The whole mumbo-jumbo stuff about data hiding has one and one single purpose [snip]

Having worked with C++, Python, and Object Pascal for a long time, I tend to agree, with a few modifications: - encapsulation helps keeping the code self-documenting -- nobody can accidentally access hidden members; - it aids documentation tools in that visibility rules can be seen as metadata -- "source navigator"-type object browsers can categorize members (methods and data) into their various protectedness; and - most significantly, hiding data and replacing direct access with clearly defined accessor methods lets you control access (such as synchronizing access from multiple threads) and also provide behaviour -- often data is calculated on demand rather than stored, and often related objects must be notified when data is changed. Python doesn't have accessor methods, but uses __setattr__ and __getattr__() instead, which is less intuitive -- a code browser cannot easily infer the access interface from the class definition alone -- and certainly slower -- but also more flexible. I'm a big believer in pure-code interfaces, keeping data hidden and restricting all reads and writes to accessor methods; languages such as Dylan and Object Pascal fortunately have accessor-method support built into the language, so referencing an attribute foo.name would actually be resolved by the compiler into a call to foo.GetName(). Python doesn't really need this, since its attributes are all dictionary-stored. Btw, as for private data members that are very specific to an implementation of a class, Ada95 solves this quite elegantly through packages, which are similar to C++ namespaces. I don't remember if Ada has language-assisted accessor method support.

...

...

Python has no "out" parameter, only "in" parameters that are mutable depending on the type of the object passed. The syntax I'm alluding to would effectively give you both "out" and "const" parameters. But that might result in a lot of incomprehensible code. I'm not sure if I'm in favor of having 'out' parameters anyway. constness as defined in C++ is also tricky, as it infects code; everything that touches it needs to be const-correct. Python tends to be less strict in this area.

Yes, another thing that I consider to be stupid in C++ is the overuse of const, or its use at all. Again, generations of programmers are taught into this thing about usage of const, and buying into it without questionning.

Const is overrated but often useful. Given C++'s absolutely antique object paradigm -- heap-based objects that aren't garbage-collected, meaning you end up dabbling with pointers *a lot*, or use confusing reference-counting smart-pointer template classes that go all over the place -- I like pass-by-reference better. I'm absolutely annoyed with C++. This is one reason: class Foo; class Bar { Foo F; }; class Foo { Bar B; } This, of course, won't compile -- the class Foo is undefined at the time Bar is declared. This means that a class A cannot contain a member of another class B if B already contains a member of class A, unless one of them stores the member as a pointer reference. This certainly screws up any reference-counting smart-pointer scheme, or at least makes it bloody hard to keep simple.

Keep Python simple. The role of Python is CP4E (Computer Programming For Everyone.) In Java or C++, you have to type all the extra stuff about public/ private/ protected/ void/ abstract/ static/ synchronize/ final/ const/... before you can do something. I know many people that live in that world and refuse to simplify their lives... well, then again, I also know people that lives in the Perl world and insist that Perl is a very readable language. :)

Readability and verbosity are not the same things. Java is at least an improvement on C++'s readability, but it is occasionally perhaps too verbose. But not compared to, say, Dylan, which has keywords like "required-init-keyword"; in spite of this, it's a great language once you get used to it. I rather like Borland's Object Pascal myself. It's suitably verbose to be readable, strict enough to catch most trivial errors in the compilation phase, statically-typed enough to perform really well, and just plain likeable. It doesn't have operator overloading, parameterized classes, multiple inheritance, or synchronized members, although it does have interfaces, static, abstract, const, and member visibility constructs. Here's the above snippet in OP: type Foo = class; Bar = class B: Bar; end; Foo = class F: Bar; end; (And this compiles.)

Hung Jung

-- Alexander Staubo http://alex.mop.no/ "`Ford, you're turning into a penguin. Stop it.'" --Douglas Adams, _The Hitchhiker's Guide to the Galaxy_