These are changes that reduce the mutable surface of SymbolType and it's usages.
It builds on https://github.com/rpau/javalang-compiler/pull/58.
If that needs rework this needs a rebase.
There are only 2 uses of "Symboltype.setName" left.
I would like to get rid of "symbol.getType().setName(nameExpr);" in LoadStaticImportsAction.
It's unfortunate that the SymbolType object that is already stored in the Symbol needs tweaking here.
But I don't understand enough of the surrounding code flow there to propose a "good" solution to
improve the general flow.
If you are OK with that I will create a new SymbolType instance at that location and set that new instance
into the "Symbol" via "Symbol.setType". (see 4f4245cf8769d5294ddfeea0e82c7c5e6dab64f9)
That helps to improve SymbolType at least.
The other usage of setName outside of Symboltype I am investigating.
When we want to remove public setters of SymbolType how to do that?
If external projects depend on them they will break.
Do you know of external usages beyond the other walkmod projects?
How do you test changes like that for the other walkmod projects?
Do you have some automatic way of checking that?
Is there some "maven way" or "travis way" or whatever that tracks new usages of deprecated code?
If yes making the setters deprecated, checking all depdendant projects for new deprecation warnings, fixing them, increasing the minimum version of the javalang-compiler dependency they depend on and at last removing the setter and increasing the version number can be done.
How did you do incompatible changes in the past?
These are changes that reduce the mutable surface of SymbolType and it's usages. It builds on https://github.com/rpau/javalang-compiler/pull/58. If that needs rework this needs a rebase. There are only 2 uses of "Symboltype.setName" left. I would like to get rid of "symbol.getType().setName(nameExpr);" in LoadStaticImportsAction. It's unfortunate that the SymbolType object that is already stored in the Symbol needs tweaking here. But I don't understand enough of the surrounding code flow there to propose a "good" solution to improve the general flow. If you are OK with that I will create a new SymbolType instance at that location and set that new instance into the "Symbol" via "Symbol.setType". (see 4f4245cf8769d5294ddfeea0e82c7c5e6dab64f9) That helps to improve SymbolType at least. The other usage of setName outside of Symboltype I am investigating.
When we want to remove public setters of SymbolType how to do that? If external projects depend on them they will break. Do you know of external usages beyond the other walkmod projects? How do you test changes like that for the other walkmod projects? Do you have some automatic way of checking that? Is there some "maven way" or "travis way" or whatever that tracks new usages of deprecated code? If yes making the setters deprecated, checking all depdendant projects for new deprecation warnings, fixing them, increasing the minimum version of the javalang-compiler dependency they depend on and at last removing the setter and increasing the version number can be done. How did you do incompatible changes in the past?