Talk:Interval types

--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.

--Schoelle 12:13, 11 July 2007 (CEST) Ok, lets me see if I can correctly summarize, relating to my article [1]. I am not doing this to advertise for my solution, but just because it is easier for me to understand something new by relating it to something that I have understood.

For Covariant arguments and anchored types, we are (more or less) removing covariance from the language (the conformance rules have been made so restrictive that the BOAT/SKIPPER/CAT/CAT_SKIPPER example becomes illegal), as demanded in my article. (1)

For Genericity, we are using rules similar to Wildcard types in Java, which disallows calls to features with arguments of a generic type (X[A..A] is X<A> in Java, X[A..NONE] is X<? extends A> in Java). (2)

I think that the approach of invariant arguments described in my paper is more elegant (I am probably just locked into own ideas), as the decision of using a generic parameter covariantly is made by the supplier and not the client, i.e. it becomes part of the library design. But if Java people can live with Wildcard types, so can we ... ;-) (3)

--Juliant 19:01, 11 July 2007 (CEST)

for (1): Actually it's not the conformance rules that have been restricted, but the feature call rules. Per default you still have full conformance between normal types, but you mostly cannot call covariant features. In the end it is the same, restricting covariance as much as you probably won't use it anymore.

for (2): Yes, they are very similar.

for (3): The problem with the invariant arguments you described is that they break the library for sure. Since one of the criterias for a catcall solution is backwards compatibility, this is not an option. If you would be starting from scratch, it may be a good option as the use of a generic is dictated by the library designer and it could be easier to use by the programmer.

--Schoelle 22:22, 11 July 2007 (CEST) This needs to be seen. Both approaches break existing code. I do not know which one breaks more. I think that invariant arguments are easier to fix, as they are fixed on the supplier side, and not on the client side.