My approach. The core is the engine. - page 14
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
The format is simple, but it's not working with it. I mean when there are a lot of properties in objects.
Here's an example of your approach, actually used, the principles are the same. Lexical parsing of text, it's very hard to do anything manually. Only automation. And don't say it is convenient.
The array of prototypes shown is a result of manual initialization of Object properties with default values. It is seen only by the developer.
Main Kernel - is compiled automatically from element prototypes. Then the prototypes are converted into concrete elements. Also automatically.
As for working with the constructor, there are simple keywords and convenient form of drawing. There are no such tables there.
Here's another example that fits your idea, just a lot of dynamic elements. There are entire strategies, three of them in the example. There's not a lot of convenience here. In the attached file.
That is, in order to maintain the dimensionality of the array, some of your objects have fake properties. It's very flexible, you can't say anything about it.
Alas, we have to temporarily put up with this inconvenience. On the other hand, a two-dimensional kernel provides extremely convenient and fast access, building in loops and much more. If you make one-dimensional kernel, there will be no "fake" properties. But the convenience will become many times less. Or, you could simply put the text and icon properties in a number of Core properties. And the problem will be eliminated. I will do so in the future.
Here's another example that fits your idea, just a lot of dynamic elements. There are entire strategies, three of them in the example. There's not a lot of convenience here. In the attached file.
I have initially warned the readers that my approach is not aimed at convenience of a programmer. I am offering the conception of the most powerful and fastest development of a program.
Of course, they will say that the fastest development of a program is to plug in ready-made blocks. Yes, but the program quality drops and overhead grows. Joining blocks is not the best solution in terms of efficiency.
I initially warned readers that my approach is not focused on programmer-friendliness. It offers the concept of the most powerful and fastest development of a program.
It is convenient when the programmer does not directly modify/create such data.
Using code that works with such data is quite handy.
I initially warned readers that my approach is not focused on programmer-friendliness. It offers the concept of the most powerful and fastest program development.
How can these two points coexist together: lack of convenience for the programmer and fast program development? How can you develop a program quickly if it is not convenient?
What's the problem with controlling? Add a property, and increase the size of the Kernel rows. That's all.
And what will you do if it will be necessary to make not rectangular button, but circular or triangular?
If you use OOP, you will create a base class Button, which has an abstract method Draf - this method is responsible for drawing buttons. For a round button, you will need to create an heir of Button, which will suffice to override the Draf method, which will implement drawing of the round button. For a rectangular button, it will also suffice to create an heir of Button and override the Draf method to draw a rectangular button.
What would it all look like if you use your method?
Here's another example that fits your idea, just a lot of dynamic elements. There are entire strategies, three of them in the example. There's not a lot of convenience here. In the attached file.
No way!
It's a beautiful thing... it's a stackable automaton.
with minimal knowledge of assembler and Forth, it's a breeze to read. If there were comments, it would be no more complicated than MQL.
This is handy when the programmer does not directly modify/create such data.
Using code that works with such data is quite handy.
You'll see, an array of prototypes is created once. And then, it is changed VERY rarely. Only in case of serious modifications in program.
No way!
It's a beautiful thing... a clear stack machine.
If you know assembler and Forth as little as possible, it's read in a jiffy. If there were comments, it would be no more complicated than MQL.
It's a cool gizmo.) You agree, that it's easier to write programs in MQL than in assembler. I'm talking about usability, efficiency.