Personal view about catcall solution

--Juliant 07:30, 23 June 2007 (CEST)

As explained in the general remarks section, you need to be able to express contravariance to be able to correctly model agents and comparator objects. For this reason, I suggest using the usage-site variance for generics since it is powerful enough to model the agents right.

As this only solves the case of generics, another solution has to be used for non-generic types. Again, the general remarks section explaines that another solution is needed to solve the catcall problem of non-generic types as otherwise the expressiveness of the programmer is restricted if the covariantly redefined features (e.g. is_equal) and the features with formal generic parameters (e.g. put) are treated the same.

For this reason I suggest using the DOG proposal for non-generic covariance. Although this may restrict the use of covariance severely as you need to know in advance which features can be used covariantly, it still allows features to declare parameters as like Current and thus implicitly as covariant.

--Seilerm 07:41, 23 June 2007 (CEST)

I find the expressiveness of the Usage-site_variance quite astonishing. A huge plus is that it solved the agent mechanism flawlessly.

We identified NUMERIC, COMPARABLE as well as several ANY features like is_equal, copy, ... as the source of argument covariance in ordinary types. NUMERIC and COMPARABLE rely on `like Current'. I would design classes which have a need for argument covariance in the sense of 'like Current' over generics:

NUMERIC / COMPARABLE and the like

class NUMERIC [G] feature

 plus alias "+" (a_other: G): G
   deferred
   end

end

class INTEGER

inherit

 NUMERIC [INTEGER]

feature

 -- ...

end

The same is possible for COMPARABLE and makes it even more expressive in conjunction with the Usage-site variance.

These classes are both basic building structures of the base library which would need to be adapted. But a redesign is planned anyway for the near future as far as I now.

is_equal, copy and the like

They can be made non generic with added preconditions or have already another solution like the ~ operator.

I also think that the solution by using renaming is ok in the rare cases where a sudden need for covariant argument redefinition occurs. Usually this is a setter of covariant redefined attribute. Other proposals, like the dog proposal, cannot help here either as the need for covariance was not foreseen. After removing ordinary argument covariance from our libraries we could make the covariant feature redefinition configurable on a per cluster basis to support legacy code.