[wx-dev] Re: 2.8, 2.10, 3

[Stefan Csomor]

Hi
>> yes, and yet the are adding quite a lot of functionality from one 
>> compat release to another, they definitely have a good way to do 
>> these things, on every class level they have their d_ptr that is used 
>> to point at the data, so they don't get into a fragile situation with 
>> inheritance either
> We need to go this route.  And not talk about it, but actually do it.  
> The same happens in some key Cocoa classes as well.
>
> ...
> I've been hesitant to start working towards this in trunk with wxCocoa 
> because it means rearranging all of the code in trunk in such a way 
> that it will no longer be patch compatible with 2.8.  But I think 
> ultimately it really must be done.  I'd actually like to play with 
> this in a separate branch that will never be released so I can get a 
> feel for what needs to happen.
>
> Obviously you've got something similar going on with the wxMacControl 
> stuff in wxMac but right now it has a lot of mac-specific stuff in 
> it.  I'm thinking of doing a similar thing in wxCocoa but with a 
> platform-independent base.  If it works out then as we discussed a 
> while ago, wxMac and wxCocoa could share it and other ports could 
> eventually follow.
yes, I think we have several layers on which things could make changes easier

- the d_ptr approach

http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#Using_a_d-Pointer

- having pImpls for almost everything and have the implementation wx-private for things that don't have to be subclassed (eg built-in controls etc.), this pImpls could have a common interface for all ports, as we've discussed, the idea for wxMacControl was to get a feeling on what needed to be in there at all, and then start separating common from port-specific things

- also for subclassable classes that eg would be used for implementing user controls, perhaps we can have events where we used to have virtual methods, this would also increase the decoupling 

Best,

Stefan