Difference between revisions of "Talk:Covariance and generics case study"
| Line 7: | Line 7: | ||
---- | ---- | ||
I tried doing this and it worked well for routine parameters but broke down with function returns. The functions wanted to return the complex generic class but I couldn't downcast these to the simplified versions. | I tried doing this and it worked well for routine parameters but broke down with function returns. The functions wanted to return the complex generic class but I couldn't downcast these to the simplified versions. | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | For example if I had a class operating on complex generic parameters: | ||
| + | |||
| + | class SIMPLE | ||
| + | inherit (complex generic type) | ||
| + | |||
| + | encrypt (in: (complex generic type)) | ||
| + | is do end | ||
| + | |||
| + | make_new_key: (complex generic type) | ||
| + | is do end | ||
| + | |||
| + | I could put SIMPLE in to the encrypt feature, however, I could not assign the return from make_new_key to SIMPLE. | ||
Latest revision as of 08:26, 3 July 2008
--Peter gummer 17:53, 13 April 2008 (PDT) This is a really good comparison!
The explosion of complex declarations in the generic cases could be defused by declaring new classes. It's similar to how you had to declare new classes to redefine features covariantly. Those new classes would encapsulate the generic parameters, saving clients the trouble of worrying about the generics.
I tried doing this and it worked well for routine parameters but broke down with function returns. The functions wanted to return the complex generic class but I couldn't downcast these to the simplified versions.
For example if I had a class operating on complex generic parameters:
class SIMPLE inherit (complex generic type)
encrypt (in: (complex generic type)) is do end
make_new_key: (complex generic type) is do end
I could put SIMPLE in to the encrypt feature, however, I could not assign the return from make_new_key to SIMPLE.
