www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D modeling

reply CheeseWiz <CheesyFritos gmail.com> writes:
Here is the code, It would be nice if D could do proper modeling 
of models. One can understand the issues as described in the 
comments in the main. The idea is simple, we have a model(a set 
of interrelated classes that are used for some purpose(which can 
be called a model or a framework)) and we want to derive an new 
model from it(using inheritance of models, it's similar to 
inheritance of classes but is based on the set and internal 
structure). Any model derived from another contains the base 
model and it's structure exactly how any class that derives from 
any base class will contain the base class structure.

But since D does not know about models it makes makes it 
difficult to do such things and makes for ugly code. If the 
language and compiler could understand models we could extend 
models perfectly. We would only have to add whatever new behavior 
we want or change the behavior we want.

There are 3 main problems:

1. Because we cannot use multiple inheritance, this makes the 
code extremely verbose. We must use interfaces and the syntax 
becomes unnecessarily verbose, but it does work ultimately. Model 
inheritance has no issues with the diamond problem. Only one 
branch will ever be used(either through the base model or, when 
overridden, through the derived model).

2. We must override and alias members that ultimately do not need 
to be expressed. The compiler can figure it out if it understood 
what was being done.

3. Oop contravariance breaks the model logic and mixes 
dependencies. It is a non-issue in modeling. In D it requires us 
to cast everywhere. This is the main issue. You can see the issue 
at work using IsItTasty functions. It's simple, Contravariance 
prevents us staying with the derived model, we have to use the 
base model(for return types, same applies to arguments with 
covariance). But when we are in a derived model we are in it, we 
are using everything in the derived model that belongs to it(and 
behind them is the base model, but we do not directly refer to 
the base model), at least that would be the plan.

//f.IsItTasty; 		// Error: no property

The issue is with this line, it should just work, but D complains 
because it is trying to use the base model, yet, for all 
practical purposes the base model does not exist. The base model, 
in modeling, is completely occluded by the derived model(although 
maybe we would need a `supermodel.` type of accessor like we have 
with `super.`, although `super.` may work just fine)



Here is the code:


import std.stdio, std.traits;

struct ModelA
{
     // D only allows single inheritance, must use interfaces
     interface iAnimal
     {
         string Type();
		string Name();
         void Attack(iAnimal who);
         iFood LikesWhichFood();
     }

     interface iCat : iAnimal
     {
		void Meow();
     }

     interface iDog : iAnimal
     {
		void Bark();
     }
     interface iFood
     {

     }

     class Animal : iAnimal
     {
         void Attack(iAnimal who) { writeln(Name, " is attacking 
", who.Name, "!"); }
         string Type() { return "Unknown Animal Type"; }
		override string Name() { return "Unknown Animal"; }
		iFood LikesWhichFood() { writeln("Food D Type: ", 
fullyQualifiedName!iFood); return null; }					
     }

     class Cat : Animal, iCat
     {
		string name = "Unknown Cat";
         override string Type() { return "Cat"; }		
		override string Name() { return name; }
         void Meow() { writeln("Meow!"); }
		this() { }
		this(string n) { name = n; }
     }

	class Dog : Animal, iDog
     {
		string name = "Unknown Dog";
         override string Type() { return "Dog"; }		
		override string Name() { return name; }
         void Bark() { writeln("Bark!"); }
		this() { }
		this(string n) { name = n; }
     }


     class Food : iFood
     {

     }
}


// Model B, It is "derived" from A, meaning Model B could, in 
theory, substitute for Model A as long as everything is designed 
correctly
// In this case we will create a ViewModel, a gui framework for 
ModelA. We actually cannot do this naturally in D since it does 
not support multiple inheritance.
struct ModelB
{	
     interface iAnimal : ModelA.iAnimal
     {

     }

     interface iCat : iAnimal, ModelA.iAnimal
     {

     }

     interface iDog : iAnimal, ModelA.iAnimal
     {

     }
     interface iFood : ModelA.iFood
     {
		void IsItTasty();
     }

     class Animal : ModelA.Animal, iAnimal
     {

     }

     class Cat : ModelA.Cat, iAnimal, iCat // We need to derive 
from Animal, not iAnimal, to provide proper ModelB implementation 
of Animal
     {
		alias Attack = Animal.Attack;	// Required by D
		
		// In D, ModelA.Cat's implement is not provided as default, we 
have to reimplement everything. Or is Animal providing any 
implementation
         override string Type() { return super.Type; }		
		override string Name() { return super.Name; }
         override void Meow() { super.Meow; }
		void Attack(iAnimal who) { super.Attack(who); }
		override void Attack(ModelA.iAnimal who) { super.Attack(who); }
		override iFood LikesWhichFood() { writeln("Food D Type: ", 
fullyQualifiedName!iFood); return new Cabbage; }					
		this() { }
		this(string n) { name = n; }
		
     }

	class Dog : ModelA.Dog, iAnimal, iDog
     {
		alias Attack = Animal.Attack;	
         override string Type() { return super.Type; }		
		override string Name() { return super.Name; }
         override void Bark() { super.Bark; }
		void Attack(iAnimal who) { super.Attack(who); }
		override void Attack(ModelA.iAnimal who) { super.Attack(who); }
		override iFood LikesWhichFood() { writeln("Food D Type: ", 
fullyQualifiedName!iFood); return new Donuts; }					
		this() { }
		this(string n) { name = n; }
     }


     class Food : iFood
     {
		void IsItTasty() { writeln("Unknown Food"); }
     }

	class Donuts : Food
	{
		override void IsItTasty() { writeln("YUK!"); }
	}

	class Cabbage : Food
	{
		override void IsItTasty() { writeln("YUM!"); }
	}
}
void main()
{

	{
		ModelA.iAnimal animal1 = new ModelA.Cat("Mittens");
		ModelA.iAnimal animal2 = new ModelA.Dog("Sparky");

		writeln(animal1.Name);
		writeln(animal2.Name);
		animal1.Attack(animal2);
		animal1.LikesWhichFood;
	}

	writeln("\n----------\n");

	{
		ModelB.iAnimal animal1 = new ModelB.Cat("Super Mittens");
		ModelB.iAnimal animal2 = new ModelB.Dog("Super Sparky");

		writeln(animal1.Name);
		writeln(animal2.Name);
		animal1.Attack(animal2);
		auto f = animal1.LikesWhichFood;
		//f.IsItTasty; 		// Error: no property `IsItTasty` for type 
`Models.ModelA.iFood`. It should return a ModelB.iFood, we are 
inside ModelB, never any risk
		(cast(ModelB.iFood)f).IsItTasty;		// We can, of course, force 
it, but that is the rub, we don't have to, that is why we want to 
have a concept of a model, it tells the compiler that there is 
something more going on and it can reduce all this overhead. We 
can't even override this because of the contravariance rule.

	}

	writeln("\n----------\n");

	// This is the magic, ModelB is now substituted in Model A. It's 
basically still oop but our entire derived model is(or should be) 
used.
	// We can substitute the new model in all places where the old 
was used. This is the easy way to do ModelViewModel, we simply 
extend the model and add the view, no complex bridging, adapting, 
maintance, dependencies, etc.
	{
		ModelA.iAnimal animal1 = new ModelB.Cat("Super Mittens");
		ModelA.iAnimal animal2 = new ModelB.Dog("Super Sparky");

		writeln(animal1.Name);
		writeln(animal2.Name);
		animal1.Attack(animal2);
		animal1.LikesWhichFood;
		auto f = animal2.LikesWhichFood;
		//f.IsItTasty;	// This Error is ok, we are inside ModelA, 
ModelA would never use IsItTasty and it would be wrong to do 
so(it's only wrong because it should be impossible for ModelA to 
know about ModelB, else we create a dependency between models and 
really end up with one combined model rather than two separate 
models). But note that we could cast
		(cast(ModelB.iFood)f).IsItTasty;		// We can, of course, force 
it though(only because we know for a fact we are actually dealing 
with a ModelB disugised as a ModelA, this is generally not the 
case), but this then shows a dependency. Note that it is exactly 
like the above model though... but there is a huge difference. In 
the first case it is afe, in this case it is not.. and the only 
difference is the model we are working in.
	}
}


It should be noted that modeling is a higher abstraction but is 
effectively almost identical to standard oop. It's akin to 
elements and arrays of elements. It's virtually not that much 
more, except we do have to then add a few concepts such as 
indexing, insertion, etc.

In D, the code is very verbose, I guess some meta programming 
could reduce the verbosity quite a bit. Maybe it could even 
reduce it all(using mixin templates to provide the default 
implementation). I'm not sure if problem 3 could be fixed though, 
if it could then there would be no issues with modeling in D 
except verbosity, which, if meta program solved it then maybe 
there would be no issues in D.

If D had introduced a new concept called a model, which is sort 
of a collection of classes, then would could do something very 
simple to create a new model:

model ModelA
{
    class A { }
    class B : A { A foo; }
}

model ModelB : ModelA
{
    class A { B bar; } // bar is new functionality on top of 
ModelA.A. foo returns ModelB.A, not ModelA.A(fixes problem 3)
    // class B : A; // automatically uses ModelB.A and so has a 
member named bar, we don't have to change it if we don't want.
}

The model keyword looks at the specified hierarchy of ModelA(in 
this case just A, B and the inheritance morphism B : A) and we 
can then derive from the entire model... very similar to how we 
derive from classes.


auto m = new ModelA();

and

ModelA ma = new MoodelB();



I think D actually basically can do all this. If we replace model 
with class and inner classes could be derived recursively a few 
little extensions and we could just essentially use nested 
classes:

class ModelA
{
     class A { }
     class B : A { }
}

class ModelB : ModelA
{
     // The compiler extends inheritance to all classes of ModelA 
recursive
     // i.e. it adds class A : ModelA.A { } class B : A, ModelA.B 
{ } // Multiple inheritance allowed
     // Possibly allow direct modification such as override void 
B.bar(). rather than having to do it inside the class of B. Would 
make things a little less verbose.
}

Of course, to avoid it doing this on preexisting code we would 
introduce the model keyword... which would probably break a lot 
of code, so a better keyword would need to be used.


What is the use?

Imagine you write a calculator. You only write the business end, 
no gui, no interface, etc.

Now you want to create a gui for it. you create a new model that 
extends th calculator. You don't mix and match, don't create 
ModelViewModel(well, you are but using models you don't have to 
duplicate any code that is not needed.

model CalculatorGUI : Calculator
{
    // Add only graphical necessities. The gui can be used 
anywhere the calculator can, always providing a gui for any usage
}


E.g., suppose a bank around uses the Calculator to do math, you 
could substitute the CalculatorGUI for it and then get a gui 
version. Since CalculatorGUI is a Calculator, it will work just 
fine, again, this is just oop but applied in a more sophisticated 
way.


I have never seen a programming language use models like this. 
They all leave it up to the programmer to deal with keeping 
everything on the straight and narrow. Modeling is used 
everywhere and constantly. In fact, class inheritance is just 
very simple modeling.

I believe Haskell can do such things naturally but I don't know. 
D can almost D things naturally but it could be made very natural 
with a few modifications.
Jul 01 2019
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 2 July 2019 at 01:21:56 UTC, CheeseWiz wrote:

 3. Oop contravariance breaks the model logic and mixes 
 dependencies. It is a non-issue in modeling. In D it requires 
 us to cast everywhere. This is the main issue. You can see the 
 issue at work using IsItTasty functions. It's simple, 
 Contravariance prevents us staying with the derived model, we 
 have to use the base model(for return types, same applies to 
 arguments with covariance). But when we are in a derived model 
 we are in it, we are using everything in the derived model that 
 belongs to it(and behind them is the base model, but we do not 
 directly refer to the base model), at least that would be the 
 plan.


Quite the opposite! Covariance actually saves you.

struct ModelB
{	
     interface iAnimal : ModelA.iAnimal
     {
         override iFood LikesWhichFood();
     }
Jul 02 2019
parent CheeseWiz <CheesyFritos gmail.com> writes:
On Tuesday, 2 July 2019 at 13:52:17 UTC, FeepingCreature wrote:

 On Tuesday, 2 July 2019 at 01:21:56 UTC, CheeseWiz wrote:

 3. Oop contravariance breaks the model logic and mixes 
 dependencies. It is a non-issue in modeling. In D it requires 
 us to cast everywhere. This is the main issue. You can see the 
 issue at work using IsItTasty functions. It's simple, 
 Contravariance prevents us staying with the derived model, we 
 have to use the base model(for return types, same applies to 
 arguments with covariance). But when we are in a derived model 
 we are in it, we are using everything in the derived model 
 that belongs to it(and behind them is the base model, but we 
 do not directly refer to the base model), at least that would 
 be the plan.


 Quite the opposite! Covariance actually saves you.

 struct ModelB
 {	
     interface iAnimal : ModelA.iAnimal
     {
         override iFood LikesWhichFood();
     }


Ok, adding the follow does seem to work:

     interface iAnimal : ModelA.iAnimal
     {
		override iFood LikesWhichFood();
     }

then one has to do

     class Animal : ModelA.Animal, iAnimal
     {
// Note the cast, but it is ok if necessary since at least it 
would isolate it.
		 override iFood LikesWhichFood() { return 
cast(iFood)super.LikesWhichFood; }
     }


The goal here is to avoid having to add all the extra plumbing. 
Imagine a real project with 100's of classes and having to 
override and cast everything just to get it to function. It seems 
excessive. Maybe meta programming can fix it?
Jul 02 2019
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 2 July 2019 at 01:21:56 UTC, CheeseWiz wrote:

 There are 3 main problems:

 1. Because we cannot use multiple inheritance, this makes the 
 code extremely verbose. We must use interfaces and the syntax 
 becomes unnecessarily verbose, but it does work ultimately. 
 Model inheritance has no issues with the diamond problem. Only 
 one branch will ever be used(either through the base model or, 
 when overridden, through the derived model).


I don't see where you used multiple inheritance. Turn everything 
into concrete/abstract classes and you should be fine.


 2. We must override and alias members that ultimately do not 
 need to be expressed. The compiler can figure it out if it 
 understood what was being done.


Are you referring to the "NotImplementedException" that 
proliferate most poorly designed abstractions?


 3. Oop contravariance breaks the model logic and mixes 
 dependencies. It is a non-issue in modeling. In D it requires 
 us to cast everywhere. This is the main issue. You can see the 
 issue at work using IsItTasty functions. It's simple, 
 Contravariance prevents us staying with the derived model, we 
 have to use the base model(for return types, same applies to 
 arguments with covariance). But when we are in a derived model 
 we are in it, we are using everything in the derived model that 
 belongs to it(and behind them is the base model, but we do not 
 directly refer to the base model), at least that would be the 
 plan.



With D support for both covariance and contravariance, you should 
be covered. You desired model behavior should just fall into 
place.

Could you throw up a working example as a gist? Might take a hack 
at it.
Jul 02 2019
next sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 2 July 2019 at 14:36:04 UTC, Jesse Phillips wrote:

 With D support for both covariance and contravariance, you 
 should be covered. You desired model behavior should just fall 
 into place.

 Could you throw up a working example as a gist? Might take a 
 hack at it.


Here is a related article

https://he-the-great.livejournal.com/54436.html
Jul 02 2019
prev sibling parent reply CheeseWiz <CheesyFritos gmail.com> writes:
On Tuesday, 2 July 2019 at 14:36:04 UTC, Jesse Phillips wrote:

 On Tuesday, 2 July 2019 at 01:21:56 UTC, CheeseWiz wrote:

 There are 3 main problems:

 1. Because we cannot use multiple inheritance, this makes the 
 code extremely verbose. We must use interfaces and the syntax 
 becomes unnecessarily verbose, but it does work ultimately. 
 Model inheritance has no issues with the diamond problem. Only 
 one branch will ever be used(either through the base model or, 
 when overridden, through the derived model).


 I don't see where you used multiple inheritance. Turn 
 everything into concrete/abstract classes and you should be 
 fine.


I didn't, D doesn't support MI.

One has to inherit the base model and the derived model 
relationships, that is MI.

     interface iDog : iAnimal, ModelA.iAnimal
     {

     }

     class Animal : ModelA.Animal, iAnimal
     {
		 override iFood LikesWhichFood() { return 
cast(iFood)super.LikesWhichFood;
     }

ideally we could just do

class Dog : Animal, ModelA.Animal

and that is MI. It would simplify both models


 2. We must override and alias members that ultimately do not 
 need to be expressed. The compiler can figure it out if it 
 understood what was being done.


 Are you referring to the "NotImplementedException" that 
 proliferate most poorly designed abstractions?


		alias Attack = Animal.Attack;	// Required by D
		void Attack(iAnimal who) { super.Attack(who); }


D gave me an error and said I must use the alias(first line), 
without I get an error about a missing override.

Error: class `Models.ModelB.Cat` use of 
`Models.ModelA.Animal.Attack(iAnimal who)` is hidden by `Cat`; 
use `alias Attack = Animal.Attack;` to introduce base class 
overload set



 3. Oop contravariance breaks the model logic and mixes 
 dependencies. It is a non-issue in modeling. In D it requires 
 us to cast everywhere. This is the main issue. You can see the 
 issue at work using IsItTasty functions. It's simple, 
 Contravariance prevents us staying with the derived model, we 
 have to use the base model(for return types, same applies to 
 arguments with covariance). But when we are in a derived model 
 we are in it, we are using everything in the derived model 
 that belongs to it(and behind them is the base model, but we 
 do not directly refer to the base model), at least that would 
 be the plan.



 With D support for both covariance and contravariance, you 
 should be covered. You desired model behavior should just fall 
 into place.


Yes, it seems that with the proper overrides it works. It is 
quite verbose, it would be amazing if all this stuff could be 
automated. It all is boilerplate code and requires for every 
model and every component of the model.


 Could you throw up a working example as a gist? Might take a 
 hack at it.


The OP contains a working example. Adding the overrides does 
solve problem 3 and so it is possible to have model inheritance 
in D! That is good news(I suppose it should be obvious since it's 
just normal inheritance)!

Now the only goal is too make it simple to do. I imagine meta 
programming and mixin templates could solve this... Not sure 
though if one would need partial classes to make it work. (it 
would be ugly to also have to have a lot of mixin templates 
littered throughout)

The goal would be to create something as simple as

model A : B
{

    // Add whatever extensions one wants, all plumbing is taken 
care of.
}
Jul 02 2019
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 2 July 2019 at 18:27:32 UTC, CheeseWiz wrote:

 
 The OP contains a working example.


I don't want to pull all the pieces together.

Meta programing wouldn't likely help, there are too many rules 
about how your interface and inheritance needs to combine with 
the parent model that any meta programming would hide the intent.

I still don't believe interfaces are needed, nor your example of 
multiple inheritance.
Jul 02 2019
parent reply Bert <Bert gmail.com> writes:
On Wednesday, 3 July 2019 at 04:58:00 UTC, Jesse Phillips wrote:

 On Tuesday, 2 July 2019 at 18:27:32 UTC, CheeseWiz wrote:

 
 The OP contains a working example.


 I don't want to pull all the pieces together.


There are no pieces to put together. It is just a direct copy and 
paste. I pasted directly the source code in to the editor... you 
have to do is find the first place(which starts with import) and 
scroll do the last line(which is the last } of main). You are 
making it far more difficult than it is.

The only difference is to get it truly working you have to add 2 
lines of code to add the contravariance.


 Meta programing wouldn't likely help, there are too many rules 
 about how your interface and inheritance needs to combine with 
 the parent model that any meta programming would hide the 
 intent.


Maybe, maybe not. There are not too many rules though. It's 
simply providing the right overrides and such


 I still don't believe interfaces are needed, nor your example 
 of multiple inheritance.



Interfaces are required because D does not support MI of classes. 
You will not be able to substitute one model for the other 
without inheritance. It's required.

Any any object in the derived model HAS TO derive from the base 
model and the parent in the derived model. That is the whole 
point. That is multiple inheritance. It can't be done any other 
way, but D only lets one inherent multiply using interfaces.

You won't be able to get around that if this is going to be done 
using oop.

Now, maybe one can hack things and not use inheritance between 
models and then force some type of substitution scheme that 
works... but that is for someone else to figure out.

Everything actually works out in D, it's just verbose and 
cumbersome and for complex models it is error prone. Hence the 
only thing to do is find a better way to deal with it.
Jul 03 2019
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 3 July 2019 at 13:34:38 UTC, Bert wrote:

 Interfaces are required because D does not support MI of 
 classes. You will not be able to substitute one model for the 
 other without inheritance. It's required.


All I did was remove the interfaces:

https://run.dlang.io/gist/3b14d69aa323d83e2736a0e2e0dece3f
Jul 03 2019
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 3 July 2019 at 14:01:17 UTC, Jesse Phillips wrote:

 On Wednesday, 3 July 2019 at 13:34:38 UTC, Bert wrote:

 Interfaces are required because D does not support MI of 
 classes. You will not be able to substitute one model for the 
 other without inheritance. It's required.


 All I did was remove the interfaces:

 https://run.dlang.io/gist/3b14d69aa323d83e2736a0e2e0dece3f


Now I remove your unneeded overrides:

https://run.dlang.io/gist/28168b9e1265ab05da310c527079f6ac
Jul 03 2019
parent reply Bert <Bert gmail.com> writes:
On Wednesday, 3 July 2019 at 14:06:16 UTC, Jesse Phillips wrote:

 On Wednesday, 3 July 2019 at 14:01:17 UTC, Jesse Phillips wrote:

 On Wednesday, 3 July 2019 at 13:34:38 UTC, Bert wrote:

 Interfaces are required because D does not support MI of 
 classes. You will not be able to substitute one model for the 
 other without inheritance. It's required.


 All I did was remove the interfaces:

 https://run.dlang.io/gist/3b14d69aa323d83e2736a0e2e0dece3f


 Now I remove your unneeded overrides:

 https://run.dlang.io/gist/28168b9e1265ab05da310c527079f6ac


404: Not Found


The problem with removing the interfaces is that when you try to 
extend the model by adding new classes you will then have 
multiple inheritance of classes and be screwed. You may be able 
to remove them in the simple example I gave but in general it 
will be impossible to make it work. One of the main reasons for 
interfaces is precisely to allow MI in a single inheritance 
language. The interfaces are the only way to avoid such future 
problems. In essence you are creating an anti-pattern.
Jul 03 2019
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 3 July 2019 at 19:31:49 UTC, Bert wrote:

 The problem with removing the interfaces is that when you try 
 to extend the model by adding new classes you will then have 
 multiple inheritance of classes and be screwed. You may be able 
 to remove them in the simple example I gave but in general it 
 will be impossible to make it work. One of the main reasons for 
 interfaces is precisely to allow MI in a single inheritance 
 language. The interfaces are the only way to avoid such future 
 problems. In essence you are creating an anti-pattern.


Huh, not sure what is up with that:
https://gist.github.com/run-dlang/bfc043093066da04f0d2bec5a07de459

I understand the purpose for interfaces, what I'm trying to 
understand is your requirements for this 'model' idea.

Your code made overzealous use of inheritance which I expect 
created some of your frustration. When I stated I did not see 
multiple inheritance in your code, you pursued it was and the 
interfaces were required. I have shown this is not true, so I ask 
you to consider what your needs actually are. I'm not creating 
any patterns I'm informing you of how the language works and 
meets your demonstrated need.
Jul 03 2019
parent reply CheeseWiz <CheesyFritos gmail.com> writes:
On Thursday, 4 July 2019 at 04:33:12 UTC, Jesse Phillips wrote:

 On Wednesday, 3 July 2019 at 19:31:49 UTC, Bert wrote:

 The problem with removing the interfaces is that when you try 
 to extend the model by adding new classes you will then have 
 multiple inheritance of classes and be screwed. You may be 
 able to remove them in the simple example I gave but in 
 general it will be impossible to make it work. One of the main 
 reasons for interfaces is precisely to allow MI in a single 
 inheritance language. The interfaces are the only way to avoid 
 such future problems. In essence you are creating an 
 anti-pattern.


 Huh, not sure what is up with that:
 https://gist.github.com/run-dlang/bfc043093066da04f0d2bec5a07de459


That works.


 I understand the purpose for interfaces, what I'm trying to 
 understand is your requirements for this 'model' idea.

 Your code made overzealous use of inheritance which I expect 
 created some of your frustration. When I stated I did not see 
 multiple inheritance in your code, you pursued it was and the 
 interfaces were required. I have shown this is not true, so I 
 ask you to consider what your needs actually are. I'm not 
 creating any patterns I'm informing you of how the language 
 works and meets your demonstrated need.



You seem to think the example is a real world model and that all 
other models would work the same.

Let me ask you, do you think interfaces are never needed in oop? 
If they are, why? Do you realize that the modeling is just oop?

Now, I will explain why you are wrong, misunderstanding the 
problem, and how you changed the entire meaning of the program to 
cram it in to your misunderstanding.

1.

struct ModelB
{	
     class Animal : ModelA.Animal
     {

     }

     class Cat : ModelA.Cat
     {
		override Food LikesWhichFood() { writeln("Food D Type: ", 
fullyQualifiedName!Food); return new Cabbage; }					
		this() { }
		this(string n) { name = n; }
		
     }

	class Dog : ModelA.Dog
     {
		override Food LikesWhichFood() { writeln("Food D Type: ", 
fullyQualifiedName!Food); return new Donuts; }					
		this() { }
		this(string n) { name = n; }
     }

You've removed all the interfaces so you would not have MI. You 
believe that was as smart thing. But you have completely 
disconnected  ModelB from itself.

Now ModelB.Dog does not inheret from ModelB.Animal.

What happens if you extend ModelB.Animal? How is ModelB.Dog going 
to see that? It can't, it's not connected. You have not created a 
new model.  You have simply extended every class in ModelA. You 
have done nothing model wise.

2.

My original code:

	ModelA.iAnimal animal1 = new ModelB.Cat("Super Mittens");
	ModelA.iAnimal animal2 = new ModelB.Dog("Super Sparky");

you changed the returns to auto.

In mine, I'm using oop and animal1 is of class type ModelA but of 
instance type ModelB. By using auto you still have ModelB's(even 
though they are not longer really a Model). This may seem like no 
problem in this simple case but realize in a real problem ModelA 
be creating new objects using a factory. You won't have access to 
changing everything so easily. The whole point I did not use auto 
was to express this. I wanted to show how how animal1 as a ModelA 
could hold a ModelB and act properly.(i.e., inheritance).

If one has a class hierarchy, this is what you have done:

    A
  /   \
B     C

and you you have

    A  ---->  a
   /    \
B -> b   C -> c

Every class is just has a new derived base class for you to 
insert. This is just basic oop. This is not on a higher level. c 
is not related to a as C is to A.

What I have is this

   A  ---------->  a
/   \           /   \
B   C          b    c
-------------->
     --------------->


compared to yours:

   A  ---------->  a
/   \
B   C          b    c
-------------->
     --------------->


(notice that a, b, and c are not related directly in the fashion 
of the structure).

3. You have to realize you are wrong, that is the first step to 
understanding. I've tried to point it out but you are probably 
still thinking "But I'm right and he's wrong".

What you are doing is not modeling. That is the first 
realization. You have done nothing outside basic oop that 
everyone does. It's just class inheritence. You have some class X 
and you want a new one so you derive from it. You have a class Y 
and you want some new Y and you derive from it... but your does 
not explicitly connect X and Y in any way shape or form if they 
are connected.


What I'm doing is preserving the structure. When we derive a 
class, we preserve the base classes structure. This is called an 
embedding. The base class is embedded in the derived class and 
this allows the derived class to be the base class. That is, we 
can always substitute the derived in places where the base class 
is because the derived is the base class in *structure*.

But the same logic holds for relations between classes(which are 
models, frameworks, designs, etc). I'm trying to preserve the 
structure of the classes AND the structure between the classes. 
Do you see this?

https://en.wikipedia.org/wiki/Natural_transformation


The only thing I can say is that with what you are doing, you 
cannot subsistent one model for the other because you actually 
only have one model.

In my original code I have two models. The second model is fully 
derived from the first. It contains the entire structure of the 
first. It is true inheritance of models and it is oop.

It means that if a program was written with ModelA in mind, I can 
derive a new model called ModelB and drop it in place of it. I 
can extend my model and inside the model everything is in terms 
of ModelB(not mixing modelA stuff).


Look at this, the lines are inheritance:

   A  ---------->  a
/   \           /   \
B   C          b    c
-------------->
     --------------->


compared to yours:

   A  ---------->  a
/   \
B   C          b    c
-------------->
     --------------->


In yours, if I create a class b, it contains B and then A, but no 
a.
In mine, b contains B, A, AND a.

Yours you cannot get a. How will you get it's members? As far as 
your model is concerned, a is not connected to b. In mine a is 
directly connected to be(it inherits it). And the relationships B 
: A is preserved b : a.

You can see this in the code by trying to add a new method to 
ModelB.Animal... it does not show up in ModelB.Dog... 
ModelB.Animal is not related to ModelB.Dog. Hence you are not 
preserving the structure in ModelB that exists in ModelA.

This means if someone comes along and decides to model ModelB, 
they will be screwed because it no longer models A. You have 
broken "model inheritance".

Class inheritence doesn't break like this because it preserves 
the internal structure. Model inheritance doesn't break this 
because it preserves the internal structure... but D doesn't know 
about model inheritance so one can actually break it.


It's only going to be clear when you realize there is more to it 
than what you are thinking about. It may or may not be subtle.

It's purpose is a little more practical though. Your method will 
work but it requires hacks, factors, and all kinds of things to 
keep the modeling consistent and useful. You can cast objects and 
use factors to generate the appropriate types...

But in what I'm doing, one does not have too do all that.

ModelB knows about itself. ModelB.Dog knows about 
ModelB.Animal... not only ModelA.Animal.

Do you see the difference? I'm adding an arrow, it's not just an 
arrow, it's a structural relationship that has meaning(it is 
inheritance). I'm using *multiple inheritance* and you are using 
single inheritance. You can claim that I don't need multiple 
inheritance but really, you should be skeptical since obviously 
multiple inheritance will generally provide more(but never less).

You are throwing out a connection to fit the problem in to your 
own misconception.

If you want to see your problem, it's quite simple:


struct ModelB
{	
     class Animal : ModelA.Animal
     {
        void Fart();
     }

}

Your Dog is oblivious to Fart.. It can't see it, there is no 
arrow. Add it to your code...  You cannot do dog.Fart. You can 
cast, you can play games, but it is not naturally done like it 
should(like standard inheritance should work).

But if you do what I do, or had MI:

     class Dog : Animal, ModelA.Animal

Now Dog can see Fart. Now that is MI, can't be done in D, so we 
have to use interfaces.

Do you get it? The main thing to recognize is that you are 
pruning the structure... and so you have to absolutely make sure 
you are not cutting the tree down in the process, and 
unfortunately that is what you did in this case. You just need to 
recognize there is more too it to start seeing what it is. As 
long as you keep believing it can be simplified you will continue 
going down that dead end.
Jul 05 2019
next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Friday, 5 July 2019 at 11:22:10 UTC, CheeseWiz wrote:

 I'm trying to preserve the structure of the classes AND the 
 structure between the classes.


So what you want is for this code to work, right?

import std.stdio;

struct ModelA {
     class Animal {}
     class Dog : Animal {
         void bark() {
             writeln("ModelA barks!");
         }
         void bite() {
             writeln("ModelA bites!");
         }
     }
}

struct ModelB {
     class Animal {
         mixin inherit!ModelA;
     }
     class Dog : Animal {
         mixin inherit!ModelA;
         void bark() {
             writeln("ModelB Barks!");
         }
     }
}

unittest {
     ModelB.Dog a = new ModelB.Dog();
     ModelA.Dog b = a;
     ModelA.Animal c = b;
     ModelA.Animal d = a;

     assert(a !is null);
     assert(b !is null);
     assert(c !is null);
     assert(d !is null);

     // bark() is overridden in ModelB.Dog, so that's the version 
what's being called:
     a.bark(); // ModelB Barks!
     b.bark(); // ModelB Barks!

     // bite(), however, is not overridden, so ModelA's version is 
used:
     b.bite(); // ModelA bites!
     a.bite(); // ModelA bites!
}


As is hinted at by the `mixin inherit!ModelA;` lines above, 
mixins can sorta make this work. Here's a PoC that makes the 
above code work:

mixin template inherit(ParentModel) {
     static assert(is(typeof(this) == class), "inherit only works 
for classes");
     static assert(__traits(hasMember, ParentModel, 
typeof(this).stringof), "inherit works only for models matching 
the same class structure");

     alias ThisClass = typeof(this);
     alias ParentClass = __traits(getMember, ParentModel, 
typeof(this).stringof);

     import std.typecons : AutoImplement;
     static class Base : ParentClass {
         ThisClass zis;
     }
     template What(alias func) {
         enum funcName = __traits(identifier, func);
         static if (__traits(hasMember, ThisClass, funcName)) {
             enum What =  __traits(isVirtualFunction, func) &&
                          __traits(isVirtualFunction, 
__traits(getMember, ThisClass, __traits(identifier, func)));
         } else {
             enum What = false;
         }
     }
     template How(T, alias func) {
         import std.format : format;
         enum How = q{return zis.%1$s(args);}
             .format(__traits(identifier, func));
     }
     AutoImplement!(Base, How, What) _proxyParent;
     alias _proxyParent this;

     this() {
         _proxyParent = new typeof(_proxyParent)();
         _proxyParent.zis = this;
     }
}

Of course, it's ugly as all hell, and there are some issues (like 
casting from ModelA.Dog back to ModelB.Dog) that simply can't be 
handled by library code, but for limited applications, this works.

--
   Simen
Jul 05 2019
next sibling parent CheeseWiz <CheesyFritos3 gmail.com> writes:
On Friday, 5 July 2019 at 12:24:06 UTC, Simen Kjærås wrote:

 On Friday, 5 July 2019 at 11:22:10 UTC, CheeseWiz wrote:

 I'm trying to preserve the structure of the classes AND the 
 structure between the classes.


 So what you want is for this code to work, right?

 import std.stdio;

 struct ModelA {
     class Animal {}
     class Dog : Animal {
         void bark() {
             writeln("ModelA barks!");
         }
         void bite() {
             writeln("ModelA bites!");
         }
     }
 }

 struct ModelB {
     class Animal {
         mixin inherit!ModelA;
     }
     class Dog : Animal {
         mixin inherit!ModelA;
         void bark() {
             writeln("ModelB Barks!");
         }
     }
 }

 unittest {
     ModelB.Dog a = new ModelB.Dog();
     ModelA.Dog b = a;
     ModelA.Animal c = b;
     ModelA.Animal d = a;

     assert(a !is null);
     assert(b !is null);
     assert(c !is null);
     assert(d !is null);

     // bark() is overridden in ModelB.Dog, so that's the 
 version what's being called:
     a.bark(); // ModelB Barks!
     b.bark(); // ModelB Barks!

     // bite(), however, is not overridden, so ModelA's version 
 is used:
     b.bite(); // ModelA bites!
     a.bite(); // ModelA bites!
 }


 As is hinted at by the `mixin inherit!ModelA;` lines above, 
 mixins can sorta make this work. Here's a PoC that makes the 
 above code work:

 mixin template inherit(ParentModel) {
     static assert(is(typeof(this) == class), "inherit only 
 works for classes");
     static assert(__traits(hasMember, ParentModel, 
 typeof(this).stringof), "inherit works only for models matching 
 the same class structure");

     alias ThisClass = typeof(this);
     alias ParentClass = __traits(getMember, ParentModel, 
 typeof(this).stringof);

     import std.typecons : AutoImplement;
     static class Base : ParentClass {
         ThisClass zis;
     }
     template What(alias func) {
         enum funcName = __traits(identifier, func);
         static if (__traits(hasMember, ThisClass, funcName)) {
             enum What =  __traits(isVirtualFunction, func) &&
                          __traits(isVirtualFunction, 
 __traits(getMember, ThisClass, __traits(identifier, func)));
         } else {
             enum What = false;
         }
     }
     template How(T, alias func) {
         import std.format : format;
         enum How = q{return zis.%1$s(args);}
             .format(__traits(identifier, func));
     }
     AutoImplement!(Base, How, What) _proxyParent;
     alias _proxyParent this;

     this() {
         _proxyParent = new typeof(_proxyParent)();
         _proxyParent.zis = this;
     }
 }

 Of course, it's ugly as all hell, and there are some issues 
 (like casting from ModelA.Dog back to ModelB.Dog) that simply 
 can't be handled by library code, but for limited applications, 
 this works.

 --
   Simen


No, sorry, The classes have to actually inherit. The model itself 
has to be substitutable in all ways in to the original model, 
else it is not derived.

There is no way for ModelB to be a drop in replacement and so to 
preserve the structure. You should see my other long post about 
this.

Without inheritance(and MI but having to use interfaces) it will 
be impossible to make all this work and then the whole point 
would be useless.

There are two things:

1. Any new model must preserve all the structure of the old, else 
it won't work. inheritance does this, that is the whole point. If 
the structure is not preserved want can't substitute the derived 
class or model for the base class or model. If you leave out 
"connections" then something will go wrong at some point. It's 
like creating, say, a circuit from a schematic and leaving out 
wires saying "Oh, this wire doesn't matter" when, in fact, it 
does.  This is wiring up the modelB to modelA structurally. This 
could be called inter-model inheritance.

2. The model must be properly extendable within itself. By 
removing the intra-model inheritance(like Jesse did). This allows 
one to work within the model as if they were working completely 
from the original model, but as if it were entirely new(meaning 
one can add new structure but not remove structure).

I think the confusing part for you guys is that both types are 
still basic inheritance. Ya'll are not recognizing that there is 
a subtle distinction between the conceptually. Model 
inheritance(inter-model) is analogous to class 
inheritance(inter-model).

It's sort of like having an element operation and then extending 
it too work on arrays. The same underlying operation is used but 
there is a subtle difference in that one has to iterate over the 
arrays and apply the operation. The element operation is class 
inheritance and the array "operation" is model inheritance. It's 
a little more complex than and hence the "subtle details".

You guys are removing the very code that allows one to create a 
truly *derived* *model*. It's not derived unless it's 
derived(meaning all the structure is preserved). This applies to 
classes as well... but since D and oop already handle all the 
details for classes it is not an issue and no one thinks about 
it. Since D does not handle models or have such concepts and they 
are not commonly thought of in such "forest views" one has to be 
more careful.


It's simple as this:

Definition: Model - A model is a collection of classes and their 
inheritance relationships. Hence it is a category or a a directed 
graph or an inheritance hierarchy.

Ok?

Definition: Model Inheritance - A preservation of a model's 
structure[called the base model] inside a new model, called the 
derived model.


Note that these parallel classes. Classes contain members and one 
can think of it as a very simple graph. Models contain classes 
and one can think of it as a very simple graph but at a higher 
level. Each node in the graph is a class and hence it has a 
subgraph.

But just like you can't partially inherent a class and you can't 
partially inherit a model. In D, you can do it only because D 
doesn't understand models... but if you do it wrong you will run 
in to major problems. It would be akin too trying to implement 
classes in a language by hand and forgetting to include some 
members, but not having the compiler able to check for you.

This is not complex or a "hard problem". It's very simple. Try 
not to over complicate it. The definitions above, if understood 
correctly, should be enough.

Thanks for wasting your time on it though ;) Sorry you 
misunderstanding it ;/ Maybe your code can be adapted though, at 
the very least you'll have to add the inheritance relationships, 
maybe that will fix it and make it all work right?

I will say that in the code I posted, you cannot remove the 
interfaces nor the inheritance relationships. Doing that 
completely destroys everything. If you think it can you are not 
understanding the problem correctly and should focus on realizing 
why it is necessary.

Try to think of it in terms of a real world application. Say a 
program that uses a model, such as a video game that uses oop to 
manage the video game objects... and then you create an entirely 
new model that adds something new to the model. Rather than 
extend each class individually you want extend the entire model 
to a new one in a consistent and logical way.

You do this by copying and pasting all the "structure". But your 
model won't be able to just drop in and replace the original 
because it doesn't inherit in any way... so you start adding 
inheritance, but now it's MI because your model already has 
inheritance in it(since the original model had it since it was 
oop based). Now you have to use interfaces because of SI in D. If 
you do everything right, and the original model was designed with 
proper object construction that allows extension(e.g., overriding 
"new" or having a factory) then  your new model will can simply 
be dropped in to the original model without issue. EXACTLY the 
same as how it would work for a single class and object. [that is 
the goal at least and to make that happen requires some work, but 
one is properly extending models the other is proper object 
creation]

If done right though, and ideally with help from the compiler, it 
becomes very simple too do so. You can think fo class inheritance 
as a very slimmed down and naive version of model inheritance. 
class inheritance is model inheritance because a simple base 
class - derived class is a model.

You can think of traditional inheritance as being a dumbed down 
version of model inheritance or model inheritance is a 
generalization of class inheritance.
Jul 05 2019
prev sibling parent reply CheeseWiz <CheesyFritos gmail.com> writes:
On Friday, 5 July 2019 at 12:24:06 UTC, Simen Kjærås wrote:

 On Friday, 5 July 2019 at 11:22:10 UTC, CheeseWiz wrote:

 I'm trying to preserve the structure of the classes AND the 
 structure between the classes.


 So what you want is for this code to work, right?

 import std.stdio;

 struct ModelA {
     class Animal {}
     class Dog : Animal {
         void bark() {
             writeln("ModelA barks!");
         }
         void bite() {
             writeln("ModelA bites!");
         }
     }
 }

 struct ModelB {
     class Animal {
         mixin inherit!ModelA;
     }
     class Dog : Animal {
         mixin inherit!ModelA;
         void bark() {
             writeln("ModelB Barks!");
         }
     }
 }

 unittest {
     ModelB.Dog a = new ModelB.Dog();
     ModelA.Dog b = a;
     ModelA.Animal c = b;
     ModelA.Animal d = a;

     assert(a !is null);
     assert(b !is null);
     assert(c !is null);
     assert(d !is null);

     // bark() is overridden in ModelB.Dog, so that's the 
 version what's being called:
     a.bark(); // ModelB Barks!
     b.bark(); // ModelB Barks!

     // bite(), however, is not overridden, so ModelA's version 
 is used:
     b.bite(); // ModelA bites!
     a.bite(); // ModelA bites!
 }


 As is hinted at by the `mixin inherit!ModelA;` lines above, 
 mixins can sorta make this work. Here's a PoC that makes the 
 above code work:

 mixin template inherit(ParentModel) {
     static assert(is(typeof(this) == class), "inherit only 
 works for classes");
     static assert(__traits(hasMember, ParentModel, 
 typeof(this).stringof), "inherit works only for models matching 
 the same class structure");

     alias ThisClass = typeof(this);
     alias ParentClass = __traits(getMember, ParentModel, 
 typeof(this).stringof);

     import std.typecons : AutoImplement;
     static class Base : ParentClass {
         ThisClass zis;
     }
     template What(alias func) {
         enum funcName = __traits(identifier, func);
         static if (__traits(hasMember, ThisClass, funcName)) {
             enum What =  __traits(isVirtualFunction, func) &&
                          __traits(isVirtualFunction, 
 __traits(getMember, ThisClass, __traits(identifier, func)));
         } else {
             enum What = false;
         }
     }
     template How(T, alias func) {
         import std.format : format;
         enum How = q{return zis.%1$s(args);}
             .format(__traits(identifier, func));
     }
     AutoImplement!(Base, How, What) _proxyParent;
     alias _proxyParent this;

     this() {
         _proxyParent = new typeof(_proxyParent)();
         _proxyParent.zis = this;
     }
 }

 Of course, it's ugly as all hell, and there are some issues 
 (like casting from ModelA.Dog back to ModelB.Dog) that simply 
 can't be handled by library code, but for limited applications, 
 this works.

 --
   Simen


No, sorry, The classes have to actually inherit. The model itself 
has to be substitutable in all ways in to the original model, 
else it is not derived.

There is no way for ModelB to be a drop in replacement and so to 
preserve the structure. You should see my other long post about 
this.

Without inheritance(and MI but having to use interfaces) it will 
be impossible to make all this work and then the whole point 
would be useless.

There are two things:

1. Any new model must preserve all the structure of the old, else 
it won't work. inheritance does this, that is the whole point. If 
the structure is not preserved want can't substitute the derived 
class or model for the base class or model. If you leave out 
"connections" then something will go wrong at some point. It's 
like creating, say, a circuit from a schematic and leaving out 
wires saying "Oh, this wire doesn't matter" when, in fact, it 
does.  This is wiring up the modelB to modelA structurally. This 
could be called inter-model inheritance.

2. The model must be properly extendable within itself. By 
removing the intra-model inheritance(like Jesse did). This allows 
one to work within the model as if they were working completely 
from the original model, but as if it were entirely new(meaning 
one can add new structure but not remove structure).

I think the confusing part for you guys is that both types are 
still basic inheritance. Ya'll are not recognizing that there is 
a subtle distinction between the conceptually. Model 
inheritance(inter-model) is analogous to class 
inheritance(inter-model).

It's sort of like having an element operation and then extending 
it too work on arrays. The same underlying operation is used but 
there is a subtle difference in that one has to iterate over the 
arrays and apply the operation. The element operation is class 
inheritance and the array "operation" is model inheritance. It's 
a little more complex than and hence the "subtle details".

You guys are removing the very code that allows one to create a 
truly *derived* *model*. It's not derived unless it's 
derived(meaning all the structure is preserved). This applies to 
classes as well... but since D and oop already handle all the 
details for classes it is not an issue and no one thinks about 
it. Since D does not handle models or have such concepts and they 
are not commonly thought of in such "forest views" one has to be 
more careful.


It's simple as this:

Definition: Model - A model is a collection of classes and their 
inheritance relationships. Hence it is a category or a a directed 
graph or an inheritance hierarchy.

Ok?

Definition: Model Inheritance - A preservation of a model's 
structure[called the base model] inside a new model, called the 
derived model.


Note that these parallel classes. Classes contain members and one 
can think of it as a very simple graph. Models contain classes 
and one can think of it as a very simple graph but at a higher 
level. Each node in the graph is a class and hence it has a 
subgraph.

But just like you can't partially inherent a class and you can't 
partially inherit a model. In D, you can do it only because D 
doesn't understand models... but if you do it wrong you will run 
in to major problems. It would be akin too trying to implement 
classes in a language by hand and forgetting to include some 
members, but not having the compiler able to check for you.

This is not complex or a "hard problem". It's very simple. Try 
not to over complicate it. The definitions above, if understood 
correctly, should be enough.

Thanks for wasting your time on it though ;) Sorry you 
misunderstanding it ;/ Maybe your code can be adapted though, at 
the very least you'll have to add the inheritance relationships, 
maybe that will fix it and make it all work right?

I will say that in the code I posted, you cannot remove the 
interfaces nor the inheritance relationships. Doing that 
completely destroys everything. If you think it can you are not 
understanding the problem correctly and should focus on realizing 
why it is necessary.

Try to think of it in terms of a real world application. Say a 
program that uses a model, such as a video game that uses oop to 
manage the video game objects... and then you create an entirely 
new model that adds something new to the model. Rather than 
extend each class individually you want extend the entire model 
to a new one in a consistent and logical way.

You do this by copying and pasting all the "structure". But your 
model won't be able to just drop in and replace the original 
because it doesn't inherit in any way... so you start adding 
inheritance, but now it's MI because your model already has 
inheritance in it(since the original model had it since it was 
oop based). Now you have to use interfaces because of SI in D. If 
you do everything right, and the original model was designed with 
proper object construction that allows extension(e.g., overriding 
"new" or having a factory) then  your new model will can simply 
be dropped in to the original model without issue. EXACTLY the 
same as how it would work for a single class and object. [that is 
the goal at least and to make that happen requires some work, but 
one is properly extending models the other is proper object 
creation]

If done right though, and ideally with help from the compiler, it 
becomes very simple too do so. You can think fo class inheritance 
as a very slimmed down and naive version of model inheritance. 
class inheritance is model inheritance because a simple base 
class - derived class is a model.

You can think of traditional inheritance as being a dumbed down 
version of model inheritance or model inheritance is a 
generalization of class inheritance.
Jul 06 2019
parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Saturday, 6 July 2019 at 19:45:24 UTC, CheeseWiz wrote:

 No, sorry, The classes have to actually inherit. The model 
 itself has to be substitutable in all ways in to the original 
 model, else it is not derived.


Can you please show in code something that can't be done with the 
code I wrote (or better, 
https://gist.github.com/Biotronic/f362732f83e7b4c6a4b3370919d73be3, which fixes
some issues in the original)?

I know there are language limits that no library code can 
overcome, but for the vast majority of cases, this is no issue. I 
can get all of this to work:

unittest {
     // Implicit conversions to ModelA:
     ModelB.Dog a = new ModelB.Dog();
     ModelA.Dog b = a;
     ModelB.Animal c = a;
     ModelA.Animal d = c;

     assert(a !is null);
     assert(b !is null);
     assert(c !is null);
     assert(d !is null);

     // Methods are inherited from the corresponding class in the 
base model:
     assert(a.eat() == "foo.ModelA.Dog");
     assert(b.eat() == "foo.ModelA.Dog");
     assert(c.eat() == "foo.ModelA.Dog");
     assert(d.eat() == "foo.ModelA.Dog");

     // bark() is overridden in ModelB.Dog, so that's the version 
what's being called:
     assert(a.bark() == "foo.ModelB.Dog");
     assert(b.bark() == "foo.ModelB.Dog");

     // bite(), however, is not overridden, so ModelA's version is 
used:
     assert(a.bite() == "foo.ModelA.Dog");
     assert(b.bite() == "foo.ModelA.Dog");

     // Managed to fix casting from ModelA to ModelB:
     assert(cast(ModelB.Dog)d !is null);
}

I'm unsure what functionality 'proper' inheritance buys you over 
what I've made. (sugar, sure. But functionality?)

Since my code may be somewhat hard to follow, I'll describe what 
it does: mixin inherit!ModelA inside ModelB.Dog creates a new 
class derived from ModelA.Dog that points to the ModelB.Dog 
instance, and forwards method calls to this where appropriate. We 
then use alias this to make ModelB.Dog implicitly cast to this 
new class.

To use diagram somewhat like yours: 
https://i.imgur.com/t4z9c3D.png (black lines are regular 
inheritance, orange ones are regular inheritance using 
AutoImplement, and dashed lines are alias this)

So the classes defined in ModelB don't derive from anything in 
ModelA, but use language features to behave as if, in any way we 
care. If there are cases we care about that I haven't thought of, 
I'd love to be told of them.



 1. Any new model must preserve all the structure of the old, 
 else it won't work. inheritance does this, that is the whole 
 point. If the structure is not preserved want can't substitute 
 the derived class or model for the base class or model. If you 
 leave out "connections" then something will go wrong at some 
 point. It's like creating, say, a circuit from a schematic and 
 leaving out wires saying "Oh, this wire doesn't matter" when, 
 in fact, it does.  This is wiring up the modelB to modelA 
 structurally. This could be called inter-model inheritance.


I believe this is very adequately covered in my code. If you have 
an actual counterexample, please show it.



 2. The model must be properly extendable within itself. By 
 removing the intra-model inheritance(like Jesse did). This 
 allows one to work within the model as if they were working 
 completely from the original model, but as if it were entirely 
 new(meaning one can add new structure but not remove structure).


I fail to see how my code precludes this. Please to show?



 I think the confusing part for you guys is that both types are 
 still basic inheritance. Ya'll are not recognizing that there 
 is a subtle distinction between the conceptually. Model 
 inheritance(inter-model) is analogous to class 
 inheritance(inter-model).


This is either perfectly obvious, or you are describing something 
very different from what it seems you are describing. If the 
latter, please try again, as I really want to understand.



 Thanks for wasting your time on it though ;) Sorry you 
 misunderstanding it ;/ Maybe your code can be adapted though, 
 at the very least you'll have to add the inheritance 
 relationships, maybe that will fix it and make it all work 
 right?


It does have the inheritance relationships, just not the way you 
may be expecting them.

--
   Simen
Jul 07 2019
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 5 July 2019 at 11:22:10 UTC, CheeseWiz wrote:


 You seem to think the example is a real world model and that 
 all other models would work the same.


No I asked a question about your model and you said it couldn't 
be done without interfaces, I showed that wasn't the case.


 You've removed all the interfaces so you would not have MI. You 
 believe that was as smart thing. But you have completely 
 disconnected  ModelB from itself.

 Now ModelB.Dog does not inheret from ModelB.Animal.


Your model doesn't do that either, why? Because D doesn't have 
multiple inheritance. You would need `ModelB.Dog : ModelB.Animal, 
ModelA.Dog` but you can't because D does not allow for it.


 2.

 My original code:

 	ModelA.iAnimal animal1 = new ModelB.Cat("Super Mittens");
 	ModelA.iAnimal animal2 = new ModelB.Dog("Super Sparky");

 you changed the returns to auto.


You are correct, and that only has the effect of forcing the cast 
I removed, my model matched the behavior of your model.



 3. You have to realize you are wrong, that is the first step to 
 understanding. I've tried to point it out but you are probably 
 still thinking "But I'm right and he's wrong".


No, I don't think I am right, I think I was wrong because the 
model you provided was inaccurate for requirements you are 
placing on me.

A wise man once said to me, "You have to realize you are wrong, 
that is the first step to understanding"

See, what happened is you missed the point of removing all the 
interfaces, it was to show that the interfaces you chose to add 
were not necessary to meet the code you had put into place, it 
was also intended to show that your inheritance of all the 
different interfaces in all classes was excessive and causing 
issues.

Here is a more accurate representation of your model when 
correctly written in D.

https://gist.github.com/JesseKPhillips/b891604444f4aee72c705b498a206d50

What you will notice is that the ModelB.Animal class is commented 
out, the reason for this is because it is not utilized your 
original model as you never inherited that class, all you did was 
`alias Attack = Animal.Attack;` but that isn't doing what you 
think it is doing.

I instructed ModelB.iAnimal to `override iFood LikesWhichFood()` 
because I wanted covariance and have ModelB Animials to return 
ModelB.iFood.

So please continue to insult my understanding of how D 
inheritance works, I'd like to hear more about your unbounded 
knowledge.
Jul 07 2019
parent reply CheeseWiz <CheesyFritos gmail.com> writes:
On Sunday, 7 July 2019 at 16:37:32 UTC, Jesse Phillips wrote:

 On Friday, 5 July 2019 at 11:22:10 UTC, CheeseWiz wrote:


 You seem to think the example is a real world model and that 
 all other models would work the same.


 No I asked a question about your model and you said it couldn't 
 be done without interfaces, I showed that wasn't the case.


 You've removed all the interfaces so you would not have MI. 
 You believe that was as smart thing. But you have completely 
 disconnected  ModelB from itself.

 Now ModelB.Dog does not inheret from ModelB.Animal.


 Your model doesn't do that either, why? Because D doesn't have 
 multiple inheritance. You would need `ModelB.Dog : 
 ModelB.Animal, ModelA.Dog` but you can't because D does not 
 allow for it.


 2.

 My original code:

 	ModelA.iAnimal animal1 = new ModelB.Cat("Super Mittens");
 	ModelA.iAnimal animal2 = new ModelB.Dog("Super Sparky");

 you changed the returns to auto.


 You are correct, and that only has the effect of forcing the 
 cast I removed, my model matched the behavior of your model.



 3. You have to realize you are wrong, that is the first step 
 to understanding. I've tried to point it out but you are 
 probably still thinking "But I'm right and he's wrong".


 No, I don't think I am right, I think I was wrong because the 
 model you provided was inaccurate for requirements you are 
 placing on me.

 A wise man once said to me, "You have to realize you are wrong, 
 that is the first step to understanding"

 See, what happened is you missed the point of removing all the 
 interfaces, it was to show that the interfaces you chose to add 
 were not necessary to meet the code you had put into place, it 
 was also intended to show that your inheritance of all the 
 different interfaces in all classes was excessive and causing 
 issues.

 Here is a more accurate representation of your model when 
 correctly written in D.

 https://gist.github.com/JesseKPhillips/b891604444f4aee72c705b498a206d50

 What you will notice is that the ModelB.Animal class is 
 commented out, the reason for this is because it is not 
 utilized your original model as you never inherited that class, 
 all you did was `alias Attack = Animal.Attack;` but that isn't 
 doing what you think it is doing.


The compiler forced me to do that to override the base class. 
Irregardless, it is irrelevant.


 I instructed ModelB.iAnimal to `override iFood 
 LikesWhichFood()` because I wanted covariance and have ModelB 
 Animials to return ModelB.iFood.

 So please continue to insult my understanding of how D 
 inheritance works, I'd like to hear more about your unbounded 
 knowledge.


I'm not insulting you. I was pointing out that your incessant 
"You don't needed interfaces" is wrong. I'm sorry you seem to 
think that when someone gives an example that example is all that 
matter. I have to give examples to express concepts.

I was trying to get you to realize that you are missing the point 
but you seem to want to keep on harping it. I will make it clear: 
THE EXAMPLE I GAVE IS AN ****EXAMPLE****. Is that clear?

Here is the definition of an example:

ex·am·ple
/iɡˈzampəl/
  Learn to pronounce
noun
1.
a thing characteristic of its kind or illustrating a general rule.
"it's a good example of how European action can produce results"
synonyms:	specimen, sample, exemplar, exemplification, instance, 
case, representative case, typical case, case in point, 
illustration
"a fine example of a 16th-century longhouse"
2.
a person or thing regarded in terms of their fitness to be 
imitated or the likelihood of their being imitated.
"it is vitally important that parents should set an example"
synonyms:	precedent, lead, guide, model, pattern, blueprint, 
template, paradigm, exemplar, ideal, standard; More
verb
1.
be illustrated or exemplified.


What you did was make my example as if it were an actual problem. 
It should have been clear that the example was ridiculous as a 
problem by it's nature.

The whole problem was about modeling, not about somehow 
optimizing the example.  You failed at that, I'm sorry, I tried 
to get you to understand that so we could move past it but you 
still want to seem to harp on it. I told you several times you 
were wrong in removing the interfaces. You took it as being wrong 
in making that example work, I was telling you that it is wrong 
to remove it because it destroys the examples as being an example 
of the larger problem I am talking about. I stated many times 
what I was trying to do and you insisted at every step I didn't 
need interfaces and I told you they were required for the general 
problem. You ignored that and now you want to blame me for you 
ignoring it. I told you many times you can't ignore it and you 
are wrong for doing so but now, again, it is my fault for you 
ignoring it. You still seem to think you are right because you 
reduced the example to an equivalent example that is functionally 
the same. Well, duh... but now what the fuck am I suppose to do 
with real problems that actually matter rather than some 
contrived and pathetic example that was meant to be precisely an 
example to illustrate the more general problem(the problem I did 
state in more general terms)?

I mean, seriously, what the hell is one suppose to do? Give an 
example and create in in such a way that no one could ever reduce 
it to a example that then is irrelevant? Come on! That is now how 
things work no matter how much you want them to!

See, what you were suppose to do in your brain is say "Ok, this 
is an example, I'll assume in requirements for inheritance are 
necessary in the larger scope and because he has told me several 
times they are... I'll just take his word for it". But no, it's 
all my fault for not just accepting your answer as being correct.
Jul 07 2019
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 7 July 2019 at 20:42:00 UTC, CheeseWiz wrote:

 On Sunday, 7 July 2019 at 16:37:32 UTC, Jesse Phillips wrote:

 https://gist.github.com/JesseKPhillips/b891604444f4aee72c705b498a206d50

 What you will notice is that the ModelB.Animal class is 
 commented out, the reason for this is because it is not 
 utilized your original model as you never inherited that 
 class, all you did was `alias Attack = Animal.Attack;` but 
 that isn't doing what you think it is doing.


 The compiler forced me to do that to override the base class. 
 Irregardless, it is irrelevant.


It did not force you to do that because you did not inherit that 
base class.

You started with complaints about how verbose D was with the 
modeling pattern you wanted to express, you claimed it was 
possible and this was an example.

The example actually shows that D does not allow you to model as 
you desired, but that wasn't the claim you were making, you said 
the example did what you wanted but it doesn't.
Jul 07 2019