Here's one for you guys. You see this in a few places, where I extend a method parameter to specialize it (i.e. Graphics2D), but I don't want to change the base class API? So in this case:

class Weblet
{
  virtual Void get(WebReq req, WebRes res) {}
}

class Widget extends Weblet
{
  virtual Void get(WebUiReq req, WebUiRes res) {}
}

First off, we can't even do this in Fan, since we don't support method overloading. And casting everything would suck:

Void get(WebReq req, WebRes res)
{
  uiReq := (WebUiReq)req
  uiRes := (WebUiRes)res    
}

I haven't given it that much thought yet - but one option is Ruby-esque, where we extend the original class like Rails does. Which would be a use case for the dynamic invoke operator. And I think prototype inheritance is the type of thing you want here, versues wrapping at each layer. Some food for thought - what's your guys thoughts?

That contra-variance because you are breaking the original base class's contract for get() - now I can't pass just any WebReq/WebRes like the contract says I can. It happens naturally in lots of problem spaces, but is a slipperly slope to slide down. I think our approach should be larger grained original classes versus a lot of specialized sub-classes. Although we need to talk about it. Also using dynamic invoke -> operator can solve a lot of problems too.