The 3 methods are
A) superclassing
B) superclassing modified
B) delegation.
In thinking over superclassing vs delegation, I realized
superclassing, if used in a modified form isn't so bad.
However straight superclassing presents real design problems with
inconsistent states between
On 30 Oct 2002 [EMAIL PROTECTED] wrote:
Rename Application components to Module
It would probably be more convenient to have this conversation directly on
STRUTS-DEV while we hash out the details :-).
Regarding Rob's basic issue, it might be worthwhile to see how I treated
essentially the
Craig R. McClanahan wrote:
So, this is a long-winded case of asking why can't we do this?
* Move all the functionality of ApplicationConfig to ModuleConfig.
* Make ApplicaitonConfig a subclass of ModuleConfig with no
extra methods of its own.
* Deprecate the ApplicationConfig class itself.
On 30 Oct 2002 [EMAIL PROTECTED] wrote:
I have also checked out the struts_1_1_b2 branch,
any method that appeared after that release will be simply replaced
and not deprecated. Again since ApplicationConfig derives from
MethodConfig code should still compile in the case of
method