[wx-discuss] Re: More wxTNG Discussion (was: aspects of a safe future)

[Vadim Zeitlin]

On Fri, 26 Oct 2007 17:05:42 +0200 Jeroen van der Wulp <J.v.d.Wulp at tue.nl> wrote:

JvdW> I see, header-only implementations are still not on the map. Should have 
JvdW> expected this, because the template mechanism is not being put to use.

 Please don't tell me that you'd like to put the entire code of wxWidgets
(2MLoC at the last count) in the headers.

JvdW> VZ> The use of namespaces, while nice in theory, is just not worth it
JvdW> VZ> in practice and doesn't really bring anything except the dubious moral
JvdW> VZ> satisfaction.
JvdW> 
JvdW> The practical reason being that this-or-that old compiler does not 
JvdW> support namespaces...

 Actually, no. I don't think there are any compilers we use which don't
support namespaces (although plenty don't support ADL). The practical
reason is that we discussed this (look in wx-dev archives for details),
found that it would be difficult to do this in backwards compatible way and
that there are no obvious advantages in doing it anyhow. And so we decided
that our efforts would be better spent elsewhere.

JvdW> I really do not care about how long it takes to compile wxWidgets.

 This is because you don't do it very often. I do, and I do care. And
obviously the templates would be in the headers and so this would affect
applications using wx as much as building wx itself.

JvdW> For frequent building such as done by developers use a build system
JvdW> that is aware of header dependencies, supports modular building, and
JvdW> use the handle-body idiom to cut down compilation time.

 How exactly does it combine with putting all the code in the templates in
the header?

 Again, I have trouble taking buzzword-ridden phrases such as above
seriously. If you have any concrete ideas to propose -- great. If not, this
discussion is really, really useless.


JvdW> I do not now about the details of GTK+ programming, and how wxGTK is 
JvdW> implemented. I think that GTK+ returns error codes that at some point 
JvdW> are passed back to a method in a wxWidgets component and from there the 
JvdW> wxWidgets object hierarchy is all C++. The exception would only need to 
JvdW> travels through C++ code. Or are there scenarios where C code actually 
JvdW> uses wxWidgets components?

 Yes. C callbacks call wx event handlers which in turn generate events
processed by the user code.

JvdW> I see that as an advantage as well, but I am not really interested in 
JvdW> such functionality. What I fail to understand is that preventing users 
JvdW> of the library from making mistakes has such a low priority. People make 
JvdW> mistakes, even smart people. I think it is considered it to be a 
JvdW> property of a good interface if it prevents (or makes it very hard) for 
JvdW> a user to make a mistake.

 Yes, I agree. But what mistakes exactly are we speaking about here
concretely?

JvdW> Maybe, but are you a user of wxWidgets?

 Yes.

JvdW> An illustration of my previous point. Suppose I get an idea for an 
JvdW> interface and write a new widget for all wxWidgets supported platforms 
JvdW> and I use namespaces, exceptions and templates to parameterise the used 
JvdW> string implementation, no matter how good it looks it will probably 
JvdW> never get included (at least not without serious refactoring). It does 
JvdW> not fit the current wxWidgets way of doing things.

 It won't be included because it won't _work_. You can't use namespaces and
exceptions just in one control, this affects the entire library. As for
templates, you're free to use them as the svn trunk already does.

 Finally, using parametrized string type is opposite to the development of
wxWidgets 3 where wxString is a superposition of std::string and wstring
and also supports UTF-8 so this is indeed unlikely to be acceptable. But
this still doesn't mean you can't use it (and interoperate with wx) in your
own code.

JvdW> I was thinking we were still talking about the next generation 
JvdW> wxWidgets.

 We talked about it enough, see all the previous wxTNG discussions. And
AFAIK nobody still has any precise idea just about anything, including all
the above mentioned issues such

- use of smart pointer-like objects instead of pointers
- better, type-safe, flexible event handling subsystem
- using factories for object creation

and many others. Just about the only issue which doesn't create any
problems is the use of namespaces -- which just proves that only trivial
changes not really bringing anything important are easy to do.

 I'd love to have 6 months needed (in my estimation) to write a prototype
of wxTNG which would contain the answers to the questions above. But I
don't have enough time. And yes, it's true that wx may become irrelevant if
we never find the time to work on the new version. So it would be great if
instead of a single person spending 6 months we could have 12 persons
spending 2 weeks by working together. Except it doesn't seem to work like
this, as soon as there is more than 1 person much more time is spent in
discussions without ever arriving at anything.

JvdW> I was hoping this meant the start of some ground breaking 
JvdW> changes, a break with backwards compatibility.

 We can break with backwards compatibility only if wxTNG and current wx can
be used together and if you can progress to wxTNG progressively. We need to
find a way to allow it. Again, refer to the previous discussions for
wx2-on-3 and wx3-on-2 proposals.

JvdW> For instance to parameterise the string implementation throughout all
JvdW> of wxWidgets.

 What exactly would this achieve?

 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