Questions on OOP in MQL5 - page 27

 
Alexey Navoykov:

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.

 
TheXpert:

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.

Yes, but it at least points out the problems of incorrect (thoughtless) use of OOP. I think it is very useful here, so that beginners do not get an impression that the very fact of using OOP is a panacea and a guarantee of code quality.
 
TheXpert:

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.

 
Vasiliy Sokolov:
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.

 
Dmitry Fedoseev:

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.

 
Igor Makanu:

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.

 
Dmitry Fedoseev:

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

 
Igor Makanu:

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.

 
Igor Makanu:

...

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.