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 looked through my new prism, a hybrid of OOP and Kernel, at the object systems described in the programs, and nearly burst my brain. First of all, I took a new look at my GUI systems. Through all these objects-parameters, objects-states, objects-events and handlers. Since the GUI and its technology is familiar to me, everything seemed quite clear, but, the system is very complex. A mass of parameters, mappings and handlers. I have come to the conclusion that such systems can not arise by themselves. And natural selection has no power here.
Here's why:
Each parameter may have n number of derived parameters. Let's say: a change of X can generate infinitely many derived parameters from the values of that X at any given time.
Each derived parameter must have a handler and a link to other parameters. No parameter exists by itself. The link is mandatory.
The coupling can be different, and consequently a variety of handlers-filters, correctors, transducers-can appear.
The events that can be considered significant for the systems are indefinitely many. Each one has its own properties, links and handlers. The variations are innumerable.
Thus, without a concept, no system can emerge. (Most likely).
It is only unclear how life on Earth originated...
Here is another example:
Consider a system for moving a window with controls on a graph.
Thus, with this system, we can change the coordinates of a window and its objects at the event of its handle being grabbed by the cursor. To move it all, we need to associate it all with the ObjectSetInteger handler functions that change the position of the MT object on the chart.
This is an implementation of just one GUI function by linking special system blocks - Object Parameters, Object Handlers, etc...
To build such a system in the Kernel, is not a bit easier (or maybe even harder) than to write normal code without turning everything into an Object. But, I'll keep digging...
ZS. I forgot to add that in order to move the window, we also need to "craft" an Event Object, which locks the window handle and the cursor's movement. And this event object, connect it to the object handler of cursor x,y values (that writes the difference in derived parameters), and it would work only on signal of this event.
And for every event object, you need to create an object handler and bind it to it.
Each object-handler has its own properties, and its values are used by it when it works with parameters or events. Therefore, there must be a template, or you'll get bogged down creating it all.)
Here is another example:
Consider a system for moving a window with controls on a graph.
Thus, with this system, we can change the coordinates of a window and its objects at the event of its handle being grabbed by the cursor. To move it all, we need to associate it all with the ObjectSetInteger handler functions that change the position of the MT object on the chart.
This is an implementation of just one GUI function by linking special system blocks - Object Parameters, Object Handlers, etc...
To build such a system in the Kernel, is not a bit easier (or maybe even harder) than to write normal code without turning everything into an Object. But, I'll keep digging...
ZS. I forgot to add that in order to move the window, we also need to "craft" an Event Object, which locks the window handle and the cursor's movement. And this event object, connect it to the object handler of cursor x,y values (that writes the difference in derived parameters), and it would work only on signal of this event.
And for every event object, you need to create an object handler and bind it to it.
Each object-handler has its own properties, and its values are used by it when it works with parameters or events. Therefore, there must be a template, or you'll get bogged down creating all this.)
Complicated. Unjustifiably complicated.
That's right.
Binding between derived parameters containing the x,y difference of the cursor and form objects (which are in the chain) has a handler in the centre that can perform a serial connection to the x,y parameters of each form object. That is, binding parameters via the serial connection handler allows to replace the binding of each form object with derived parameters passing values of difference x,y. I was also thinking about it.
In my GUI, window moving is implemented inside function doing the following:
(1) Event checker for window handle click event
(2) Move cursor event
(3) Calculating the difference between the current cursor coordinates and the past cursor coordinates
(4) Cycling through the window objects and changing their coordinates by adjusting the difference in the cursor position.
(5) Calling the ObjectSetInteger to move the МТ-object of the window form (canvas) along the chart by the given distance.
Thus, the implementation within the function is correct. The implementation through Object Handlers, Object Parameters and Object Bindings looks awkward against this background. But, let's dig in...
This is correct.
The mapping between the derived parameters containing the x,y difference of the cursor and the form objects (which are in the chain) has a handler in the middle which can perform a serial connection to the x,y parameters of each form object. That is, binding parameters via the serial connection handler allows to replace the binding of each form object with derived parameters passing values of difference x,y. I was also thinking about it.
In my GUI, window moving is implemented inside function doing the following:
(1) Checking for window handle click event
(2) Move cursor event
(3) Calculating the difference between the current cursor coordinates and the past cursor coordinates
(4) Cycling through the window objects and changing their coordinates by adjusting the difference in the cursor position.
(5) Calling the ObjectSetInteger to move the МТ-object of the window form (canvas) along the chart by the given distance.
Thus, the implementation within the function is correct. Implementation through Object Handlers, Object Parameters and Object Bindings looks awkward against this background. But, let's dig in...
Yes, because you don't need to make these handlers separate from the object. The class that returns the cursor coordinates can be made static - it will be available to any class in the program, and getting the coordinates and responding to them should be implemented in every object. But only the main form object should call these handlers. Then for all other form objects it is sufficient to specify new coordinates and redraw. Inside the form object there is a list of all its objects. The form object has defined change of its coordinates - sets new values to its coordinates, goes through its list of objects and calls methods to set coordinates of each object in its list. At the same time, every subsequent object does the same thing when its coordinates change - it looks through its list of objects and commands them to change their coordinates. The objects in the lists are arranged in the order they are drawn (Z-sequence). In other words, each object has its own method of changing coordinates, but it is implemented in the same way - it looks through the list of all "friendly" objects and calls the same method for each of them. Thus, by calling this method once for the main form object, we automatically start a coordinate change for all objects in the form. After all of the form object's "own" objects have been processed, the form object's redraw chart method is invoked, which is the same for all of the modified objects.
...
This is the standard OOP view of the window movement mechanism. I'll show you a different one. To do this, clear your mind for a second and just follow my thought.
That's the end of the tale...
We looked at the matrix from the outside and gasped! "We've created an Object System!")
ZS. Notice that everything can be created in an array-matrix. And the array-matrix is the Core. And entities in it - the real objects. And parameters, and events, and bindings, and properties, and handlers. There are uncountable systems which can be constructed in the Kernel from these base things.
A mock continuation...
11. Somehow the first-born parameters decided to follow a fashion. They found out that there is a property fair somewhere in the matrix, and a certain space in the novelty. They say it has three properties. "Dimensions" are called. These properties have a supposedly infinite range of values, and as a bonus they give away another "parameter-time". The parameters came to the fair and took the properties x,y,x_size,y_size. They say they want to make a shell in space. And they took colour. They returned and started to dress up the new properties. They modeled and modeled some spatial envelopes until they got tired of it. They grew immensely, then collapsed... Then they put colours on themselves and relaxed. They started to think what to do next. And then they looked at the time-property box. Let's see what it is... They opened it, attached it to themselves, but they did not calculate the values and in a moment it evaporated into emptiness. After all, time is a parameter with which one must be very careful...
A mock continuation...
11. Somehow the first-born parameters decided to follow a fashion. They found out that there is a property fair somewhere in the matrix, and a certain space in the novelty. They say it has three properties. "Dimensions" are called. These properties have a supposedly infinite range of values, and as a bonus they give away another "parameter-time". The parameters came to the fair and took the properties x,y,x_size,y_size. They say they want to make a shell in space. And they took colour. They returned and started to dress up the new properties. They modeled and modeled some spatial envelopes until they got tired of it. They grew immensely, then collapsed... Then they put colours on themselves and relaxed. They started to think what to do next. And then they looked at the time-property box. Let's see what it is... They opened it, attached it to themselves, but they did not calculate the values and in a moment it evaporated into emptiness. After all, time is a parameter you have to be very careful with...
And the first ten were not serious?
I, for one, cannot read without laughing.
...
All this "objectivity" is very confusing, don't you agree... You have to be careful with it. Nikolai Semko was right about the proximity of genius and schizophrenia. It's possible to 'go crazy'. There are some things it is better not to understand. Some doors, must always be closed to our Consciousness. As one movie said, - "the most dangerous parasite is an idea. Once in the brain, it's impossible to get it out." The matrix I was talking about is dangerous for the Mind. It's easy to get lost in it and get lost forever. Let's be careful.)))