Difference between revisions of "Talk:Restrict"

 
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
I would have to disagree with the elegance of this solution.
+
--[[User:Clemahieu|Clemahieu]] 18:04, 20 September 2007 (CEST)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.
+
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 features of ANIMAL don't make sense for a specific subclass, ANIMAL is not an abstraction of this subclass 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.
 
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.
+
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.
 
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.
 +
--[[User:Colin-adams|Colin-adams]] 08:41, 20 September 2007 (CEST)
 +
 +
 +
--[[User:Ericb|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?
 +
 +
--[[User:Clemahieu|Clemahieu]] 19:05, 20 September 2007 (CEST)
 +
Do two different classes with identical restrict clauses conform to each other?  If so we've basically created an anonymous class.  If not, what's the point of creating a virtual class if one and only one class conforms to it and it's a one to one mapping of class definition?
 +
 +
Two different classes that inherit from the same class with the same restriction clause are both conform to the same virtual class. Whether or not they conform to each other, depends on what other features they might add.
 +
 +
As for the verbosity of the declarations, in cases where this is great, an anchor can be used.
 +
 +
I don't understand about exposing which covariant features they call in their implementation - can you expand on this?
 +
--[[User:Colin-adams|Colin-adams]] 19:26, 20 September 2007 (CEST)

Latest revision as of 08:26, 20 September 2007

--Clemahieu 18:04, 20 September 2007 (CEST)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 features of ANIMAL don't make sense for a specific subclass, ANIMAL is not an abstraction of this subclass 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?

--Clemahieu 19:05, 20 September 2007 (CEST) Do two different classes with identical restrict clauses conform to each other? If so we've basically created an anonymous class. If not, what's the point of creating a virtual class if one and only one class conforms to it and it's a one to one mapping of class definition?

Two different classes that inherit from the same class with the same restriction clause are both conform to the same virtual class. Whether or not they conform to each other, depends on what other features they might add.

As for the verbosity of the declarations, in cases where this is great, an anchor can be used.

I don't understand about exposing which covariant features they call in their implementation - can you expand on this? --Colin-adams 19:26, 20 September 2007 (CEST)