Update inheritance.md - covariance and contravariance #276
Conversation
syntax_and_semantics/inheritance.md
Outdated
|
|
||
| ## Covariance and Contravariance | ||
|
|
||
| One place this can get a little tricky is with arrays. We have to be careful when declaring an array of objects where inheritance is used. For example, consider the following |
There was a problem hiding this comment.
please be specific about what "this" is.
|
Thanks @RX14 for the review. I updated |
|
Thank you @KCErb! |
| end | ||
| ``` | ||
|
|
||
| because in the initialize the default type for @arr is `Array(Bar)` but the required type is `Array(Foo)`. You can solve this by specifying the type explicitly: |
There was a problem hiding this comment.
default type for @arr
This is not concept of the type system. I would suggest explaining that the type of the [Bar.new] expression is Array(Bar) and that is not assignable to an Array(Foo) instance var.
Then it follows from the previous example why the expression [Bar.new] of Foo works.
There was a problem hiding this comment.
Yes, I can see how my language is a bit confusing / imprecise here. I'll reword a bit and see what you think.
| end | ||
| ``` | ||
|
|
||
| The way Crystal handles the bigger topic of [covariance and contravariance](https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)) in general, has more tricks and pitfalls to it, so you may be interested in [this issue / discussion](https://github.com/crystal-lang/crystal/issues/3803) for more reading. |
There was a problem hiding this comment.
I would not link issues from the repo. It does not help to read the guide as a book.
Also,
has more tricks and pitfalls to it
adds no explanation or description current limitations.
I know the Covariance and Contravariance is not fully supported since the user can't express fully it's expectation in generic classes, nor the compiler infers what happens. Given that, maybe examples should cover: tuples (or named tuples), arrays, custom generic classes.
Another aspect mentioned is that method matching does not uses the notion of substitutability to determine if a definition should be used or not. In this PR only assignments were used, hence substitutability principle is used.
There was a problem hiding this comment.
I'd be happy to remove this link, seems a little strange to me. :)
As for some of the examples you mentioned, is this the best place or is it potentially growing the article too much? If we really want to address covariance and contravariance as a topic in the gitbook, I might not be the best person, it's a little over my head at the moment (though I could catch up with a bit of reading it seems).
I can think of a few roads:
- Small: just remove the link and the stuff about "pitfalls" to keep it to one simple example of an array and link to the wikipedia article.
- Medium: add in an example using a Tuple here or put one on Generics over in the generics inheritance section and link to it.
- Large: consider doing a separate page on the topic of covariance and contravariance to fully document the expected behavior in a wide range of cases, link to that in places that mention inheritance such as this article or the one I just mentioned on generics.
It's only that third option that I wouldn't feel totally qualified to write up properly. Which direction do you (folks) lean?
|
Sure I'd be happy to work on this a bit more. Would it be better to restore the branch and push more changes to it or make a new branch? |
|
Great! Thanks. Opening a new PR is fine. This PR is an improvement by itself :-) |
|
OK cool, will do next chance |
Not sure about linking to an issue in the gitbook ... but otherwise, how's this for a crack at crystal-lang/crystal#6507 (comment)?