
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
We talked about it already and I said it clearly. You also acknoledged it. Then you come back to it, among other wrong ideas that it should be public or I must clutter etc. Well no, it shouldnt be public and for me its the better solution. Anyway, our stands are clear as I said, let the people choose. Thats it, its your thread but I think there are many people that will agree with me also so I wrote here. Have a good day.
What did I acknowledge?
I asked you a pertinent question that you never answered... Would you also propose that the global constants, such as DBL_MAX, also be removed from the global scope and inserted as protected members of CObject and only accessible to its descendants?
What did I acknowledge?
I asked you a pertinent question that you never answered... Would you also propose that the global constants, such as DBL_MAX, also be removed from the global scope and inserted as protected members of CObject and only accessible to its descendants?
Acknowledged that I only target class scope.
So just to confirm I understand you. You are okay with everything except using a class like a c++ namespace?
So just to confirm I understand you. You are okay with everything except using a class like a c++ namespace?
I can see your point as well. And static methods without state, should be ok (psychologically I don't like it though).
Also, they don't quite make it as part of a CObject, because they are stateless and not belong to particular object, which makes it somewhat duplicated.
I though also of making it static methods in CObject, which seems slightly more correct, and would also allow for the scope to be global, which will allow to call CObject::None(typename) from all over, but then it would also make sense to move them away to a different class as you did.
And it does appeal to have it from any scope. So, I am not against your idea at all.
To be honest, I find drawbacks in both implementations. I can argue for both.
I can see your point as well. And static methods without state, should be ok (psychologically I don't like it though).
Also, they don't quite make it as part of a CObject, because they are stateless and not belong to particular object, which makes it somewhat duplicated.
I though also of making it static methods in CObject, which seems slightly more correct, and would also allow for the scope to be global, which will allow to call CObject::None(typename) from all over, but then it would also make sense to move them away to a different class as you did.
And it does appeal to have it from any scope. So, I am not against your idea at all.
I'm glad that we're on the same page. 😃
Regarding it's implementation in CObject, however, I think the only way it would work without breaking a lot of classes out there is if/when MQ ever implements multiple inheritance.
Otherwise, it would wreck the current ecosystem we have with only single inheritance.
I'm glad that we're on the same page. 😃
Nothing changed though, I am not sure I will adopt this at all because static methods still are not good in my view. And maybe the CObject is the least price altgether. Will give it a second thought, maybe something will come up.
In this context, there is no functional difference between static methods and globally defined functions other than namespace encapsulation. But if it pleases you to not use a class as a pseudo-namespace then perhaps this is the right version for you?
In this context, there is no functional difference between static methods and globally defined functions other than namespace encapsulation. But if it pleases you to not use a class as a pseudo-namespace then perhaps this is the right version for you?
And each time, instead of writing for instance NONE(double) - just write NONE_DOUBLE.
Those defines are there to be used anyway, so why not settle with it?