Maybe a point that should be addressed in the long run (I'm thinking
Tapestry 5.0 instead of 4.1) is that sub-classing might be overused in
this framework. In an interface-designed framework there shouldn't be
too much need to "un-privatize" members.
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Jesse Kuhnert wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
