My approach. The core is the engine. - page 135
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
There's a different problem there. The limitation of the core elements and parameters. I know what the solution should be. I just haven't had a chance to do it yet.
That's why I'm asking. If you've got 21 strings sewn into the kernel, it's not very good and you can't just fix it.
No. It's external code that's written for the constructor. That reproduces the table. Then I click the button and all the connection files and the boot kernel for the engine are printed. Then everything works.
As I understand it is an autogenerator which generates the autoconnect code plus some of the kernel code. This is an interesting solution.
I haven't tested it yet.
It works for me. But there seems to be a problem with closing a row when a stop is triggered. Sometimes the row remains. This is a problem with detection of closed orders in the code I have written. The table has nothing to do with it.
1. That's why I'm asking. If you've got 21 lines in the kernel, it's not good and you can't just fix it.
2. I understand it's an autogenerator that generates the autoconnect code plus some of the kernel code. Interesting solution.
1. Exactly. A limited number of elements can be prescribed in the constructor. Hence, a dynamic table must consist of a limited number of rows, but at the same time, be unrestricted. The solution is only to create special arrays for added parameters and scroll their values through the table cells.
2. Yes. Constructor creates kernel for engine based on the code you cited. + prints the connection files. Then, I put the kernel into the engine (DRIVE). After that, the engine can play the desired GUI. The interface files connect to the EA and start interacting with it.
So as not to be unsubstantiated, I will finally give you an example of the "kernel" itself. More precisely, it is a boot file. There are several kernels.
Let me remind you that it is printed automatically, based on KIB code. Then placed in the engine. Further, the engine works with it.
Nikolay, let's talk about the subject. Take CCanvas class, for example, which I have already dealt with. So, I took out all functions from it. Made them independent from the class wrapper. How is it worse now? It became easier to work with them. I made an animation using these functions. Before that, I hardly ever saw any animations with this class.
So why this wrapper?
You're drawing on a canvas too. You could just call a specific function and draw. But no. You wrap and wrap and wrap. So explain to me, why?
Yes, because it's mega-comfortable. But it's very hard to understand until one starts using it oneself.
I'm not able to think in a way that makes it convenient for me. Therefore, it's not convenient for me. Wrap around, depict object orientation. To classify when necessary and not necessary...
One gets the impression that OOP itself gets in front of the mechanism it's supposed to serve. That is, the mechanism must strive for integrity, hence for the smallest number of its blocks. But OOP forces these blocks to multiply for any reason. As the result the structure of mechanisms is tattered and they do not work well. And they develop even worse.
Nikolay, start creating mega-mechanisms (10 times larger than the Kanvas class), and you will understand where and how OOP becomes inconvenient.
I don't know how to think in a way that makes me comfortable. Therefore, for me, it is uncomfortable. Wrapping around, portraying object orientation. Classifying when necessary and not necessary...
One gets the impression that OOP itself gets in front of the mechanism it's supposed to serve. That is, the mechanism must strive for integrity, hence for the smallest number of its blocks. But OOP forces these blocks to multiply for any reason. As the result the structure of mechanisms is tattered and they do not work well. And they develop even worse.
Nikolay, start creating mega-mechanisms (10 times larger than the Kanvas class), and you will understand where and how OOP becomes inconvenient.
Your words say only one thing:
...
Nikolai, has it ever occurred to you that your love for OOP is not justified by almost anything but abstract reasons?
Say, if you were creating gigantic mechanisms with this OOP, it would be clear why you need it so much. You'd specifically justify why you need OOP. But, you create relatively small mechanisms. There is not enough code there to draw conclusions about disadvantages and advantages of this or that approach. But you keep talking about OOP anyway. While OOP is just a tool, and has no sense by itself. That is if there is no mechanism to be made, OOP is not necessary. But if there is a mechanism, it should be serious enough to require OOP while creating it.
Most of those who stand up for OOP do not make anything serious. They only do small things. However, their belief in OOP is unshakable. Others who make much more serious mechanisms are much less likely to shout about the greatness of OOP. Some even speak out with criticism (there have been a couple of times).
So, your argument needs to be backed up by practice, not just theory. I, for example, can argue about the benefits of OOP in GUI development with Anatoly, because we can compare solutions and their nuances in practice. But, with you, I can't deploy my argument because you won't understand it. You will, but you won't understand it (no offence). Anatoly, on the contrary, can understand it very well. The difference in experience of creating global mechanisms is the main reason for misunderstanding.
SZY. As a practitioner I will tell you this: The approach must be such that it would maximize the potential of the brains of a particular programmer. I have found such an approach for myself.