Comment 1 Sven Efftinge 2012-11-08 05:05:04 EST

what validation would you like to have here?

Comment 2 Sebastian Zarnekow 2012-11-08 05:22:38 EST

Good question ...

I had the following use case with a class that defines:

def dispatch generateModifier(JvmGenericType it) {}
def dispatch generateModifier(JvmField it) {}
def dispatch generateModifier(JvmOperation it) {}
def dispatch generateModifier(JvmConstructor it) {}

Starting the migration towards

def dispatch generateModifier(JvmGenericType it, TracingAppendable appendable)

I'd usually use the compiler to provide hints where a method was called with the wrong number of arguments. Since there is no Change Method Signature refactoring (yet :p), it was hard to spot all the places where I had to make changes - first all the declarations, afterwards all the clients.

But that's only half of the story. Assuming a type hierarchy with

class Super {
  def dispatch generateModifier(JvmGenericType it) {}
  def dispatch generateModifier(JvmField it) {}
}
class Sub extends Super {
  def dispatch generateModifier(JvmOperation it) {}
  def dispatch generateModifier(JvmConstructor it) {}
}

The newly introduced dispatch cases actually contribute to the 'real thing'. However, there is no override / overload validation thus changing the super type's signatures silently breaks the subtype since it'll simply define its own variant of 'generateModifier'.

I'm aware that there are other cases where a change in a super type breaks subtypes so I'm not sure about this feature request any more.

Comment 3 Sven Efftinge 2012-11-08 06:12:14 EST

I guess we can alt least come up with some optional warnings.