Un unrestricted inheritance leads to 'degeneracy' of objects - General

Igor Makanu 2019.10.06 12:23 #401

Vladimir Simakov:
Shit. How would you like to create an mql delegate? Just for fun, for the sake of raising the BSD.

analogue can't, did so, checked in MT4 works so far, but in MT5 no longer works

typedef void(*TFuncvoidPTR)(void);
//+------------------------------------------------------------------+
void OnStart()
{  TFuncvoidPTR arrPTR[3];
   arrPTR[0]=f1;
   arrPTR[1]=f2;
   arrPTR[2]=f3;
   for(int i=0; i<3; i++)
      arrPTR[i]();			// ' ) ' - expression expected

}
//_______________________________________________________________________
void f1() { Print("1"); }
void f2() { Print("2"); }
void f3() { Print("3"); }
//+------------------------------------------------------------------+

2019.10.06 16:22:44.202 tst EURUSD,H1: 3

2019.10.06 16:22:44.202 tst EURUSD,H1: 2

2019.10.06 16:22:44.202 tst EURUSD,H1: 1

Dmitry Fedoseev 2019.10.06 13:12 #402

Igor Makanu:

analogue can't, did so, checked in MT4 works so far, but in MT5 no longer works

2019.10.06 16:22:44.202 tst EURUSD,H1: 3

2019.10.06 16:22:44.202 tst EURUSD,H1: 2

2019.10.06 16:22:44.202 tst EURUSD,H1: 1

The fundamental difference from c# is this line:arrPTR[0]=f1;

It should look something like this:arrPTR[0]=new tralala(f1);

Or something like that. What I don't understand is, how could anyone want to do that? And to talk about the adequacy of someone else's thinking.

INFO indicator I need Insert indicator into another Any questions from newcomers

Igor Makanu 2019.10.06 13:34 #403

Dmitry Fedoseev:

The fundamental difference from c# is that this line:arrPTR[0]=f1;

It should look something like this:arrPTR[0]=new tralala(f1);

Or something like that. That's what I don't understand - how could one manage to want such a thing? And to talk about the adequacy of someone else's thinking.

In Sharpe, the concept: "take the stuffing from all existing languages" + add magic in the form of pure and obligatory OOP in any case - you get any solution up to

int a = new int();
char b = new Char();
string c = new string(new char[] { });
string d = String.Empty;
String e = String.Empty;

and after seeing this code a C++ programmer starts looking for hidden meanings in it.... but there is no point! - the only point is to gather all non-programmers under C# imho ))))

A truly amazing result!!! From theory to practice The agony of choice

Реter Konow 2019.10.06 14:28 #404

The reasons why unrestricted inheritance leads to 'degeneracy' of objects are found.

EXPLANATION:

1. We declare a base (abstract) class A.

2. we construct a long chain of inheritance from it. For that purpose we create 10 heirs from A and 10 descendants from each of them. We have 10 direct chains of inheritance, 10 classes in each.

3. Each class has unique 10 properties and 10 methods. Due to their uniqueness, the properties and methods are encapsulated smoothly in classes and a clear hierarchy representing the "elegant" structure of the base object is built on them.

4. But lo and behold, the unique properties run out. New "objects" appear - "born" by crossing of properties and methods of different classes and different chains. They do not have a direct chain of inheritance from A, but inherit their properties through many chains leading to the base object.

At the same time, inheriting their properties from "unique" objects, "mixed" objects inherit only a few properties and methods from them, leaving others unclaimed. They inherit many classes, but should only take some of their "inherited" material, leaving the rest untouched. BUT THIS IS NOT POSSIBLE. By accessing their classes, they inherit whatever is available.

In other words, their inheritance is unclear. By accessing their "parents", these objects acquire properties and methods they don't need. And there is no way to avoid these "superfluities".

It means that inheritance stops to work properly when there are a large number of descendants. The objects "degenerate" because of the set of "parents" and generalization of the excessive diversity of "inherited material". Objects cease to be conceptually coherent.

Errors, bugs, questions Features of the mql5 Questions from Beginners MQL5

Dmitry Fedoseev 2019.10.06 14:46 #405

Nah, that can't happen. Somewhere around level 6-8 of inheritance a mutation occurs and a machine uprising happens.

Artyom Trishkin 2019.10.06 14:52 #406

Реter Konow:

The reasons why unrestricted inheritance leads to "degeneracy" of objects are found.

EXPLANATION:

1. We declare a base (abstract) class A.

2. we construct a long chain of inheritance from it. For that purpose we create 10 heirs from A and 10 descendants from each of them. We have 10 direct chains of inheritance, 10 classes in each.

3. Each class has unique 10 properties and 10 methods. Due to their uniqueness, the properties and methods are encapsulated smoothly in classes and a clear hierarchy representing the "elegant" structure of the base object is built on them.

4. But lo and behold, the unique properties run out. New "objects" appear - "born" by crossing of properties and methods of different classes and different chains. They do not have a direct chain of inheritance from A, but inherit their properties through many chains leading to the base object.

At the same time, inheriting their properties from "unique" objects, "mixed" objects inherit only a few properties and methods from them, leaving others unclaimed. They inherit many classes, but should only take some of their "inherited" material, leaving the rest untouched. BUT THIS IS NOT POSSIBLE. By accessing their classes, they inherit whatever is available.

In other words, their inheritance is unclear. By accessing their "parents", these objects acquire properties and methods they don't need. And there is no way to avoid these "superfluities".

It means that inheritance stops to work properly when there are a large number of descendants. The objects "degenerate" because of the set of "parents" and generalization of the excessive diversity of "inherited material". Objects cease to be conceptually coherent.

So - the wrong concept is built.

Why inherit a car body and a portrait from a "frame" object?

Реter Konow 2019.10.06 14:59 #407

Artyom Trishkin:
So - the wrong concept is built.

Why inherit the car body and portrait from the "frame" object?

In the area of small tasks, a huge hierarchy of inheritance is not required. But, the hierarchy of the AI Knowledge Base, is almost unlimited. I have come to the conclusion that hierarchy of objects is convenient, practical and effective up to certain limits, after which "multiple" inheritance begins, leading to "degeneration" of object generations. New objects are removed from the base and their properties are "secondary", because they are collected from other objects. In the process of "collecting" properties, the new objects take on extra "inherited material", which is "wedged" into their operation.

I don't know how to solve this problem.

Any questions from newcomers Questions from a "dummy" Representation of an object

Igor Makanu 2019.10.06 15:04 #408

in case anyone reads it,https://tproger.ru/translations/oop-principles-cheatsheet/

though I doubt it, it's not the bourgeoisie's job to read what they write

Реter Konow 2019.10.06 15:12 #409

Igor Makanu:

in case anyone reads it,https://tproger.ru/translations/oop-principles-cheatsheet/

though I doubt it, it's not the bourgeoisie's job to read what they write.

The article talks about inheritance. Read it.

"Inheritance is the ability of one object to base itself on the properties of another."

But what if you have a 102nd generation object that can inherit ONLY from several objects instead of one? It will acquire extra properties and methods in proportion to the number of its "parents".

Questions from Beginners MQL5 Errors, bugs, questions PLO. Application issues

Artyom Trishkin 2019.10.06 15:16 #410

Реter Konow:

In the area of small tasks, a huge hierarchy of inheritance is not required. But, the hierarchy of the AI Knowledge Base is almost unlimited. I came to the conclusion that hierarchy of objects is convenient, practical and effective up to certain limits, after which "multiple" inheritance begins, leading to "degeneration" of object generations. New objects are removed from the base and their properties are "secondary", because they are collected from other objects. In the process of "harvesting" properties, the new objects take on extra "inherited material" that is "wedged" into their operation.

Not sure how to solve this problem.

Clear classification. If we see that multiple objects have the same properties, then it is logical to describe these properties in one parent object.

If a child object overrides a parent object property with the same name, that property must be virtual.

Override parent function Why does my object Canvas is cool!

A question for OOP experts. - page 41