[Zope] Zope needs this (and Dynamo has it)

[Alexander Staubo]

(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_