Hi folks, I filed a bug some days ago, #24865 The is_modal method was no more virtual, so my code broke. My specific use of #is_modal is in system handling semi-modal dialog boxes. So I need to trap IsModal from the legacy code. Then I came along the new SWIG macro: SWIG_WXTOPLEVELWINDOW_NO_USELESS_VIRTUALS It is responsible of the new behaviour, for those who don''t know, it removes the ''virtualness'' of a bunch of methods. In these there''s the one I use: is_modal. I understand the need to lower the library size and also the speed concern. But which methods should we ''unvirtualize'' ? Regards, Pascal
Pascal Hurni wrote:> I filed a bug some days ago, #24865 > The is_modal method was no more virtual, so my code broke. > My specific use of #is_modal is in system handling semi-modal dialog > boxes. So I need to trap IsModal from the legacy code. > > Then I came along the new SWIG macro: > SWIG_WXTOPLEVELWINDOW_NO_USELESS_VIRTUALS > It is responsible of the new behaviour, for those who don''t know, it > removes the ''virtualness'' of a bunch of methods. In these there''s the > one I use: is_modal. > > I understand the need to lower the library size and also the speed > concern. But which methods should we ''unvirtualize'' ?It''s not only size and speed, but that directors will cause fatal errors and crashes in some cases if the method is virtual, because it hides the correct implementation. Eg you end up with an endless loop and StackError. The difficult bit of deciding which to ''virtualize'' is that ''virtual'' is used in two slightly different ways. Firstly there are methods in base (possibly abstract) classes (like wxWindow, wxTopLevelWindow) which are always overridden in concrete C++ subclasses. Here it''s probably a mistake to have director methods in ruby, at least in the subclasses, because they can never be usefully redefined in those classes. The NO_USELESS_VIRTUALS macros are meant to catch these. Secondly there are methods which it is expected that user-written C++ (and hence Ruby) subclasses will define themselves. These definitely need ''director''. Sorry I haven''t yet taken a detailed look at that specific bug. alex
Alex Fenton a ?crit :> > It''s not only size and speed, but that directors will cause fatal errors > and crashes in some cases if the method is virtual, because it hides the > correct implementation. Eg you end up with an endless loop and StackError.I wasn''t aware of these kind of problems.> > Secondly there are methods which it is expected that user-written C++ > (and hence Ruby) subclasses will define themselves. These definitely > need ''director''.That makes sense, yes.> > Sorry I haven''t yet taken a detailed look at that specific bug. >Don''t look at the bug, I was simply saying that the behaviour changed from 1.9.8 to 2.0.0, and thus I filed a bug (in my sense). Note that I can live with these methods being ''unvirtualized'', but I think we should document these changes (maybe a note on every method ''unvirtualized'' ?) My point was to know what happend and how the ''bad'' methods list was setup. Thanx for these clarifications. Regards, Pascal