Overhead for the PLO - page 4
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
My experience shows that you do need to.
I went this way about five years ago, back then on MT4. (Not because I didn't know about OOP, but because I was too lazy to bother with interfaces and inheritance, especially since at that time MT4 and MT5 were significantly different in terms of MQL implementation). This led me to the understanding of its fallacy. This is not "wisdom", but quite a reasonable limitation, a kind of "foolproof". If you always remember what each of hundreds of variables is responsible for - you don't need encapsulation. I don't remember that, and I prefer to have as few entities available in each block of a program as possible.
As soon as MQL4 appeared OOP - I started to translate all my developments into a single form based on interfaces.
I still haven't managed to come up with anything more convenient than MQL4-order system. If you have an example, please show me.
All trading API I've seen looks monstrous compared to MQL4. They are also clumsy.
I have never been able to come up with anything more convenient than an MQL4 order system. If you have an example, please show me.
All trading API I've seen look monstrous compared to MQL4. And what's more, they are clumsy.
What good will come out of it, each parameter must be drawn in a separate function. It would be more logical to receive the structure with all parameters by request, like with ticks.
I have never been able to come up with anything more convenient than an MQL4 order system. If you have an example, please show me.
All trading API I've seen look monstrous compared to MQL4. And what's more, they are clumsy.
What do you mean?
The very essence of orders ? Yes, I agree, it's quite handy.
But just the application of OOP to this system, in my opinion, is what gives the biggest "win". Let's say I have the same interface - gives both MT4 position consisting of orders and MT5 position consisting of MT5 positions, and regardless of whether hedging or netting conditions.
In my opinion, it's much more logical and understandable when we have a list of order objects (or MT5 positions) obtained via the Select() function and we address the properties of orders, rather than the"environment state" (obtained via the same function), which we address via functions.
The most interesting thing is if we need to track several orders at once - in this case, the procedural approach inevitably leads to a "pseudo-object" one - we have to create an array of information on orders that should be updated when entering OnTick() and work with order data by indexes in the array, just like with OOP-pointers to order objects.
In addition, the OOP approach would give us an advantage when working with historical and active orders simultaneously, since the historical order interface is the successor of the active order. And the procedural approach means that historical and active orders are handled by different functions, which is much less convenient.
What good is that each parameter has to be pulled by a separate function. It would be logical, like with ticks, to get the structure with all parameters on request.
The Order.TakeProfit and OrderTakeProfit() entries are the same. The first one has only possibility to store the object, and the second one - relevance. The need for storing is encountered very rarely, and not in TS. And there it is no problem to create the structure.
Myself I wondered why the developers have not made the return of the order structure, and left each field separately through a function (for the history also a ticket is required each time).
In general, I do not see anything really wrong with MQL4-API (it may work not only in MT4/5).
What do you mean ?
The very essence of order trades ? Yes, I agree, quite handy.
But just the application of OOP to this system - in my opinion - is what gives the biggest "win". Let's say I have the same interface - gives both MT4 position consisting of orders and MT5 position consisting of MT5 positions, and regardless of whether it is hedged or netting.
You have your own wrap, the other has his own wrap. The question was whether it's possible to create a more convenient wrapper than MQL4.
It's much more logical and understandable in my opinion, when we have a list of order objects (or MT5 positions) obtained using the Select() function and we access order properties rather than"environment state" (obtained using the same function) which we access via functions.
The most interesting thing is if we need to track several orders at once - in this case, the procedural approach inevitably leads to "pseudo-object" approach - we need to create an array of information on orders that should be updated when entering OnTick() and work with order data by indexes in the array, in the same way as with OOP-pointers to order objects.
I wrote about it in the previous post.
Besides, the OOP approach would give us an advantage when working with historical and active orders simultaneously - since interface of historical order is heir to the active order. The majority of functions are common. And the procedural approach allows us to handle historical and active orders using different functions, which is much less convenient.
Well, in MQL4, the history is handled by the same functions (OrdersHistoryTotal does not count).
It would be nice to have a code example where own trade API is clearly better than MQL4-API. I myself use OOP almost everywhere. And for some specific tasks I do some trade wrappers. But they are not universal, though very convenient to use for some particular task. However, I still want to compare the universal trading APIs.
I myself wondered why the developers didn't make the return of the order a structure, but left each field individually through a function (a ticket is also required each time for history).
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
In MT5 there were structures, but returns through functions still.
Forum on trading, automated trading systems and strategy testing
Overhead for OOP
fxsaber, 2017.07.07 08:08
The question was different, is it possible to create a wrapper more convenient than MQL4?
In MT5 there were structures, but return via functions anyway.
Maybe they decided not to break the tradition, but they should have.
I understand if the data was downloaded from the brokerage company server, but it is local, it is taken instantly, we could fill the structure immediately
They probably decided not to break tradition, although they should have
I understand if the data were downloaded from the DC server, but they are local, they are taken instantly, you could fill the structure immediately
Yes, during SELECT we just fill one instance of a hidden structure, the fields of which can only be accessed through const(read-only)-functions.
Probably, it's the only questionable decision of the trading API kernel. Otherwise, I don't even know what to complain about.
Yes, when SELECT is used, it fills one instance of a hidden structure whose fields can only be accessed via const(read-only)-functions.