> I find the CallCopyingArgHandler is not static, but the doc doesn't specify > the reason. > Does someone know why?
If you try making it static you will see that it is unable to use the current shuttle to visit the children. CallCopyingArgHandler exists for a very short duration - visit of one SqlCall by the shuttle. Still, there are multiple CallCopyingArgHandler instances active at the same time, so having one CallCopyingArgHandler per Shuttle instance (shared among all call visits) is not an option. > On Jun 25, 2021, at 6:00 AM, Yanjing Wang <zhuangzixiao...@gmail.com> wrote: > > In my scenarios, I created some visitors for sql node to rewrite the sql, > for example, rewriting all literals to generate a sql template. > > But I don't like many new constructors scattered somewhere. I like > singleton and dependency injection. so I read SqlShuttle source code to > look for the probability. I’m not a fan of dependency injection. I can see that it has its place, e.g. for gluing together components at the macro level. But it requires mutable fields. At the micro level, I am a fan of immutability, final fields assigned in the constructor. I agree that CallCopyingArgHandler is a strange bird. It has the purpose of a “strategy pattern”, except that it has some state. It was written a long time ago, and I’m not sure I’d do the same today. (I haven’t given it much thought.) Julian
