Mt4 End of support. - page 28
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
I don't know if anyone has suggested it, but why not move everything in MT4 to MT5, then everyone would move on.
George Merts:
They write the parts first and then combine them into a whole, often finding that the parts are not compatible with each other - which, incidentally, is what explains the desire to "have access to all available variables".
No, it's not. It's not about having access to all possible variables, just the ones you need. These are usually input and output variables of different functions.
Adding additional boundaries here will immediately make code readability much harder and increase possible errors when something did not get there because it got lost on the way because of these boundaries.
Certainly understandable desire at least somehow to pull back OOP for something useful, but such cases usually lie not in the field of programming, but in the commercial sphere, for example for extra programming hours, creation of endless discussions about architecture of interfaces and the like pleasant pastime in working time.
Is there, in principle, an example of this? Even if not yours? I have deep doubts. In the beginning of the two-thousandths' years I stopped counting the number of debugged and working lines of program code written by me because it exceeded a million - it became uninteresting. And I've never encountered a necessity to create my own class, although the variety and scale of my tasks were very diverse. I had to use procedure-type variables when it was necessary to parallelize work for several people but no more. Why is this so?
The point is that OOP can be applied only to the packaging of the ready code and it only prevents from it at the stage of code writing. But if there's no such a need, you don't need OOP either.
Vladimir:
It turns out that OOP prevents automatic paralleling of computations. Nowadays it should be considered as a very serious drawback, the perspective is not for OOP.
The perspective is in languages like Systemverilog.
It's OK, except for the fact that the isNewBar() function shouldn't exist at all. It's funny that there's so much dancing around such a trivial thing.
It's just a variable, and it's simply compared to the time of the bar; if all the cases succeed, then the variable is assigned the time of the new bar at the end. Otherwise only one attempt is allocated to all cases.
Adding additional boundaries here will immediately make code readability much harder and increase possible errors when something did not get somewhere because it got lost on the way because of these boundaries.
It's just the opposite - the boundaries allow you not to think about "why this variable, what role it plays in this case, should it be taken into account?".
The user has access only to what they need to consider, and only to what they can change. These are the very errors "when something is lost along the way" - and arise precisely because too much is available, and something is "forgotten along the way". With "truncated" virtual interests, this is much more difficult to do.
Here is the simplest example: gaining a position. A position is either open orders in MT4 or open positions in MT5.
If you have full access, then when selecting a position - the user has to remember which variables can be read now, which variables are invalid at the moment, which variables he can change, and which are not.
With the interface, things are much simpler. You got it, and it only has two functions: get the number of components, and get a pointer to a constant component. THAT'S IT. With these two functions - you physically can't get access to any "extra variables".
Andrei:
Of course, I understand the desire to at least somehow drag OOP for something useful, but such cases usually lie not in the field of programming, but in the commercial sphere, such as extra programming hours, endless discussions about the architecture of interfaces and the like pleasant pastime in office hours.
And you will come to this sooner or later. Moreover, encapsulation can be done in a "purely procedural" approach. But it is more convenient in the OOP approach, because you still get inheritance and polymorphism "automatically".
I don't know if anyone has suggested it, but why not move everything in MT4 to MT5, then everyone would move on.
The problem is not just that there is something in 4 that is not in 5. And it's not even the OOP.
5 has given practically nothing to traders (not programmers, not software traders - just traders).
Own history format, prohibition on custom - but these two points have scared away everyone who trades geometry. And no "many TFs" (with no yearly, lol), scales in pips per bar will attract them.
A simple question. What does the "grid" show? Trying to find out will lead you to the recommendation to go to freelancing and order whatever you want.
MTs are terminals for programmers. That's the whole answer.
The matter is that OOP can be applicable only to packing of ready code, at a stage of code writing it only interferes. But if there is no such necessity, there is no need in OOP.
No, it's not. It's just the other way round.
Interfaces are defined initially, even "before the stage of code writing". Interfaces are, in fact, all the same ToR for the programmer. All the interactions in Freelance are performed using explicit ToR. So, the virtual interfaces are a kind of TOR, which is where the programming starts.
You just, as I understand it, are approaching the very essence of OOP incorrectly. You write a bunch of functions first, and then you have to "squeeze" them into the OOP design. But this is a wrong way. The correct way is the opposite - firstly you define OOP-definition, those sets of basic interfaces between components of the system. And then one by one each component is written following these very predefined interfaces.
Yes, sometimes it happens that we find out when writing the code that the interface has not provided for something. And then you start... "Ohhhh... In the procedural approach - I'd have access to all this, I'd have no problem doing what I need, but now - how do I get access to these variables?". This happens when in the design stage of interfaces - something was not taken into account. This is a very unpleasant situation - you either have to add some additional interfaces, or change the existing ones - which is fraught with errors. This situation should of course be avoided.
Here is the simplest example: getting a position. A position is either open orders in MT4 or open positions in MT5.
If you have full access, when selecting a position - the user has to remember which variables can be read now, which variables are currently invalid, which variables he can change, which are not.
With the interface, things are much simpler. You got it, and it only has two functions: get the number of components, and get a pointer to a constant component. THAT'S IT. With these two functions - you physically can't access any "extra variables".
Just the opposite is true. Users often need to know internal variables for quality testing of modules, for example, and this is not the case. And special clever ways are invented to get this access afterwards. So there is no redundant information in principle, and those who don't need it may simply not use it.
This is exactly the opposite. Users often need to know internal variables in order to test quality modules, for example, and this is not the case. And they come up with special clever ways to get this access afterwards. So, there is no needless information, and those who don't need it simply don't use it.
If you need "crafty access to get it" - it indicates incorrect system design.
For example, if we write a generator of input signals - we should not have access to information concerning, say, money management.
Of course, during debugging there may be a situation, say, when there was no entry - we should immediately eliminate the situation, when it happened because the money management prohibited the operation (say, there is not enough margin). And how do you know about it from the entry generator? You do not - you do not have access. But in this case - it is enough to make sure that the generator has set a signal for entry, and it worked correctly. There was no input - for some other reason, which lies outside the input generator. Finding out the reason in this case is really more difficult than if we have access to all variables of the money management directly. But, it is much more dangerous that in normal, routine operation - we, having access to them - will "get in the wrong place".
If 'tricky access to get' is required, it is an indication of faulty system design.
Development is first and foremost a natural process of the mind.
In this process, ideas are formed freely and even spontaneously.
Following an OOP makes it difficult to transform the code freely.
In the natural process of development, the code itself gradually shrinks and universalizes.
In the natural process, the functions do not break up but on the contrary grow and unite into large blocks.
Large blocks solve a wide range of tasks.
OOP prevents these blocks from forming, leaving the code fragmented.
OOP creates complicated access, which steadily increases the number of references to variables.
The benefits of granularity are outweighed by the difficulty of making a coherent mechanism.
The main disadvantage: OOP forces us to follow the way of splitting the code into a number of functions.
It is easier for a human to accept fragmented code, but fragmentation is contraindicated to any mechanism.