Difference between revisions of "Talk:Restrict"

Revision as of 05:53, 20 September 2007

I would have to disagree with the elegance of this solution.

If we have a virtual restricted form of ANIMAL that CAT conforms to, let's say ANIMAL1, but ANIMAL1 does not conform to ANIMAL, what is the point of defining ANIMAL1? In the future when there are new virtual covariant forms of ANIMAL, ANIMAL2, ANIMAL3, that have different combinations of restrictions but none of which conform to ANIMAL or each other, what is the point of having them? Why not just use CAT, or DOG instead of CAT -> ANIMAL1 or DOG -> ANIMAL2. If ANIMAL is not an abstraction of things that conform to it, it's not an abstraction by the very definition.

In this case, sleep should not be in the definition of ANIMAL, but instead in a class ANIMALS_THAT_SLEEP to which cat does not conform.

The same thing with an animal eating food. If a specific animal cannot eat the definition of food that is defined in animal, then it is not an animal because it can't eat that food.

I may be biased, I prefer using generics with generic constraints as opposed to covariant redefinition.

ANIMAL is an abstraction of things that conform to it. --Colin-adams 08:41, 20 September 2007 (CEST)

--Ericb 16:53, 20 September 2007 (CEST): What I don't like with this kind of solution, and I already expressed that feeling at ECMA meetings, is that it will make the declaration of the type of the entities too verbose to my taste. But perhaps I'm wrong. Another thing that I don't like is that it gives me the impression that now the signature of features will have to expose what covariantly redefined features they call or not in their implementation. If this is the really the case, then do we really want implementation details to be visible from the interface in the such a way?