Refactoring in Crystal

rename.cr

class Foo
  def foo(x)
    # Rename this call from "bar" to "baz":
    # What other things change in this file?
    #
    # According to what's called, Bar#bar needs
    # to change. But what about Baz#bar? I can
    # also pass Baz.new to Foo.new.foo. There's
    # no way to tell if that should be renamed too.
    #
    # Renaming based on usage isn't correct. The
    # only solution to this is to make all methods
    # have mandatory argument types, and return
    # types. Then you'll know for sure what needs
    # to be renamed.
    x.bar(1)
  end
end

class Bar
  def bar(x)
  end
end

class Baz
  def bar(x)
  end
end

Foo.new.foo(Bar.new)

So obviously the tooling wouldn't always be able to automatically refactor cases like this, but after semantic analysis, wouldn't it be possible to refactor some things and emit information about ambiguous cases for the user to refactor manually?

That's not much of an improvement over just running the compiler and fixing each error until it works, but it could at least list all of the cases at once (rather than one at a time from compiling) and in a nicer format (just file+line entries with a line or 2 of context, maybe).

Note: this is me speaking completely theoretically based on experience with the language and some previous discussions. I don't have any actual experience with Crystal's tooling to know what it can and can't do.

@asterite Interesting, in TypeScript you get an error:

    # Renaming based on usage isn't correct. The
    # only solution to this is to make all methods
    # have mandatory argument types, and return
    # types. Then you'll know for sure what needs
    # to be renamed.

So, we can just allow refactoring/renaming if the method/symbol is manually typed, to be able to get properly refactoring, is just like TypeScript does.

Also, expanding on @faustinoaq's comment on C++ refactoring tools, clang-rename is an attempt at doing this sort of thing, though it has plenty of restrictions on what it is really capable of.

Personally, local variable renaming, and small refactors such as "extract this subexpression to a variable" would be my 99% usecase for a refactoring tool. Renaming methods at the callsite seems complex, simply look up definitions and rename at the method definition site. For renaming at method definition, first type the whole program, rename all the places where we call the method on the non-union type, then give me a list of places where the method is called on a union which includes the type, and let me decide what to do on a case-by-case basis.

Well, I guess I can add at least basic rename support 👍 , see: crystal-lang-tools/scry#101 (comment)