[Zope-dev] SVN: zope.app.component/trunk/ Please, don't just remove things that could be used in users code.

[Dan Korostelev]

>> +- Make ``class`` directive schemas importable from old location,
>> +  raising a deprecation warning. It was moved in the previous release,
>> +  but some custom directives could possibly use its schemas.
>
> Out of curiosity, *was* it used by custom directives that you know of?

Well, I personally found out that they were removed while checking out
the z3ext packages. Some of them use "require" and "allow"
subdirectives for their custom directives. In the case of "allow" and
"require" it's quite easy to think out the case where they will be
reused.

> A more philosophical question: are the interfaces used to implement a
> directive part of a public API that is reusable or not?
> When we moved the directive implementation I arbitrary made the
> assumption that it'd be fine to just move them wholesale, but you
> clearly don't agree. Besides the interfaces, should the implementation
> also have backwards compatibility imports?  I guess sometimes reuse by
> interface subclassing does happen in directive implementation, but of
> course we could declare that such reuse is only intra-package.

It looks like "yes, it should" to me. AFAIK, we reuse directives in
zope itself and in other packages. One example is z3c.pagelet that
reuses IBasicViewInformation schema and functions like
"handle_permission" or "handle_for". However, that might be considered
as a flaw to be fixed, so there's a place for discussion on that
topic. However, I think that it's even good for directives to be a
part of reusable API. What if we want to create an extended
<browser:page /> directive, adding only one custom field? The
implementation functions and classes are also reused sometimes. We
reuse the zope.component's directives like "adapter" and "utility", so
why not reuse a ClassDirective if it fits our needs?

> In my mind, it's also less risky to move a directive implementation even
> if it is reused, as the amount of external reuse is likely rare and is
> less likely to be in end-user code. The developers of the code layered
> on top of the directive definition would therefore be quite capable of
> fixing any breakage quickly.

Of course, its clearly okay to move directive schemas and definitions
around, but I believe, that we need to support old imports for one or
two "big releases" as we did before. There's a nice deprecation
framework, provided by zope.deprecation and zope.deferredimport, so
why not just use them to maintain backward compatibility while
signaling people that they need to update their code? Not everyone is
so quick and has time to fix the breakage. It's also quite hard to
qucikly find where did the thing move if there's no compatibility
imports or comments w/o reading changelogs.

> But of course placing a few imports for backwards compatibility is not a
> lot of work and may be the easiest way out of this set of questions. :)

Yep. Also, as I said before I think we also need to use deprecation
warnings for imports that are not classes for persistent objects
(until Chiristian writes the tool to upgrade them :)).

-- 
WBR, Dan Korostelev