Chris Withers wrote:
For me, the irony is that when Zope 2's development process was at its worst, this problem was at its best as there was so little change, enabling people to gather more knowledge without having to stop to re-learn their old knowledge.


It is my impression that it was Zope 2's obscenity towards API stability which provoked the Zope 3 rewrite. We are only doing now what could have been done (over the course of 4 to 5 years) much earlier. After all, the "new religion" idea (Component Architecture) dates as far back as 2001.

Sure, having to do:

to_change = {}
if obj.hasProperty(x):
    to_change[x]=x_value
else:
    obj.manage_addProperty(x,x_value,x_type)
obj.manage_changeProperties(**to_change)

...and remembering that manage_editProperties is BAD isn't that pretty, but it's been stable for so long that I can write it from memory now, and that's a big win.

Well, prettiness (or rather ugliness) aside, I'm having a problem letting that argument count. C programmers could easily use the same line of argumentation to say that manual error handling via return codes may be more complicated than dealing with exceptions, but they've been doing it for so many years that they can write it from memory now.

I for one prefer exceptions over manual error handling. And I prefer straight-forward APIs over unnecessarily complicated constructs.

So, for me, it would be great if developers would take more time to weigh up the "what does this new feature or refactoring bring" against the "how much of a PITA is it going to be for everyone else to relearn this"...

Agreed.

Philipp

_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to