D modeling

[Jesse Phillips]

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.