3 ms·

I have long wished that code changes to a repository could be accompanied by code refactorings that are intended to be applied to code using that repository Th

I have long wished that code changes to a repository could be accompanied by code refactorings that are intended to be applied to code using that repository This was entirely feasible in Smalltalk. Not sure if people ever applied this outside the context of ORMs/database mapping. (Some shops did something like what you are describing in that limited context.) A short script that applied a specific refactoring could be placed in a specially named method on a particular class, for example. (Or some other mechanism could be used to store metadata on what versions the refactoring was applicable to.) It was also possible to quickly hack a GUI tool that you could bring up to selectively apply the refactorings. Also, after the advent of "The Refactoring Browser" the parser engine was also used to build the refactorings directly built into the "IDE." (It's actually where the parser engine came from.) (Not only did this rewrite engine have full syntactic power, with all values wild-carded, one could also script against values in the parse tree or provide the values from snippets of code.)

masklinn 10y ago
I think they mean the "refactoring" should be shipped as part of the release to be applied by codebases depending on the library, possibly automatically or semi-automatically, it's not about a formal refactoring of the "current" codebase which most modern IDEs can do and which is pretty easy in statically typed languages. Though what they're talking about would generally be considered an API change not a refactoring.
- stcredzero 10y ago
  I think they mean the "refactoring" should be shipped as part of the release to be applied by codebases depending on the library, possibly automatically or semi-automatically That's exactly what I'm talking about! For example, in the StORE version control that comes with VisualWorks Smalltalk, it would be fairly easy to detect the presence of a particular class and method, whose name contains metadata about version, then pop up a window showing the potential refactorings. The go equivalent would be to have a dist-refactorings subdirectory, and a go tool. Maybe dist-refactor? go dist-refactor ... The refactoring scripts would have names that contain version information. Invocation of dist-refactor would cause a list of available refactoring scripts to be applied to the codebase from all of the dependencies that are at a version later than the one compiled. Alternatively, one could invoke go dist-refactor [library]

masklinn 10y ago

I think they mean the "refactoring" should be shipped as part of the release to be applied by codebases depending on the library, possibly automatically or semi-automatically, it's not about a formal refactoring of the "current" codebase which most modern IDEs can do and which is pretty easy in statically typed languages. Though what they're talking about would generally be considered an API change not a refactoring.

stcredzero 10y ago
I think they mean the "refactoring" should be shipped as part of the release to be applied by codebases depending on the library, possibly automatically or semi-automatically That's exactly what I'm talking about! For example, in the StORE version control that comes with VisualWorks Smalltalk, it would be fairly easy to detect the presence of a particular class and method, whose name contains metadata about version, then pop up a window showing the potential refactorings. The go equivalent would be to have a dist-refactorings subdirectory, and a go tool. Maybe dist-refactor? go dist-refactor ... The refactoring scripts would have names that contain version information. Invocation of dist-refactor would cause a list of available refactoring scripts to be applied to the codebase from all of the dependencies that are at a version later than the one compiled. Alternatively, one could invoke go dist-refactor [library]