Amir Yacoby: 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?
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.
As for the question, if None was a part of global mql5 that was ideal because MQL5 is for both oo and procedural. But trying to force it with static classes for me is not worth. I still say you can do it, its matter of style and prefernce, dont feel discouraged just because someone does differently. Enough for today.
Amir Yacoby: Acknowledged that I only target class scope.
As for the question, if None was a part of global mql5 that was ideal because MQL5 is for both oo and procedural. But trying to force it with static classes for me is not worth. I still say you can do it, its matter of style and prefernce, dont feel discouraged just because someone does differently. Enough for today.
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?
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.
Amir Yacoby: 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.
class MyNewClass : public CObject, public NoneMixin;
Otherwise, it would wreck the current ecosystem we have with only single inheritance.
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.
Amir Yacoby: 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?
Actually, it is enough to add those defines in CObject, and be done with it. The rest is overkill. 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?
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?