![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
What are "appendices" written in?
In application languages.
Part 2.
In the first part we talked about the constituents of the Object, but in this part we will consider their relations to each other. The components themselves will be conventionally called"Proto-blocks", because they are not full-fledged objects, but represent some "building" entities that are part of all objects and systems. Let me remind you of their initial list:
In addition to the parametric "body" of Form, State, Event and Process, we will add a handler function (let's call it simply "handler") whose task is to "transfer" values from its proto-block to the Object's parametric set. For example: a Label has 5 parameters in a constructor function and this set is its parametric "body". Suppose we have invented a new state and written it as different values of the initial parameters, and the moment we need to move the Label to a new state, we need to call a function that transfers them from the parametric structure of the State to the parametric "body" of the Label. Simply put, this handler initializes the Object parameters with the values of its proto-block. For Process and Form, similar principle works with value transferring to Object's body but the implementation is different. But to processan Event we don't need to transfer the values - we need to check them, so a condition statement will do as a handler.
There are many handlers in my concept and they deserve a separate classification, but it would complicate the presentation too much and therefore I will touch upon them superficially, roughly dividing them into several groups:
This is by no means a complete list and names of handlers are arbitrary, but the division of their specialisation, in general, looks like this.
The next addition to the concept after handler functions would be"Modules". It is logical to assume that created proto-blocks must be stored and organized somewhere, and it is also easy to guess, that it would be optimal to separate storing of proto-blocks of different types to avoid confusion and let handlers easily "navigate" through growing contents of the Object. Hence, we create "storages" or, as it is even more beautiful,"Modules" of proto-blocks. For States, Processes, Events and Forms of the object will be created their own modules in which the proto-blocks will be:
The fourth point - of "linking" proto-blocks of different types is precisely based on their "structural inclusion" into each other, which I spoke about in the first part - Process includes States,... Event includes State,... A process includes Events,... A State can include a Form, and so on... For example, if we build our event model in a separate module, then its condition hierarchy will contain Events that are stored in the 'Event' module, and these Events in turn contain States that are stored in the States module. In this way, we not only create an efficient way of storing and using proto-blocks, but we also implement their "structural inclusivity" simply by connecting them to each other with links between the modules. By arbitrarily or thoughtfully changing links, we can create new proto-blocks from existing ones, as well as change the event or logic model in the Object's "behaviour". Changing the relationships at the level of the logic model (which in turn will be stored in its module) can completely change the program, and in doing so, we do not have to rewrite anything in the code. This is where I see the advantages of modular separation of proto-blocks.
That's all for now. Next, I'll move on to event and logic models and consider how they are constructed.
Ask questions if anything is unclear or interesting.
What is the concept for?
This concept is an attempt to move to the next level of programming, which in my view will be 'building' (rather than writing) functional systems by the computer itself, rather than by humans. The software will be able to create programmes.
There is now a neural network trained on githab code, but that's not what I mean at all.
This concept is an attempt to move to the next level of programming, which in my view will be 'building' (rather than writing) functional systems by the computer itself, rather than by humans. The software will be able to create programmes.
There is now a neural network trained on githab code, but that's not what I mean at all.
Hello Peter.
Besides OOP there is also DDD(Domain-driven design)
Just to keep you informed.
Hi Peter.
In addition to OOP, there is DDD(Domain-driven design)
Just so you know.
You're confusing the warm and the soft.
You're confusing the warm and the soft.
Where's the signal, bro?
Where's the signal, bro?