Hi, On Mon, May 31, 2010 at 10:19 AM, Felix Meschberger <fmesc...@gmail.com> wrote: > On 31.05.2010 09:41, Jukka Zitting wrote: >> On Mon, May 31, 2010 at 9:39 AM, Felix Meschberger <fmesc...@gmail.com> >> wrote: >>> Let me add another word here: We must not drive the architecture of >>> anything by the desire to avoid public method in internal classes. >> >> Did anyone suggest that? Seems to me like this whole thread is a big >> misunderstanding. > > Maybe this has not been proposed explicitly, but the proposals of > JCR-2640 and JCR-890 implicitly state this ;-)
That's certainly not my intention and I'm sorry if I haven't been clearer about this. Basically, JCR-2640 is a case of two client-facing classes A and B both using shared internal state X. In the pre-JCR-2640 state class B would access X through package-private methods on A, which causes a tight coupling between A and B and forces the internals of A to be made public if B is to be moved to another package, as suggested in JCR-890. What I've proposed and now mostly implemented in JCR-2640 is to give both A and B a direct reference to the internal state X, breaking the implementation dependency between A and B and allowing B to be moved around or refactored independently of A. At no point was this about preventing "public methods in internal classes" like X. BR, Jukka Zitting
