View source for Talk:Covariance and generics case study

← Talk:Covariance and generics case study

You do not have permission to edit this page, for the following reasons:

The action you have requested is limited to users in one of the groups: Autoconfirmed users, emailconfirmed, editors.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

--[[User:Peter gummer|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.

Return to Talk:Covariance and generics case study.

Retrieved from "https://dev.eiffel.com/Talk:Covariance_and_generics_case_study"

View source for Talk:Covariance and generics case study

Navigation

Development

Wiki

Search

Tools