Why wxWidgets does not have a namespace ?

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
shankar
In need of some credit
In need of some credit
Posts: 8
Joined: Mon Sep 21, 2009 7:04 am

Why wxWidgets does not have a namespace ?

Post by shankar » Tue Jan 12, 2010 11:50 am

i have just started learning wxWidgets .
i have a question .

why does not the whole package of the library contained in a separate namespace .This would reduce the name clashes .
another question is why macros are just every where, i mean every one will love this kind of statement---->

m_button.signal_clicked().connect(sigc::mem_fun(*this,
&ExampleWindow::on_button_clicked));

for a callback.

with regards..............

Frank
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 211
Joined: Sat Jan 01, 2005 6:19 pm

Post by Frank » Tue Jan 12, 2010 12:07 pm

Because wxWidgets is Oooold.

And for the developers of wx backwardscompatibility is more important than some fancy new language features.

BTW: There is a wxEvtHandler::Connect.

Another BTW: Why are you using sigc::mem_fun, when there is TR1::bind(), wich will also be in the next C++ standard? Yeah, because Sigc is old, when it was designed, there was no bind().

shankar
In need of some credit
In need of some credit
Posts: 8
Joined: Mon Sep 21, 2009 7:04 am

Post by shankar » Tue Jan 12, 2010 12:29 pm

Frank wrote:Because wxWidgets is Oooold.

And for the developers of wx backwardscompatibility is more important than some fancy new language features.

BTW: There is a wxEvtHandler::Connect.

Another BTW: Why are you using sigc::mem_fun, when there is TR1::bind(), wich will also be in the next C++ standard? Yeah, because Sigc is old, when it was designed, there was no bind().

You are right.
i mean i don't like MFC style programing. A modern library
design would make programming more enjoyable and more fun to do.if wxWidgets start using boost library then reuseability will increase .


with regards.........

johncruise
Earned a small fee
Earned a small fee
Posts: 24
Joined: Wed May 07, 2008 4:29 pm
Location: Sunnyvale, CA
Contact:

Post by johncruise » Tue Jan 12, 2010 4:58 pm

That could be nice good project for the wx team... put everything into namespace just like what they did in wxPython.

johncruise
Earned a small fee
Earned a small fee
Posts: 24
Joined: Wed May 07, 2008 4:29 pm
Location: Sunnyvale, CA
Contact:

Post by johncruise » Tue Jan 12, 2010 4:59 pm

... but of course, I know that it's a big of a task. No pressure though :lol: :lol: :lol:

Frank
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 211
Joined: Sat Jan 01, 2005 6:19 pm

Post by Frank » Tue Jan 12, 2010 7:02 pm

I don't think it's such big of a task. Just wraping every wxClass into a namespace can be done in a couple of hours.

I think the real issue here is backward compatibility. Namespaces are just thre begin. Getting rid of the macros is a much bigger task. And it breaks hundreds (if not thousands) of Projects.

So, the only solution would be to use the wx from today as backend and wrap it in an alternative API, wich uses modern C++ instead of 1995 C++. This way, old Code would still work on newer wx Versions, but for new code one could use new language features.

Well, this would be a really big task...

johncruise
Earned a small fee
Earned a small fee
Posts: 24
Joined: Wed May 07, 2008 4:29 pm
Location: Sunnyvale, CA
Contact:

Post by johncruise » Wed Jan 13, 2010 2:55 am

If that's the only case, a directive would be sufficient enough to fix it.

Code: Select all

#if defined( _USING_NAMESPACE_ )
namespace wx {
#endif

...
// in the end of the file
#if defined( _USING_NAMESPACE_ )
}; // namespace wx
#endif
What I had in mind was even a class rename to conform with wxPython implementation. For example, instead of using the following statement in our program...

Code: Select all

#include <wx/xml/xml.h>
...
wxXmlDocument samplexmldoc;
we'll be using...

Code: Select all

#include <wx/xml/xml.h>
...
wx::XmlDocument samplexmldoc;
This would mean all class declarations (including attribute/struct/const/etc declaration outside the class), in the header and implementation file (this includes each function implementation) would have to be touched.

so instead of

Code: Select all

class WXDLLIMPEXP_XML wxXmlDocument : public wxObject
{
public:
  wxXmlDocument();
that would look like

Code: Select all

namespace wx {
...
class DLLIMPEXP_XML XmlDocument : public Object
{
  XmlDocument();
and the corresponding code in the implemenation file would have a similar change from

Code: Select all

wxXmlDocument::wxXmlDocument()
  : m_version(wxT("1.0")), // ...
{
to

Code: Select all

namespace wx {
...
XmlDocument::XmlDocument()
  : m_version( wx::T("1.0")), // ...
{
(I've had reason why I meant wx::T() instead of just using T()).

Anyhue, besides the fact that namespace is added, regression testing would play the major part of the release process. There's going to be a plenty of hit and miss around on this kinds of change. (of course the team won't deploy it without testing right? *wink* *wink*) That would be the hard and time-consuming part of it :)

shankar
In need of some credit
In need of some credit
Posts: 8
Joined: Mon Sep 21, 2009 7:04 am

Post by shankar » Wed Jan 13, 2010 9:10 am

Hi,
Yes i know that a possible api change will introduce possible portability problems with the old projects but i think a change is necessity and will have to be done at some point of time. A change is always welcome .


Looks like wxWidgets faces the same problem as fltk gui toolkit .Fltk has couple of versions like 1.3.x and 1.1.10 and the experimental 2.0 with a very clear api.

with regards.....

Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria » Wed Jan 13, 2010 3:09 pm

My very personal opinion: it's a "nice-to-have", but there's a ***load of stuff that are more important in the "TODO-list" :)
"Keyboard not detected. Press F1 to continue"
-- Windows

catalyn269
Experienced Solver
Experienced Solver
Posts: 66
Joined: Wed Dec 12, 2007 2:40 pm
Contact:

Post by catalyn269 » Wed Jan 13, 2010 7:05 pm

To be honest, I don't really see the gain in using wx::T() instead of wxT().

I understand that it can help a lot with the syntax and the name colisions but there are a lot of other things that could be improved before that, last but bot least being the documentation !
Just me!

User avatar
tierra
Site Admin
Site Admin
Posts: 1343
Joined: Sun Aug 29, 2004 7:14 pm
Location: Salt Lake City, Utah, USA
Contact:

Post by tierra » Thu Jan 14, 2010 6:14 pm

catalyn269 wrote:I understand that it can help a lot with the syntax and the name colisions but there are a lot of other things that could be improved before that, last but bot least being the documentation !
The docs have already been immensely improved in 2.9+.

As for namespace questions, please do a search on wx-dev for "namespace". This question has come up at least once a month for a number of years now. The benefits and drawbacks involved have been covered numerous times already.

chenbin.sh
Experienced Solver
Experienced Solver
Posts: 64
Joined: Fri Apr 17, 2009 7:15 am
Location: Sydney, Australia
Contact:

Post by chenbin.sh » Fri Jan 15, 2010 4:28 am

Frank wrote:Because wxWidgets is Oooold.

And for the developers of wx backwardscompatibility is more important than some fancy new language features.

BTW: There is a wxEvtHandler::Connect.

Another BTW: Why are you using sigc::mem_fun, when there is TR1::bind(), wich will also be in the next C++ standard? Yeah, because Sigc is old, when it was designed, there was no bind().
Several months ago, some people really needed a new feature which amule (wxwidgets) didn't have. So a guy just ported some code from emule (mfc) to amule to implement it. It only took him half an hour because wxwidgets and mfc are very similar.

That proved why the wxwidget's old style is actually a strategic advantage for wxwidgets.
help me, help you.
http://blog.binchen.org

User avatar
tierra
Site Admin
Site Admin
Posts: 1343
Joined: Sun Aug 29, 2004 7:14 pm
Location: Salt Lake City, Utah, USA
Contact:

Re: Why wxWidgets does not have a namespace ?

Post by tierra » Fri Jan 15, 2010 6:49 am

shankar wrote:m_button.signal_clicked().connect(sigc::mem_fun(*this,
&ExampleWindow::on_button_clicked));
I forgot to mention that wxWidgets 2.9 actually goes a step farther than this with an even cleaner approach:

Code: Select all

m_button.Bind(wxEVT_BUTTON, &ExampleWindow::on_button_clicked);
But it's not like this is even all that bad in 2.6 and 2.8:

Code: Select all

m_button.Connect(wxID_ANY, wxEVT_COMMAND_BUTTON_CLICKED, wxCommandEventHandler(ExampleWindow::on_button_clicked), NULL, example_window_ptr);

Post Reply