Wednesday, January 11, 2017, 8:58:29 PM, Daniel Dekany wrote: > Wednesday, January 11, 2017, 3:50:50 PM, Woonsan Ko wrote: [snip] >> Regarding the internal classes, I'd personally prefer putting into >> o.a.freemarker.core.internal. It could give a good insight for >> advanced API users at least. > > But that's exactly what I want to avoid. It has caused many problems > in FM 2. That they are internal means that you can't use them at all, > because if some people do that, even accidentally (IDE auto > completion...), we will break their code. Yes their mistake, but > still... certainly you wont refactor internal code so freely anymore.
I have forgotten to mention here the other difficulty with something like o.a.f.core.internal. Classes in it will make calls towards o.a.f.core classes. But as these two package very closely belong together (they aren't two proper layers on top of each other), some of those should go to internal methods inside o.a.f.core, but you can't have public internal methods there for sure (as it's not even an .internal package). -- Thanks, Daniel Dekany
