[Zope3-dev] Re: Zope 3 as a reliable platform?!?

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Theune wrote:
> Hi,
> 
> this is a rant. I don't want to be destructive or disruptive, but I feel
> like I need to turn this up right now.
> 
> Let's start with something positive: I love Zope 3. I do. I know it
> almost since the beginning and I see how it works out.
> 
> But to be honest, I too often get the feeling that something in the
> process is wrong and we are failing to acknowledge it or work on it.
> 
> I think we make it way to hard for people who want to use Zope 3 as
> developers making applications with Zope 3.
> 
> Why? Because we keep changing stuff and don't tell people in VERY LARGE
> LETTERS about it.
> 
> What worries me most is that I, although I'm contributing to Zope 3
> every now and then, even fall into this quite often and I'm getting
> tired of it.
> 
> I can't read every proposal or every commit message or every post on the
> mailing list. I try to, but I can't. And I think that normal developers
> shouldn't have to try to.
> 
> When Philipp explained the zope.component thing in an earlier post I got
> annoyed again because I was relying on information that obviously was
> false. That's probably my fault because I didn't digg deep enough to
> verify the truth whether zope.component.provideUtility works against the
> thread local component registry or not. When I saw that
> zope.*app*.component does that I got scared because it's so similar and
> maybe hard to distinguish.
> 
> What I'm worried about is that we have to come up with a *MUCH* better
> way to tell people "What is *the single* way to do this or that?" and
> "Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!".
> 
> Again, maybe I'm only hitting this all the time because I'm living most
> of my live on pre-release-branches or the trunk, but still.
> 
> I think if Zope 3 shall be used by many people, this is a major obstacle.
> 
> I hope I don't annoy anybody, but I had to get that off my mind.

Insulating non-core developers from this kind of churn is what the
"façade" module 'zapi' was orignally for.  Folks who were writing
application code would have a reliable location in which to find the
"public" API, and would not be exposed to the deprecation dance caused
by tree refactorings:  instead, the person who did the tree refactoring
would just adjust the 'zapi' imports, and everyone else's code would
Just Work (tm).  That module would also be the logical place for lots of
the BBB code now scattered around the tree.

I'm OK with having "in-tree" code not use zapi, but I don't see a win in
propagating all the mess out to the rest of the world.  I'll also note
that "janitorial deprecation" is way too common in the tree today:
people decide they don't like the name a method was given, and deprecate
it in favor of the "better" name.  The ongoing cost of that deprecation
is then borne by everyone else.

Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE+blG+gerLs4ltQ4RAhEEAJ9/CLYNqlrPFWh+3UnPwaraMMLs7QCfVYYp
1fiertpiMU2/pFhAe6ovbQk=
=esi5
-----END PGP SIGNATURE-----