Questions on OOP in MQL5 - page 27
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
Which statements in particular are unfounded?
there is enough.
The article is a throwaway article, designed to get a firestorm from OOP people and has nothing to do with mql because there are simply no language tools for FP in mql.
so there is no point in discussing it here.
there is enough.
The article is a throw-in, designed to get burned by OOP people and has nothing to do with mql, because there are simply no language tools for FP in mql.
so there is no point in discussing it here.
there is enough.
The article is a throw-in, designed to get burned by OOP people and has nothing to do with mql, because there are simply no language tools for FP in mql.
so there is no point in discussing it here.
The comments are unnecessary.
Proponents of FP consciously forget that their lambda calculus is executed by a Turing machine, with a finite number of states and transitions between them, i.e. the same counters, branching and goto instructions are used. So to claim that FP provides something more than classical language like C, C#, Java can provide is at least incorrect.
Vasily, this article would be very useful to you - so that you don't torture yourself by squeezing out OOP for OOP's sake.
Vasily, this article would be very useful to you - so that you don't torture yourself by squeezing out OOP for OOP's sake.
Why so unflattering? I like the style of his articles very much,
I like the style and cleanliness of his articles, I wish it were clean and readable.
Why is that not flattering? I like his writing style very much,
the code is clean and readable - I would definitely wish it on myself - the level is very high.
Unfortunately I cannot support this conversation - I haven't read any articles or seen any code. It was about something else.
Unfortunately I can't support this conversation - I haven't read the article or seen the code. It was about something else.
I can only give my opinion about OOP for clarity of purposefulness of OOP in MQL. I finished the code - it was interesting to see what would be the result.
Now I have wrapped all the functions for working with orders into a class, and then I cleaned up the code and removed parameters in the functions since class fields are private - no sense.... i got a totally unusable code for further use
Yes, it's convenient that you can add small methods and extend class functionality, but for future use ... or add new methods knowing the compiler won't include unused code into the executable or... ... or ... write them all over again - so, all in all, we have a certain monster of a class for working with orders
i.e. the universality fee is a bloated code that you won't be able to read after a couple of months and you'll inherit the code so you won't have to find out what's superfluous in a class - too bad for your time
you can read it in principle, names of methods according to tasks you're about to run... in general, I'm not satisfied with the result - everything is cumbersome
I can only give my opinion about OOP for clarity of understanding the reasonability of OOP in MQL. I finished the code - it was interesting to see what would eventually come out, in the beginning it was the way I used to write - debugged service functions of working with orders and inserting OOP where I kept data and small methods that I planned to use only in a certain task, I called functions of working with orders from classes (procedural style)
Now I have wrapped all the functions for working with orders into a class, and then I cleaned up the code and removed parameters in the functions since class fields are private - no sense.... i got a totally unusable code for further use
Yes, it's convenient that you can add small methods and extend class functionality, but for future use ... or add new methods knowing the compiler won't include unused code into the executable or... ... or ... write them all over again - so, all in all, we have a certain monster of a class for working with orders
i.e. the universality fee is a bloated code that you won't be able to read after a couple of months and you'll inherit the code so you won't have to find out what's superfluous in a class - too bad for your time
you can read it in principle, names of methods according to tasks you're about to run... in general, I'm not satisfied with the result - everything is too cumbersome
In short, I pooped and got lost.
In short - shit and get out.
Hmm, who got out? What are you talking about? Okay... You have all the comments in the middle of the night, it's hard to know what's what.
...
And if you don't use classes, you'll get tired of constantly writing something like SymbolInfoDouble(_Symbol,SYMBOL_BID). Such dances every time - both brackets and underscore, and you don't know whether to press the capslock (and then somewhere else without looking, type an entire capitalized string and retype it) or keep the shifter pressed. At least that's where OOP is useful. If at least make classes for all these functions, then yes - they're huge. If you write it for yourself, it's not a problem. As for working with orders, there are not so many frequently used functions, we can simply put a few functions into a library. But in general, there is no ideal approach yet.