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
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))).
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.
Waiting for the implementation of AI :).
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:
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 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:
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.
I'm glad you're making progress. You might even invent the wheel one day.
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:
...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.
...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.