A question for OOP experts. - page 50

[Реter Konow]

Vladimir Simakov:
Shit. Drunk. I've read it, but I don't understand much. Peter, understand that there are programming languages, many of them, their creators put into them certain mechanisms of memory management, and OOP is only one of the options. They are really different, really have their pros and cons. Therefore, if you want AI, fine, I envy it, because I never dare to do it myself. But you have to implement it not here, well, mql doesn't suit, exactly, as well as any other applied language. Read C here, even without C++, looks good. So, either you should switch to another forum or you're a "global" troll))).

Yes, I understand you. Thank you.

[Реter Konow]

Yury Kulikov:

What about the promised glass ..."an application of a fundamentally new level.A level previously unreachable by any MQL programmer".

Not waiting any longer?

Nobody needs a spherical platypus.)

Mediocre"Grails" of algotrading have subjected to "genocide" all the brilliant beginnings in MQL. Destroyed their meaning.

I hung on to the last one.

[Реter Konow]

Aliaksandr Hryshyn:
Waiting for the implementation of AI :).

Ok.))

[Реter Konow]

I don't want to leave this thread, so I'll report on recent progress.

The new concept of OOP, as a "hybrid" of my representation of objects in the kernel and the standard description of objects in the class, has become more "object-based" than the usual OOP. To explain:

Now, all entities are objects. Specifically:

• Object-parameter (property).
• Object-state
• Process object
• Object-event
• Parameter-bindind object
• Parameter handler object
• Value filter object
• Value converter object
• Object-system
  

This is not a complete list of the basic objects that make up a functioning system.

The point is that each of these objects is a real Object, i.e. it has properties and relations within the system.

For example, object-parameter, - has a set of properties, among which type of value and borders of its change. Also, Object-parameter can point to its handler.

Further, - Object-state, - is an assembly of system or environment parameters with preset values.

Another, - Event object, - is any meaningful change to the system or environment. It is an assembly of parameters with specific values, checked by special handler. An event acts as a trigger for various system objects.

Parameter objects are linked by object links that pass values between them. For example: Parameter A can pass a value to parameter B, or vice versa. Or both. This is prescribed in the Parameter Link Object. In the value transfer path, there can be a value filter object or a value converter object.

Each object in my concept necessarily has a template (source form) and n number of instances.

The bottom line is that all of the above objects are universal building blocks of any system, of any complexity. There are not so many of them, but infinitely many variants of systems which can be constructed out of them.

At the moment I am at the very beginning of my journey. There is still a lot to understand.

[Koldun Zloy]

Реter Konow:

I don't want to leave this thread, so I'll report on recent progress.

The new concept of OOP, as a "hybrid" of my representation of objects in the kernel and the standard description of objects in the class, has become more "object-based" than the usual OOP. To explain:

Now, all entities are objects. Specifically:

• Object-parameter (property).
• Object-state
• Process object
• Event object
• Parameter-bindind object
• Parameter handler object
• Value filter object
• Value converter object
• Object-system
  

This is not a complete list of the basic objects that make up a functioning system.

The point is that each of these objects is a real Object, i.e. it has properties and relations within the system.

For example, object-parameter, - has a set of properties, among which type of value and borders of its change. Also, Object-parameter can point to its handler.

Further, - Object-state, - is an assembly of system or environment parameters with preset values.

Another, - Event object, - is any meaningful change to the system or environment. It is an assembly of parameters with specific values, checked by special handler. An event acts as a trigger for various system objects.

Parameter objects are linked by object links that pass values between them. For example: Parameter A can pass a value to parameter B, or vice versa. Or both. This is prescribed in the Parameter Link Object. In the value transfer path, there can be a value filter object or a value converter object.

Each object in my concept necessarily has a template (source form) and n number of instances.

The bottom line is that all of the above objects are universal building blocks of any system, of any complexity. There are not so many of them, but infinitely many variants of systems which can be constructed out of them.

At the moment I am at the very beginning of my journey. There is still a lot to understand.

I am glad you are succeeding. Perhaps one day you will even invent the wheel.

[Реter Konow]

Koldun Zloy:

I'm glad you're making progress. You might even invent the wheel one day.

I'm pleased with your understanding. That's why I calmly express my thoughts here. Sometimes, though, I hope that there is someone here who understands more.

[Реter Konow]

I will try to describe an ordinary GUI control, the button, through the prism of my new OOP concept. I will use only my own concepts when analyzing this Object-System.

And so, we have:

• An object-parameter with type property, whose value is bool (values 1/0). We write it in the kernel.
• The parameter's shell object (the button itself) is a rectangular graphical label. The properties are x, y, x_size, y_size, color. Recorded in the kernel.
• 2 shell state objects. Two assemblies of parameters - color, x,y, with values prescribed.
• Object Cursor. An assembly of four parameters: x,y, cursor and state of the left (1/0) and right (1/0) buttons.
  
• Button shell event object. An assembly from the parameters - x,y cursor and button shell space parameters (x,y, x+length, y+height).
• Event handler object, checking the position of the cursor and button and the state of the left mouse button.
• Event handler object for changing the state of the shell on the click event.
• Event handler object for value change of button's parameter (meaning the main parameter that controls the button - (1/0)).
• An object-link of button's parameter to the external system.

Here is an example set of objects needed to build a system object of a simple button, working with a more complex system. All this can be built from templates of these objects and operated by instances in the kernel.

[Dmitry Fedoseev]

...and operate with instances in the bucket:)

Why write something in a bucket, especially something related to a specific object? The object itself stores information about itself, and the bucket only contains pointers to objects.

[Реter Konow]

Dmitry Fedoseev:

...and operate with instances in the bucket:)

Why write something in a bucket, especially something related to a specific object? The object itself stores information about itself, while the bucket contains only pointers to objects.

Ask Artem. I think he knows better than anyone what I am writing about.

By the way, the idea of an object-property with its own handler was originally his. I developed it and made it more complicated. Now everything is an Object and so is the handler. There is simply a certain order of connecting Objects when building a system out of them.

[Aliaksandr Hryshyn]

"New OOP concept" - not clear on the purpose. What are you doing this for?