Droping NS_AX_BEGIN and similar macros

[j-jorge]

Hi, I have a hard time finding out the good sides of the NS_AX_BEGIN/NS_AX_END preprocessor definitions. My best bet is that the intent was to allow global namespace renaming in a single place, yet I think this is a poor practice:

• New contributors and new users cannot tell the actual namespace from the file they are looking at. They have to find the definition to know the namespace. Pure C++ syntax would have been clearer.
• It causes all files to depend on Config.h, causing high coupling and many recompilations on configuration changes.
• The occurrences on these definitions are followed by a semicolon, which is syntactically incorrect and may cause compilation warnings.
• When the cocos namespace was renamed as ax the macro was also renamed, which makes my best bet moot...

I think the code would be better without them. What do you think?

[iAndyHD3]

As you have correctly stated, I'm failing to see the good sides of having this (and many more other macros) instead of actual C++ code specifically in headers.

Another problem caused by all these macros is that you need to have the correct include directories set up to correctly parse axmol headers using some external library like libclang, and this really difficults writing quick external tools for example to generate language bindings or other things.

Axmol would benefit from using less macros.
What do you think @halx99 ?

[smilediver]

I also agree that these macros just complicate things and doesn't solve any problems. Maybe they were used for something at some point (backwards compatibility when they introduced namespaces maybe?), but now they serve no purpose.

[halx99]

Agree

[j-jorge]

I've created #2100 to remove NS_AX_BEGIN and NS_AX_END.