Inclusion of the keyword namespace in MQL5

New comment
 

I have posted this issue before to the forum, but nobody give me any feedback. Probably because I didn't expose the issue in a way right.

When you start to deal with classes, it's common to have conflicts in the class names like CParam or CManager.
It's not difficult do have many modules of a trading system needing these types of class.
The use of namespaces is importante when you are developing a complex trading system composed of many modules.

Using prefixes in all the class names is not a  good solution. We need the keyword namespace included in MQL5.

If you are a developer, what is you opion about this? 

Thanks 

 
Jin:

Using prefixes in all the class names is not a  good solution. We need the keyword namespace included in MQL5.

It's the best solution. Believe me.

 
Renat:

It's the best solution. Believe me.

Two days ago, I tried to begin to use prefix in the class names, but it seemed very aukward, then I stopped.

I ask for help to the Support Team, asking to include namespace in MQL5, and they said:

 "No, sorry. There is no reason to add namespaces. To avoid conflicts (in brain too) use direct qualifications of member functions calls.

Please do not presume any defaults - this is wrong programming practics" (Team Support)

 Well, I didn't understand, so I answered:

---------------------------

 "Sorry, I don't understand. What "direct qualifications" ? Which defaults?

I mean, you include the file, declare the class, and call the function, that's it. Like:

#import <Dummy.mqh>

void Start()
{
CDummy dummy;
dummy.DoSomething();
}

How can I qualificate further this function member call ? Could you please give me an example?"

---------------------------

What am I missing?  

 

They mean that there isn't a way of constructing a domain hierarchy, a.k.a. their class system is broken and leads to further pollution of the global scope.

In laymans terms, you can not create a namespace like "JinCorp" to contain and organize all of your classes. When you want to create a class whose name collides with any name in the heavily polluted global scope, you will have to give it some unique name. Their suggestion basically boils down to giving your classes names that would correspond to the fully qualified domain name of the class in a non-broken class system. As in, your class names for dealing with symbol information would be things like JinCorp_Symbol, JinCorp_MarketWatch, JinCorp_TickFeed and the like. For deeply nested domains, as is common practice and basically required by any logical class system, you will end up with massively long class names like JinCorp_Terminal_WindowManager_Window_Indicator_Setting and JinCorp_CandleSet_Interfaces_PatternParsers_IScanCandles. Also note the inability to alias class names with "using" or something similar, in order to perform the lexographic logical operation of "When I say 'Setting' in this context I mean 'JinCorp_Terminal_WindowManager_Window_Indicator_Setting'".

Also note that you'll get warnings and errors when your class constructors have parameter names that match a member name of the class. Instead of resolving the names with a mechanism that traverses from local scope, instance scope, static scope, then finally global scope, they have something else going on. I mean, an unqualified name that could resolve to a method parameter (basically a local function variable) should be pretty easily disambiguated from a qualified name from the 'this' scope, but no, it doesn't, and the recommended practice is to prefix all class members with m_. So, not only do you need to create massive class names that incorporate namespace information, but you also have to incorporate scope information into class dimensions.

The only thing missing from the code you'll have to type out in order to access a class member is the member type, which pretty much defeats the purpose of defining a class in the first place. I mean, you could just define methods and variables in the global scope with ridiculously long unique names to achieve the same effect for any singleton class, and for non singletons you could simply have structs to contain the dimensions of the object... of course those structs would have ridiculously long names to completely describe the intent as well...

It is definitely much easier implementing a class like system using JavaScript's implementation of functional programming, because in reality everything in JavaScript is an object... even "scalar" values. It's simple to create an empty object to serve as a namespace and add methods to it that return object instances for whatever "classes" you'd want. C#, Java, etc. are already written, tested, work well, and have moved into the new millennium with all it's new fangled "object oriented" mumbo jumbo. It would probably be easier to just write your code in one of those languages and create a simple bridge to your app using websockets. If metatrader and your websocket server are running on the same machine then everything should work fine. An added bonus is being able to just make a new bridge to another trading platform, or consume a broker's API directly, without reimplementing your trading strategy in whatever garbage language they try to trap you on their platform with. You can look up StockSharp on github, some of their code is open source there, it'll give you basic things like class descriptions for candles and implementations of all the common technical indicators. StockSharp is in C#, so it'll all make sense.

 

Why not use the preprocessor to help?

Since the language does not support the C++ using keyword, I am doing aliases with the preprocessor.


// some lib directory Test.mqh
namespace Test {
class Hello {
    Hello(){}
}
} // namespace


// Expert Advisor

#include "<libdir>/Test.mqh"
#define Hello Test.Hello // import like for a single element

OnInit()
{
    Hello test = new Hello();
}
New comment
Reason: