My approach. The core is the engine. - page 16
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
At the moment, I have one customer. I complete his tasks very quickly. 3-4 hours and a new, fully functional window is ready. Together with the connection interface. I also quickly fix bugs in the engine and send him new versions. 9 windows in a few days + engine changes, bug fixes, adding features... All very fast.
You must have a lot of free time.
You understand that you alone are not enough. The massiveness of your engine will depend on whether other programmers like it (you alone are not enough for all customers). And if the progerms don't like it, then... alas, the fate of your creation will be glorious.
The programmers will not have to get into the engine code. They will get the connection interface to it in the file. I've already tested it. Everything works.
At the moment, I have one customer. I complete his tasks very quickly. 3-4 hours and a new, fully functional window is ready. Together with the connection interface. I also quickly fix bugs in the engine and send him new versions. 9 windows in a few days + engine changes, bug fixes, adding features... All very fast.
Does it say it right? 3-4 hours to create a window? Not minutes?
I've actually been doing it for over a year now. And I don't get confused.))
For comparison, implement the same thing using OOP. Maybe you will like it. :)
Does it say it right? 3-4 hours to create a window? Not minutes?
No. You can do it in minutes if you copy code from another window and make changes. But I was talking about creating it from scratch, with thinking about graphics and working on style.
By the way, Peter, don't forget to add all sorts of graphs, like indicators, only in windows, with support for a couple of data formats(OHLC, like Zigzag, etc.). I hope it's all easily implementable in your project.
I'll try.
I'll try.
I won't try, I will). Increases the usefulness of your creation.
Does it say it right? 3-4 hours to create a window? not minutes?
What nonsense... making 3 windows in MQL even using libraries from standard MT toolkit takes 10 minutes and another 20-30 minutes to fit height and XY of buttons, edits, labels...
I can see 2 possibilities why Petr's work may be useful:
- creation of a separate application to generate MQL source code, i.e. GUI constructor and not to go into details of how it works, so to say Visual MQL++ )))
- Or: there are people who create their own difficulties and then successfully overcome them © Wingston Churchill
It seems to me that all of Peter's OOP components are constantly clinging to details.
And the core of the issue is precisely the philosophy and architecture of the system.
It was rightly said above what the controversial issues are, which seem to be advantages to Peter and disadvantages to his opponents:
- heap of globally accessible variables, no encapsulation at all.
- lack of type control
- a rigid reliance on a particular implementation of data storage.
And Peter correctly said that the concept of OOP (at least in my suggestions) is designed to simplify, "based on programmer convenience". Encapsulation, type control, interfaces - all this is designed to eliminate the very possibility of error, confusion, misuse as much as possible. That's right.
Peter's concept is the opposite. All data are accessible from anywhere, the user from anywhere in the code has full control over all the objects in the program and he can perceive them as he wants without any type restrictions (well, except for the restrictions of MQL).
Peter says that this concept "allows to achieve the maximum development. Usability comes second".
Personally, as a programmer, I already dislike that convenience comes second. But you can sacrifice this if you actually get a lot more development. Well, I want to see what it is. Where OOP-approach with constraints and encapsulation doesn't allow to reach such development, as this approach with full access to the huge array of properties, thrown in one array of monstrous sizes. (Not to mention the need to remember it all).
As rightly pointed out above, the approach is reminiscent of Pascal's TurboVision. Although, type control and encapsulation constraints have already been implemented in that library.