On Dec 20, 2006, at 7:15 AM, Christian Theune wrote:


Gary Poster wrote:
On Dec 19, 2006, at 2:34 AM, Christian Theune wrote:

Hi again,

Gary Poster wrote:
I don't have a very strong feeling about it, but lean towards "bug
fix".  It didn't break any of our code (or at least any of our
tests :-) ) so it seems safe from my perspective.
I was trying to apply the patch to the 3.3 branch and noticed that the
patch isn't compatible, as it requires a restructuring that
happened on
the trunk a while ago. This refactoring (r70331) introduces a very
feature, but the broken behaviour (trying to put anything into
_toFormValue) exists in the old variant as well.

It's a bit murky, since 70331 only changes internal APIs, but
unfortunately the widget subclass API is effectively public in IMO.
I don't think 70331 is ok to push back, unfortunately.  A shame, but
then the easiest thing to do is treat 71548 as a feature too; the
other option would be to revise the fix in 71548 for pre-70331.

I've had the same feeling initially. I'm looking at 70331 again and
don't think it's too bad.

Agreed, the potential for an incompatibility is there, because some
client code might have used _getCurrentValue already in a subclass. (But
then again, we would face the same problem when introducing
_getCurrentValue in general.)

The interface for _getFormValue remains stable and the code didn't
change. The only thing that changed is that the responsibility of
retrieving the value and converting it to it's form representation was
split over two methods instead of a single.

Hm, ok. That does sound more workable than the skim of the diff appeared. (FWIW, we also have the internal evidence of backwards compatibility that our private and public packages didn't need to be adjusted for this change.)

I'll +1 this.  :-)

Thanks, Christian!


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

Reply via email to