So here goes,
I mostly agree with what everyone has been saying. As I have been
writing code it have not been using ZCA because I'm just not sure where
it would be useful. I've been trying to think about it and plan
accordingly, but, as I have discussed with Tao, it seems like we are
just putting another layer of abstraction with no gain. What I mean is
that so far most interfaces we define have a 1 to 1 implementation. So
abstracting that interface gained us nothing other than abstraction. It
seems we do a lot of "just in case of the future" trains of thought,
which is very ideal, but it seems we are shooting ourselves in the foot
trying to do it. Meaning, we are planning for future changes, but most
likely the changes we are planning for won't occur.
Well, in case of the network layer we actually have a use case. Another
one is for the pluggability of the serializer. The first allows somebody
for instance to implement a separate eventlet based layer and let the
library use this (and I use it internally for replacing the standard
layer with a test mockup layer).
I don't see the problem with the 1:1 situation. Interfaces IMHO help to
make clearer what the component is about as it distills the essentials
out. That's also why I proposed this way of working: first write a
doctest, then write interfaces, then implementation.
Here are my less philosophical ideas:
1) I don't think it makes sense to take out ZCA and still try to code to
allow ZCA to be used at a later time. If we are going to code for ZCA,
we might as well use it. The coding is much different than normal coding
styles, so we can't have our cake and eat it too.
2) If we plan to stay with ZCA (which in all fairness doesn't seem like
too bad of an idea) we have to identify EXACTLY which parts we think
should be swappable. We don't have any design or architectural plan laid
out whatsoever, we haven't identified any components. Our design plan
just seems to be "GET IT DONE", and we pick up whatever IT is at the
time. So, with that said, ZCA can be effectively used if we identify
where we want to use it. Clearly everything shouldn't use ZCA as all
things don't need to be swappable components. Maybe we should come up
with some guidelines on how to decide.
As said, for me it's also about documentation and way of coding which
came out of the invention of the ZCA as a side effect. At least having
defined interfaces makes sense to me and does not really add that much.
3) I don't like the idea of splitting the project. The whole point of
this project was to pull together all the code that was currently in
place, integrate it, and expand it. Rather than having people working
independently on the same thing, we should make compromises and find the
best solution.
I wasn't so much talking about splitting, more adding a layer to a maybe
ZCA-less library. This also would save me from always saying "see, with
ZCA this now would be very easy." ;-)
4) This one is directly for Tao: to me, it seems the problem lies in the
fact that we all can't see how ZCA gives us anything that using normal
OO coding styles can't. I mean, most software doesn't use ZCA and they
get along just fine. We have design patterns, OO design in general, and
all else to make things swappable and manageable. Why so driven to use
ZCA and not just design our code using GREAT OO design principles?
Coding to interfaces works outside of ZCA.
Well, I have seen it happen with bigger project that OO sometimes is
quite inflexible. I gave some examples of how Zope2 looked like in the
end which led to a complete rewrite (and the invention of ZCA). ZCA was
invented out of a need to make a framework more pluggable. And at some
point you might need some registration of components so I proposed ZCA
because it's a solved problem there.
Lose coupling of components as ZCA brings us is also a topic which is
discussed in the software engineering scene and I at least have seen the
benefits in big projects where I see the before/after state. I agree
though that it shouldn't be overdone but what I mean is not that classes
should not mark up their interface but instead that classes do not need
to be dissected into adapters where this is not necessary.
And OO is not always that pluggable, because you usually cannot simply
change the superclass of some class you are using as it's all hardwired
then. And even then I would btw. propose to add interface definitions to
those classes to make clear for the user what the interface actually is.
It's less clutter then than doing it inside the code.
But as said, I will let you decide and maybe getting rid of ZCA might
also help me to spend my nights again with something else than defending
it and solving bugs :-) And if it helps to gain more developers, that's
ok as well.
-- Christian
--
Christian Scholz video blog: http://comlounge.tv
COM.lounge blog: http://mrtopf.de/blog
Luetticher Strasse 10 Skype: HerrTopf
52064 Aachen Homepage: http://comlounge.net
Tel: +49 241 400 730 0 E-Mail [EMAIL PROTECTED]
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
neue Show: TOPFtäglich (http://mrtopf.de/blog/category/topf-taglich/)
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
