My approach. The core is the engine. - page 5
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
Would you buy a bucket of radio components instead of a TV? In the same way, a kernel doesn't need to be bothered with details. But it's up to you, as long as it's convenient - fine.
The engine works with the Core using a technique I call"Focus Elements" (maybe not a good name).
The idea is as follows:
By moving the cursor around the graph, the user crosses object boundaries. Each Item has its own territory in the chart space. A special function monitors the cursor coordinates and marks which Window and Element the cursor is on.
The number of the window and element in the kernel, are written into the global variables. Then the engine uses these to access the kernel and retrieve all the current values of the properties of the Window, Element, and Object where the cursor is located.
When an event occurs (click, push-down, double-click, etc...), the block, which processes this event, immediately KNOWS in which window and with which element this event happened.
The main properties of the window, element, and object, are already in focus (i.e. already stored in global variables), and used in the code immediately.
This is very effective.
This is why the Kernel should be a simple global array....
That's why the kernel should be a simple global array.Pointer arrays have long been known in nature.
So much effort to reinvent the wheel... It's all there and in a much better form.
It's a funny thing about OOP - it causes a lot of psychological resistance in people. Even when you don't have to write classes, but only use them.
Why limit yourself to one kernel. In terms of this kernel approach, OOP is just a rabid kernel generator.
Pointer arrays have long been known in nature.
So much effort to spend on reinventing the wheel...
You see, all this entails the use of extra syntax, which is not practically necessary. The solution doesn't require this syntax and extra tools.
The solution may be primitively simple, but it is VERY effective. This is exactly what I am striving to do.
Why limit yourself to a single kernel. In terms of this kernel approach, OOP is just a rabid kernel generator.
Why is OOP here if the Solution doesn't require it?
Windows, Elements, Objects are represented and ordered in the Kernel. They are accessed through an array index or through the focus of Elements.
Why pointers, references, classes, constructors, destructors, and a million other things when the Solution already exists?
It is simple and self-sufficient.
We need OOP for quite a different purpose. I would need OOP if I created this technology with a team of other developers and each of us did only a part of the work.
OOP is needed for a completely different purpose. I would need OOP if I created this technology with a team of other developers, and each of us did only part of the work.
Mr. Well TC, let's give examples of your thoughts in code, let's discuss that OOP is "evil" later ... as they say: Codes on the table! )))
BUT, OOP is not needed when there is only one programmer and his tasks do not require OOP.
Mr. Well, let's give examples of your thoughts in code, let's discuss that OOP is "evil" later... as they say: Codes on the table! )))
Yes, I will prepare simple examples.
BUT, OOP is not necessary when only one programmer works and his tasks do not require the use of OOP.
Both theses are false.