[wx-discuss] wxTNG: compatibility with wx2 API

[Vadim Zeitlin]

On Thu, 16 Feb 2006 16:47:44 +0000 Julian Smart <julian at anthemion.co.uk> wrote:

JS> At 15:35 16/02/2006, you wrote:
JS> >as an overall direction #2 : I'd like to provide as much source code
JS> >compatibility as possible, without sacrifying goals that are too
JS> >important.

 Well, this is already excellent news as it means that we're in broad
agreement about what we want and even about how to achieve it (correct me
if I'm being too optimistic).

JS> >So this would eg mean that while wx3 might have a wx::Window with value
JS> >semantics, there still would be a wxWindow for keeping old code running.

 Right. Now the question is just whether wx::Window has a "wxWindow *"
inside it or if wxWindow becomes a wrapper around wx::Window.

JS> It would be great if we could incorporate compatibility into the wx3
JS> implementation without a full wx3-on-wx2 or wx2-on-wx3, but I expect
JS> this will be quite limited (not at all full backward compatibility).

 Yes, this would be great but I don't see how to do it. If someone does,
I'd very much like to hear about it. But for now (and after having thought
for quite some time about it) [23]-wrapping-[32] approach is all I can see.

JS> However, there's nothing to stop us from having different levels
JS> of compatibility, for example: (1) built-in, (2) add-on extra libs, (3) 
JS> wx2-on-wx3.

 I think it would be a bit confusing but maybe I just don't understand what
you mean.

JS> >- on the other hand if we to it that way, code using wx2 will never
JS> >benefit from anything,

  Why do you say this? We could still improve wx2 code base (personally I
am sure to continue this for awhile anyhow as I have a few clients using
wx2 for commercial projects and I am going to continue working with them).

JS> >and I don't think many projects will do a complete rewrite, so wx3
JS> >wrapping wx2 will keep the old code and old problems there for a long
JS> >time, and us having to support wx2

 As I said, I think we'll have to support wx2 for quite some time anyhow.
Taking into account the size of a typical project using wx (in my
experience it's measured in hundreds of kLoCs), it's wishful thinking to
believe that they're all going to be rewritten in wx3 any time soon anyhow.
As such, the possibility to start using some of wx3 features in existing
code is important, I think. And being able to mix wx2 and wx3 in the same
program should be one of the goals IMO.

JS> >wx2 wrapping wx3 will allow both sides to move gradually,

 Sorry, I fail to see how. We need to spend a massive effort on rewriting
(or at least refitting) the existing code into wx3 and during this time the
development of wx2 would be practically stopped as it couldn't even
continue on another branch as merging won't be possible later. Also, moving
all wx2 code into wx3 at once like this will automatically mean inheriting
a lot of legacy code (think: exception-unsafe, not using std classes, ...)
while in my dream wx3 would contain only clean, modern and, most
importantly, peer-reviewed code.

 When Julian says that wx2-on-wx3 approach is the cleanest and the easiest
one to implement, I agree with the first part but strongly disagree with
the second one. I'm afraid wx3-on-wx2 is the only possibility in practice.
But, again, I'd gladly consider anything else as this is not without its
own problems -- but at least it seems eminently doable.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-discuss-unsubscribe at lists.wxwidgets.org
For additional commands, e-mail: wx-discuss-help at lists.wxwidgets.org