I think you are right, type propagation is much easier than value propagation. You can reconstruct the scope from the program and refactor in it. It may not do exactly what you’d expect it to do, but it would definitely compile and work.

Can you do a runtime instanceOf/cast to a structural type? And wouldn’t that make analysis more complicated?

The type alias was just a convenient way to explain what I was talking about. Even if we drop it or make it two different type aliases the argument still stands. It just may require tracing “backwards” and “forwards” in the relationships between classes/traits and structural types.

The same goes for the case you mention. If I rename foo to bar in MyClass then it’s possible to statically find all the places that MyClass (or subtypes) is being assigned to a variable, parameter, or return with a structural type and start doing fixups. There’s no reason we should end up moving from compilable code to uncompilable code in the process (as long as all the affected source is available – but again, that’s a limitation of all rename refactorings).

Look at it this way: a compiler statically analyzes code for type incompatibilities, missing methods/functions/classes/traits, etc. There’s no reason that a rename refactoring tool can’t use the same or similar analysis and incrementally play “what if” with changes until it gets code to pass that analysis.

Still, you and I are on the same page about the central points. First, structural type refactoring can create incompatibilities in code we can’t see (e.g. if we’re writing a library). But then again, renaming a method in a normal nominative class/interface can cause problems in code we can’t see if users of our library have subclassed our code.

Second, there are some excellent refactoring tools for e.g. Smalltalk. Refactoring in such a dynamic environment is usually more of an incremental affair than in a statically analyzed environment, but it still works very well – especially if you remember the cardinal rule of always having good test coverage to back you up.

I’m glad we mostly agree.

Even with type synonyms you’re still hitting the case when you rename a method in a usual class/object/trait, but it matches also a method in a structural type. Should you rename the structural type? Both decisions may cause uncompilable code, unless you rename everything in the application, which is overkill.

I’m not sure if practically it will be such a big problem, but it does somewhat hinder refactoring. Mainly I posted this to challenge the “static types make refactoring easy” crowd.

Actually the problem isn’t “external” code at all. That the example used it was just a coincidence. Consider what a common name “getName” is. You can have such methods all over your application. Only a fraction of them will be ever called with the example method. Choosing which ones to rename with the structural type is a non-trivial task.

You’re mostly right about refactoring structural typing.

Still, there’s one area where structural typing can support static analysis and refactoring. If you have a structural “type hasFoo = {def foo()}” and a method somewhere else “def doSomething(x:hasFoo)” and a another method somewhere else still “def doSomethingElse(x:hasFoo), then renaming the method required by the hasFoo type from foo to bar can cause a refactoring that statically finds all classes/traits that are ever used as parameters for the doSomething and doSomethingElse methods(assuming whole program availability, which is something most rename refactorings assume), plus of course rename the calls to foo inside those methods. At that point you’ve got a normal rename refactoring.

What it misses, of course, is all the classes/traits that potentially could be used as parameters types for the doSomething and doSomethingElse methods but didn’t happen to be used in the program being analyzed. There’s no reason you couldn’t have a refactoring utility find all such potential uses, but as you say now we’re into the land of slightly sophisticated search and replace – sophisticated because it’s not just regex searching, Scala’s refinement types can be pretty rich and give a lot more context than my simple hasFoo type.

In terms of behavior, I should think that the correct thing to do would be to change all internal calls to the structural type (obviously). Additionally, all defined instantiations of the structural type should be located (in this case by finding method calls) and all definitions which can be changed, should be. In this case, this means that the File#getName() method should be refactored, while java.io.File should remain untouched. Thus, the refactoring will lead to an error on line 12. This is the expected behavior I think because a mismatch in the structural type indicates that the *usage* is wrong, obviously not the external definition.

I really feel that we miss each other’s point. Of course rename is not always a refactor, but what I say is that it cannot always be made into a safe refactor in a statically typed language with structural types.

You are right that refactoring structural types won’t be too often, but what if you rename a method name in a type that just “happened” to coincide with one in a structural type? This is a very annoying side effect…

Seeing as it’s meant to be used sparingly (unsurprisingly, it has a large performance hit) I doubt refactoring would be that much of an issue, simply because there shouldn’t be that many instances of it in your code.

Rename x() to toString() in Java, and if the IDE doesn’t complain at you, you’ll probably have broken code somewhere. Not all renames are refactors *even without structural typing*.