David Bolen writes:
···
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of David Bolen
Sent: Monday, April 26, 2004 4:19 PM
To: wxpython-users@lists.wxwidgets.org
Subject: [wxPython-users] Re: POLL: wx.DC methods
Robin Dunn <robin@alldunn.com> writes:
Please (re)read this section of the MigrationGuide and then vote for
one of the following:http://wxpython.org/MigrationGuide.html#new-wx-dc-methods
A) It's fine as-is, please leave it alone for future versions
B) It stinks, consistency isn't that important. Revert it.
C) Allow both TypeA and TypeB methods to use the same "normal"
name.[1]
I'm a little late to the poll since I was traveling, but from my
perspective, the changes in this regard in 2.5 were, in retrospect, a
mistake, and I would choose (B).
I do agree with those who point out that the new choices don't even
match the wxWindows documentation, but that's not my key reason for
disliking the change. The big problem for me is that the change has
broken backwards compatibility between two adjacent releases (albeit a
2.4 to 2.5 jump) of wxPython. That's been enough to cause me headaches
with older code I have that might run on a mix of machines that between
them I'd like to have both 2.4.x and 2.5.x. Other than the DC change
and the sizer change to require tuples for spacers (which also is not
the form documented for wxWindows), my code would run unchanged in 2.5.x
under the old namespace.
Originally, I was happy to see in the migration guide that the
incompatible changes seemed to be coupled with the namespace change,
with wrappers to provide backwards compatibility for the prior namespace
users. That was, until I found out that those two tuple changes didn't
fall into that category.
The problem with the parameter change is that while wrappers exist to
attempt to cover the use of the DC functions in applications using the
old namespace, DCs passed at runtime (such as in event loops) are always
the new objects, so don't get the benefit of the backwards compatible
wrappers. And the sizer parameters also appear changed regardless of
namespace used.
For the DC changes, while I can write new code that conditionalizes
which function to use (or always uses the XY variant, but aliases that
to the non-XY for 2.4.x), I can't see any way to simply execute existing
code under a 2.5.x installation without modifying all uses of DCs in
event handlers in the source. It's seems a unfortunately negative
impacting change for minimal benefit from a practical viewpoint.
If nothing else, this change has made it significantly tougher for me to
deploy 2.5.x on my machines - even development machines, since our
existing code needs to be workable on there too (which runs me into the
other thread about versioning wxPython installations :-)).
Using the wxPoint/tuple forms may in fact be more consistent with other
wrapped methods (I haven't actually verified this, but am willing to
trust), but in this case, I think that practicality should beat purity,
and compatibility with prior releases should have been maintained.
(This goes for sizers too, at least under the old namespace - I hadn't
even thought of using tuples for them in 2.4 since I was used to the
documentation and past coding).
If you want to offer a wxPoint/tuple form as part of the wx namespace
(but via an alias there, not as the native form in the underlying object
yet) that would be ok with me. E.g., I don't object to this being the
long term direction, but think we need to find a way to get there that
only affects people using the new namespace, or in some way that
provides at least one wxPython release for a transition, since code will
have to be edited for the new namespace anyway.
[1] This is possible using SWIG 1.3's method overloading abilities,
but we will lose the use of keyword args for those methods. IOW, both
of these will be possible:
This is a potentially attractive option from the perspective of
controlling migrating to the new form, but I think you'll run into the
same backwards compatibility problem by removing the ability to have
keyword arguments. It's bound to break some code, and to be honest, I
don't see any code breakage as being worth the small amount of possible
consistency gain.
-- David
Seeing this post, I recalled what Bertrand Meyer wrote in his "Eiffel,
The Language" regarding changes:
"
1. There must be wide agreement that the new solution is significantly
better than the original one. It must not entail any negative
consequence other than its incompatibility.
2. The implementers must provide an automatic conversion mechanism for
existing software. The conversion must be complete and safe.
" --p508 (1st ed.)
I would back off on the strong "must" wording of this as applied to an
API rather than to a programming language, but my point of writing is
that it sure would be nice to be given a conversion tool when something
changes that breaks compatibility. This has been done in the past, e.g.
the namespace change.
Just some thoughts,
Bruce