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

[Jeroen van der Wulp]

Vadim Zeitlin wrote:
> 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.

I never said anything about putting everything in header files. 
Templates classes and methods can also be instantiated in cpp files. I'm 
sure you know: when the type is not known at library compile time then 
you want the template definition to be in the header file. And sometimes 
for efficiency so code can be inlined.

>  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.

Makes sense. However, someone could offer to do it for you. With even 
more macro magic it would be possible to make it backwards compatible. 
Of course the result would be a maintenance nightmare, so it's better 
not to do it at all. But should at some point you be making 
non-compatible changes to a wxTNG (that still supports wx2) this 
argument disappears so then you or someone else could introduce namespaces.

>  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.

What I meant is that compilation time can be controlled to some extend. 
Through structuring the code itself or by having a smart enough build 
system. So only a minimum amount of code needs to be recompiled to make 
the library up to date. I did not want to go in detail about this. I 
have not yet found the perfect build system that makes it all possible 
without other problems.

It is no solution I am proposing, compilation time can still become 
unacceptably high. As a result productivity may suffer. I have so far 
felt that using templates for code generation has helped me get code 
more compact and readable. For me this is enough compensation for the 
discomfort of extended compilation time.

> 
> 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?

Any mistakes in the use of that interface. The original quite concrete 
context was to protect a user from allocation of widgets on the stack in 
cases where wxWidgets will clean up that widget automatically.

But there are some more cases accidentally typing wxOK where wxID_OK was 
meant, or vice versa. I will not get any warning from the compiler. 
Also, giving the same identifier to different widget objects attached to 
the same window.

I'm sure you are aware of these things and I do not want to dicuss 
solutions. But I think we both agree that there is a way to help a user 
find such mistakes before runtime. We apparently only disagree on how 
important such issues are compared to other issues.

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

I know, I have read about it a couple of times. And I like many of the 
suggestions. I noticed that so little of those ideas have so far 
actually made it to version 3. But I realise that this is also related 
to the available amount development time.

More hands get more work done. I will start filing bug reports, do I 
really need a sourceforge account? The first may be about OpenGL support 
not being found, or misreported by configure as not found (OS X with the 
current development version). Or that it tries to import a header file 
Quicktime/QuicktimeComponents.h that is not available for some reason. 
But first I'll try to find a solution myself.

> JvdW> For instance to parameterise the string implementation throughout all
> JvdW> of wxWidgets.
> 
>  What exactly would this achieve?

Offering choice of string representation to the user of the library. As 
I mentioned in a previous email, code that was written for an ANSI 
variant of the wxWidgets libraries does not necessarily compile against 
the unicode variant. If library variants can be merged, the compiler can 
select the right string representation.

Your next question would be: what problem does this solve? It actually 
only (partly) solves a distribution problem. The problem is that there 
is no standard wxWidgets installation. Sometimes there is only the ANSI 
build, sometimes only the UNICODE build. With wx3 it may also be the 
UTF-8 build. We do not want to distribute wxWidgets as part of our 
toolset so  we rely on a version that the user installs or has 
available. By the way the part it does not solve is that we use built-in 
OpenGL support, and by default this support is not included when people 
type ./configure .

Regards,

Jeroen


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