Difference between revisions of "Talk:Interval types"
| Line 3: | Line 3: | ||
:'''--[[User:Manus|manus]] 18:14, 8 July 2007 (CEST)''': This case is just a typical case of implicit covariance. The rules are the same and therefore any feature involving `like Current' in its arguments will most likely be rejected in some cases unless the target is monomorphic. Dont' forget that it is mostly the case with `is_equal' and `copy' which are getting new signatures in the new ECMA standard. For COMPARABLE then it just mean that you won't be able to compare apple with oranges which is exactly what we are trying to avoid. | :'''--[[User:Manus|manus]] 18:14, 8 July 2007 (CEST)''': This case is just a typical case of implicit covariance. The rules are the same and therefore any feature involving `like Current' in its arguments will most likely be rejected in some cases unless the target is monomorphic. Dont' forget that it is mostly the case with `is_equal' and `copy' which are getting new signatures in the new ECMA standard. For COMPARABLE then it just mean that you won't be able to compare apple with oranges which is exactly what we are trying to avoid. | ||
| − | '''--[[User:Schoelle|Schoelle]] 15:30, 10 July 2007 (CEST)''' Thanks for the answer, this was enlighting. Second question: can anybody give examples from the practice that are different from A..A and A..NONE ? Something like A..B that really is needed | + | '''--[[User:Schoelle|Schoelle]] 15:30, 10 July 2007 (CEST)''' Thanks for the answer, this was enlighting. Second question: can anybody give examples from the practice that are different from A..A and A..NONE ? Something like A..B that really is needed and makes sense? |
| + | |||
| + | :'''--[[User:Seilerm|Seilerm]] 20:33, 10 July 2007 (CEST)''': I think this comes down to the very question where covariance on ordinary types is needed. If you want I can give a lot of examples for generics, probably because it is the main source where I personally use covariance. Besides that: I have seen code where one uses anchored types (i.e. the like keyword) to anchor argument types to the type of queries (mostly attributes). And then the query result type is redefined covariantly. This might be interesting if otherwise you would need a lot of generic parameters, but you only redefine a few times different query (attribute) types in your class hierarchy. That being said, I personally don't like this style of coding. | ||
Revision as of 10:33, 10 July 2007
--Schoelle 12:33, 8 July 2007 (CEST): Could somebody illustrate how this solves the problem of convariant argument redefinition using 'like Current' or similar?
- --manus 18:14, 8 July 2007 (CEST): This case is just a typical case of implicit covariance. The rules are the same and therefore any feature involving `like Current' in its arguments will most likely be rejected in some cases unless the target is monomorphic. Dont' forget that it is mostly the case with `is_equal' and `copy' which are getting new signatures in the new ECMA standard. For COMPARABLE then it just mean that you won't be able to compare apple with oranges which is exactly what we are trying to avoid.
--Schoelle 15:30, 10 July 2007 (CEST) Thanks for the answer, this was enlighting. Second question: can anybody give examples from the practice that are different from A..A and A..NONE ? Something like A..B that really is needed and makes sense?
- --Seilerm 20:33, 10 July 2007 (CEST): I think this comes down to the very question where covariance on ordinary types is needed. If you want I can give a lot of examples for generics, probably because it is the main source where I personally use covariance. Besides that: I have seen code where one uses anchored types (i.e. the like keyword) to anchor argument types to the type of queries (mostly attributes). And then the query result type is redefined covariantly. This might be interesting if otherwise you would need a lot of generic parameters, but you only redefine a few times different query (attribute) types in your class hierarchy. That being said, I personally don't like this style of coding.
