A question for OOP experts. - page 52

New comment
 

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.

  • We take two parameters - x and y - from the "cursor" object. From them, create two derived parameter objects that will store the difference between the current and past values of x and y. (Parameter objects are not just variables, they are objects with their own properties).
  • Create a Handler Object for Parameter Objects that will (1)handle the x and y values, retrieving their difference between current and past values at the window handle event, which is written in the Handler properties, (2)write the difference to the derived parameters at the same event.
  • Create a Link Object between the derived parameter objects and the x,y parameter objects of each window object, which will be used to pass values to them.
  • After Object-binder, we create one more Handler object, which should take value from object-parameters x and y of each window object and add to it a value going on the binder.

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.)

 
Реter Konow:

Here is another example:

Consider a system for moving a window with controls on a graph.

  • We take two parameters - x and y - from the "cursor" object. From them, create two derived parameter objects that will store the difference between the current and past values of x and y. (Parameter objects are not just variables, they are objects with their own properties).
  • We create a Handler Object for Parameter Objects that will (1)handle the x and y values, retrieving their difference between current and past values at the window handle event, which is written in the Handler properties, (2)write the difference to the derived parameters at the same event.
  • Create a Link Object between the derived parameter objects and the x,y parameter objects of each window object, which will be used to pass values to them.
  • After Object-binder, we create one more Handler object, which should take value from object-parameters x and y of each window object and add to it a value going on the binder.

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.)

Difficult. Unjustifiably difficult.
The main object of a form, inside which other objects of this form lie, is the only one which receives coordinates. Changing any coordinate changes the position of the main object of the form. The other objects in that form are simply passed relative coordinates that determine their location within the form. All objects have their own order in the form, and are rearranged in that order. Each object has a list of what it contains within it. Referencing the list of contents allows each content to be given an offset command. Thus, by giving a command to a form object to shift, it automatically issues commands to shift all the contents of the form. That is, only the form is offset, and everything else is automatically offset. We don't have to give each form object an offset command by itself.
We do this for just one object. All the others will repeat it. No matter how complex a form object is, a single offset command will be passed to the entire contents of that form in an avalanche.
Everything is done only once. And then everything will be done in a chain.
 
Artyom Trishkin:
Complicated. Unjustifiably complicated.
The main object of a form, within which the other objects of that form lie, is the only one that receives coordinates. Changing any coordinate changes the position of the main object of the form. The other objects in the form are simply passed relative coordinates which determine their position within the form. All objects have their own order in the form, and are rearranged in that order. Each object has a list of what it contains within it. Referencing the list of contents allows each contents to be commanded to an offset. Thus, by giving a command to the form object to shift, the chain is automatically passed to shift all the contents of the form. That is, only the form is offset, and everything else is automatically offset. We don't have to give each form object an offset command by itself.
We do this for just one object. All the others will repeat it. No matter how complex a form object is, a single offset command will be passed to the entire contents of that form in an avalanche.
Everything is done only once. And then everything will be done in a chain.

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...

 
Реter Konow:

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.

 
Artyom Trishkin:

...

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.

  1. Imagine an array matrix. The dimensions are undefined. Perhaps it is infinite, perhaps it is not. It doesn't matter.
  2. The matrix is initialized with zeros. Zeros represent emptiness. That is, the matrix is empty.
  3. In the emptiness of the matrix, something other than emptiness has appeared. It's a zero replaced by a value. It doesn't matter what it is.
  4. We see this value in the empty matrix and say "this is a parameter". That is, not the value itself - but the cell in which it appeared. The cell is honoured with the title and called a parameter - that is, the "capacity" containing the value.
  5. The parameter immediately demands from us its definition. It is as if it is saying "I am a parameter, and I have a personality! Where are my properties?!". And we have no choice but to add to the parameter its properties, which are also parameters with their own values. We put them next to it and we have a chain - a parameter and its properties. We say "we created an Object-parameter!".
  6. Next, the parameter "says", "Where are the other parameters?! Why am I the only one?" And then we create a few more parameters in the void of the matrix, so that the "firstborn" is not bored. Of course, each of the new parameters declares its individuality and demands properties as its bearers. Thus chains of parameters grow, among which there are "first-born" and their properties. We say "We have created Parameter Objects!".
  7. Now in the emptiness of the matrix we have several parameters with chains of their properties. But each of them "screams" about the meaninglessness of their existence. Each of them is alone. Then, we decide to link the parameters so that they are not "bored". To do this, we create special parameters that serve as bindings between other parameters. They also consist of chains of properties. Now, the firstborn parameters are linked to each other by parameter chaining. Everyone is happy! We say, "We've created Parameter Bindings Objects!".
  8. But, then it turns out that the parameter-primaries want to communicate and transfer values to each other through bindings, but bindings provide for transferring values (parameter language), but do not provide for translation. And being alone, the parameters understand only their language, which means that there is a "language barrier" between the parameters and they require us to solve it.
  9. In order to solve the problem of "parameter communication" we did not have enough mappings, we needed a translation. This means that the values passed between the parameters need to be converted, taking into account the properties of each parameter. Some of them understand values in the range 1-10, and some understand (-5) - (-105). Some operate with fractional numbers, others with powers. Therefore, we conclude that we need 'translators', i.e. value handlers that take into account the properties of parameters. We create special Handler Objects and insert them into parameter mappings. Value Handler Objects "translate" the passed values between parameters using the properties of the parameters they pass and receive, and their own properties. We say - "We created Handler Objects! Now the parameters can communicate freely!".
  10. The first-born parameters were communicating and communicating and they got tired of it. Tired of it. Then they decided that they would communicate only on special occasions - well, when one of them gets an incredible value. But, as it turned out, we needed to keep an eye on the value, like a child, relentlessly. The first-born parameters asked us to think of a "monitoring system" that would signal unusual variations so that they wouldn't worry about it. So, we made a mold of the values to which we should react and added a special handler to it, which resulted in an "event object". We connected it to every parameter and they start communicating with each other using signals from event Objects. So, we created "Object-events".

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...

 
Реter Konow:

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.

 
Artyom Trishkin:

...

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.)))

 
The representation of systems in the Matrix gives a new perspective on their structures, but I did not see any hint of facilitating the creation of systems. Not to mention any "self-development". It's damned interesting to look at systems that way, but no more than that. I don't see any self-development or even a hint of it. Therefore, let's leave the divine to God. No self-development of systems can be achieved neither by standard OOP approach, nor by mine.
1...4546474849505152535455
New comment