Philipp von Weitershausen wrote:

I would vote to leave at least the class/factory and class/implements

The class/implements subdirective is debatable because putting an
interface on a class might be considered some sort of policy. So I don't
feel too strong about it.
Thanks :)
The class/factory case however is clearly about automation.
Yes, one aspect. This aspect is very important too. I love this automation and I'm probably not the only one. Look at Gary's statement "I'll miss class/factory,...".
As demonstrated in the proposal, the Python version with a simple utility 
directive is only two or so lines longer and essentially moves most of the 
information from ZCML to Python code.
The move from ZCML to Python is often better, but not always. I tried to sketch the use case *including a class from an external library into an application*.

My balance based on the attached example [1] summarizes the following:
A) Extensive today: 10 text-lines in zcml
B) Lazy today: 6 text-lines in zcml
C) Exentsive proposed: 1O text-lines in zcml, 8 text-lines in py-module
+ retyping the IFactory-import each time
D) Lazy proposed: 1O text-lines in zcml, 8 text-lines in py-module
+ retyping the IFactory-import each time

So, the proposed solution is about 3 times (*not* 3 lines ;) costlier than the laziest-manner.

It also reuses the well-known utility directive which makes registering 
factories very coherent: No matter whether they are custom or based on a 
callable like a factory from class, you just use the utility directive.

Coherence is one of the initial problems I state in the proposal so I
rather feel strongly about the class/factory case.
I really support coherence and less-magic attempts, but in this case the price is definitely to high and the intended simplification is fairly questionable.

The class/factory and createObject-pattern was always understandable for the Newbies I've met during the mini-sprints. The whole component-architecture in particular the adapter- and utility-mechanism was much more magic for them.

Automation will stay a magic, but it enables often people to do things they don't fully (deeply) understand. IMO it's more important to offer coherent magics on a certain application-layer than to evangelise assembler or even quantum mechanics. As well there the magic will come back at a certain point on a deeper application level :)

Still a very strong -1 on removing class/factory.



A) Extensive today
Today I have to write one ZCML...:

<class class=".alias.SydneyBristow">
<implements interface=".interface.ISydneyBristowPolicyMarker" /> <factory id="external.library.SydneyBristow"
     title="Agent Sydney Bristow"
     description="Sydney is an undercover agent working for the CIA"

B) Lazy today

or in the laziest manner (B):
<class class=".alias.SydneyBristow">
<implements interface=".interface.ISydneyBristowPolicyMarker" />
 <factory />

Remark: Afterward I can use the 
zope.component.createObject("external.library.SydneyBristow") to create

C) Extensive proposed
After the proposed change I have to do the following:

additional module for example
from zope.component.factory import Factory
from external.library import SyndeyBristow

sydneyFactory = Factory(
   SyndeyBristow,                     # a callable, e.g. a class
   title=(u'Agent Sydney Bristow'),
   description=(u'Sydney is an undercover agent working for the CIA')

ZCML to register the class and the factory utility:

<class class=".alias.SydneyBristow">
<implements interface=".interface.ISydneyBristowPolicyMarker" />

<utility component=".alias.sydneyFactory" provides="zope.component.interfaces.IFactory? <>" name="alias.SydneyBristow? <>" />

D) Lazy proposed ---------------- dito - 2 text lines

Zope3-dev mailing list

Reply via email to