[Zope-dev] Re: Future of ZClasses

[Patrick Gerken]

Above all,
I should mention that I believe this discussion is largely about Z3,
and I do not live in Z3 world yet. Actually I am developing more in
2.7 currently. But the policy I state below is valid for 2.x also,
afaik.

On 10/4/06, Jean-Marc Orliaguet <jmo at ita.chalmers.se> wrote:
> Patrick Gerken wrote:
> > I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it
> > makes sense to have a smaller core API with longer deprecation
> > periods, so that standard projects can try to rely on core API with
> > long deprecation phase and extender would use the one year deprecation
> > phase. But as I said earlier, I think we are quite ahead already.
> >
> > I guess the motivation of this API stability discussion is also
> > motivated by JMOs comment about how much more stable is the Java API,
> > in Point 2 and 3 of this entry:
>
> Everyone deprecates stuff, this is not the question. But what is marked
> as 'stable', 'official' or 'standard' may not be deprecated in the same
> way as something that is still under development or private. It is more
> a question of defining and maintaining a contract with API users than a
> question of technicalities (how often to deprecate, what version numbers
> to use, how to inform...)
>
> This is all about defining and maintaining a social contract with the
> user. No one prevents you from deprecating parts of an API that is
> marked as being "under development" or "private" -- as long as you say
> it from the start.
>
> Check out for instance:
> http://openide.netbeans.org/tutorial/api-design.html especially the
> chapter "Life-cycle of an API"

I can see no guarantee for a time line

> What is unclear in zope is what is "official", what is "stable", what is
> still "under development", etc. It seems that all the different packages
> have the same status, or rather that they have no status. Apart from the
> packages that were added recently (zc. ...) there is no information in
> the repository about the quality of the different APIs. There are no
> version numbers on the packages either so I don't know what is alpha,
> beta, or final. It gives the impression that the framework is stable,
> but not mature.
>
> I'd expect that the API defined in the 'interfaces.py' files for
> instance are 'official' in the sense that there is a commitment that the
> API is ready and that it won't change until the next major version, but
> I doubt that this is understood by everyone putting stuff into these files.
>

Deprecation can happen at any time. Anything deprecated in one release
will create deprecation warnings when used for two major releases.
After that the code is removed.
That is the official policy.
Though I believe this was never mentioned explicitly, this policy
relates to the releases packaged by Andreas and Philip.
So for any code released in these packages this policy is used.
I BELIEVE, this is also true for all other packages on svn.zope.org
Through it is unclear, which of these have stable releases. I would
say that everything just in svn is unstable, and stable is, what is in
the zope core packages or on cheeseshop.

> in Java, you can mark a class as 'final', meaning that no one will be
> able to subclass it, or methods can be marked as 'private'. Abstract
> classes can specify the methods that must be implemented. Also if a
> class says that it implements an interface it has to implement it
> otherwise the code won't compile.

So here I must admit that I am from Zope2 world mostly, but some
smaller Z3 code I checked actually hat assertions in their code (not
in the tests directory), that checks whether its own objects really
obey the interface. This is worse than in Java but shows that at least
these developers were aware of these things. Sadly, except for using
Meta classes I see no way to make these checks implicit like they are
in Java. This is a language problem.

> Again this is all about defining contracts.
>
> Considering the standard JBoss modules, there is no way to compare with
> zope really since they strive to implement the specifications thoroughly
> (EJB3, JSR-168, ...) and the APIs are final already, so they don't change.

Well, I can only answer with accusations like they influence the
standards so much that you could already say they define the standard,
and about the API I could ask how the react to changing environments,
but that would not be fair, since I did not research the accusations
nor how stable the API really is and what the API defines.

Maybe somebody with better background can put these accusations on
solid ground until then I have to believe Jean-Marc here.
Anyway I appreciate your critics Jean-Marc.

best regards,

           Patrick