interfaces and contracts - new pattern

[Ola Fosheim Grøstad]

On Tuesday, 3 December 2019 at 15:25:19 UTC, Adam D. Ruppe wrote:
> On the parameters side it is a little more confusing, but it 
> still makes sense:
>
> abstract class Generic {
>     void generic(Generic g);
> }
>
> class Specialized : Generic {
>     override void generic(Specialized g) {}
> }

But this doesn't work in D.


> There you can see the obvious problem:
>
> Generic g = new Specialized();
> Generic other = new SomethingElse();
> g.generic(other); // uh oh, interface allows it but 
> specialization doesn't

It could have resolved it by calling the Generic.generic(...) 
method then the Specialized.generic could have tested it... but 
it gets messy.

Makes more sense for a dynamic language, I guess.

> class Specialized : Generic {
>     override void generic(Object g) {}
> }
>
> since Generic implicitly casts back to Object, it is clear 
> anything from the interface can also go to the child, so you're 
> fine.

Yes, but when do you need to do it? So it is typesafe, but what 
would the use case be?

> It does make sense if you think about it, just it is weird if 
> you don't.

Sure, but it seems to me that something is missing when it comes 
to virtual function parameters. Then again, I think overriding 
the implementation of the subclass is kinda ugly. Some languages 
(at least one),  force you to call the super class virtual method 
as a wrapper around the subclass virtual method specialization. 
So basically the superclass gets to "look at" and act on the 
parameters before the subclass does.

I've got a feeling that one could do something interesting with 
such semantics that would make all this variance-stuff cleaner... 
somehow. But I haven't given it a lot of thought. Just a feeling. 
:)