D modeling

[Simen Kjærås]

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