Re: Design by contract and control inversion

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Wed, 31 Oct 2012 20:28:30 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> The only thing I could imagine, is to create a second type, `U`,  
> re‑interfacing `T`, and passed to the handlers instead of `T`:
>
>
>      type T is private;
>
>      type U (<>) is limited private;
>
> […]
>
> […] in the real thing I did, `U` only gets a subset of the subprograms  
> applicable to `T`.

May make one feels it would be better to expression the subset relation  
with a type relation, i.e. type `T` would be a derived type of `U` (hence,  
`U`'s properties, is a subset of that of `T`).

Unfortunately, doing this:


     type U (<>) is tagged limited private;

     type T is new U with private;


… leads into an issue: you want to disallow any instance of `U` to be  
created (the reason of the unknown discriminant), but this also disallow  
instantiation of `T` as‑is, as `T` inherits the unknown discriminant. Can  
have a `Create` or `Instance` function, but would be cleaner to be able to  
get ride of this unknown discriminant. If `T` adds capabilities to `U`, it  
should be able to get ride of it, isn't it?

That make me feel again that use of the unknown discriminant is too much  
like a hack, when you just want to disallow instantiation from the client  
side. Would be nice to have something to directly express it, not  
involving any discriminants, which is a separate concept (indeed, the full  
view of the type, does not have, and does not need any).

There use to be thread on that topic, but can't remember which one it was.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University