Petition for examples of covariance
- Tags:
- type system
- covariance
There are many discussions on how to make Eiffel type-safe. The ECMA committee has been very active in coming up with solutions (though non of these solutions have been fully implemented and analysed). Most of these solutions evolve around the typing of entities and the rejection of certain polymorphic bindings.
I have claimed multiple times recently (for example in the articles Covariance through renaming or Type Safe Eiffel) that Eiffel does not need covariant arguments and any usage of covarianct arguments is conceptually flawed.
Still, it seems like people want covariance and are reluctant to remove it from the language. I have never used covariance, but I really want to know where people see it as necessary.
So here is my plea: I want to know about you and how you are using covariant arguments in your applications or libraries. Give me examples, so I can try to understand and learn why covariance is necessary and helpful.
Unfinished
Your renaming article is still marked as under construction.
Colin Adams
Tag removed
Thanks for the hint, I have removed the tag.
A Plea for Overloading (Sarcastic)
When working in languages that don't have covariance, on occasion I've resorted to overloading. Very, very few occasions. I felt filthy, but the lack of covariance had backed me into a corner: it was either overload, else do an utterly disgusting typecast.
The dangers of covariance are far outweighed by the dangers of not having covariance.
(But if I encounter an example of where we've used covariance in the next few days, I'll be sure to post it here.)
XPath data model and sequences
I faced some issues with catcalls when implementing the XPath library. My problem resolution technique was class (and code) duplication. So it's a mess.
I would like to use covariance if I could to avoid this maintenance nightmare.
Take a look at XM_XPATH_SEQUENCE_ITERATOR and its descendancy (a neologism?) tree.
Colin Adams
ECMA view?
What is the view of other members of the ECMA committee of your three-pronged proposal?
At first reading it sounds good to me.
Colin Adams
Re: ECMA view?
Hi cannot talk for ECMA in general, but the comments I have received were somehow: a) we want to have a single solution, b) covariance with renaming is "fake covariance", c) we want to have a more expressive type system, and similar.
The point of my blog entry is not that I want to advertise for my solution. My own "type safe Eiffel" article was written for me to clear up my thoughts and summarize my point of view. It is more that I really want to understand the covariance issue and why it is useful. I will definitely have a look at the classes that you suggested.
Export status
Well, I am very much against a single solution, since I strongly advocate forbidding the reduction of export status on conforming inheritance paths.
Prior to non-conforming inheritance, we had no choice. Soon we will have the choice, and it should be closed down to the only correct one.
Colin Adams
Re: Export status
If I read ECMA correctly (but it is not 100% clear to me), the removal of the export restriction is already part of the standard, so my critizism here is not correct anymore. The paper was written on the basis of pre-ECMA-Eiffel.
I do not know if ECMA is exactly the same as my solution. If that is correct, then we should not talk about CAT calls anymore ("Change of availability or type"), but only about COT calls ("Change of type").
Longing to hear
Did you ever look at my classes?
I'm still longing for a solution that will mean I don't have to keep duplicating code by the thousand-line-full.
Colin Adams