I think I understand a little better the reasoning behind some of the private/protected member/method access throughout the framework, but I still feel like it would help us (tapestry) continue to move forward and allow the users to implement what they need when we don't have time to do it or examine what they want.
It does expose the internals quite a bit more and will probably cause headaches for people when internal changes are made, but the big question is, which is better? Completely cut-off the ability to do these things, or allow it with the "you're messing with internals, use at your own risk because we will change them whenever we want". I'd personally rather have the freedom to override things and go through the effort of updating whatever I'm doing to work with new tapestry versions as they come out. If this change is ok'd I'd like to implement it on a as I see it kind of basis. Not an all inclusive overhaul. Would just have to take a careful look at each class being used and determine if members/methods really should be private, or if protected be sure that enough of the members are also protected to make them useful. I'm more for making everything protected by default, as a means to allow extension where appropriate. There are special cases where there is just no way that it is safe for people to use/override a member or method, and this instance makes sense to be private of course. Thoughts? jesse
