Re: DO NOT REPLY [Bug 14054] - Rename Application componentsto Module

2002-11-02 Thread Rob Leland
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

Re: DO NOT REPLY [Bug 14054] - Rename Application componentsto Module

2002-10-30 Thread Craig R. McClanahan
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

Re: DO NOT REPLY [Bug 14054] - Rename Application componentsto Module

2002-10-30 Thread Rob Leland
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.

Re: DO NOT REPLY [Bug 14054] - Rename Application componentsto Module

2002-10-29 Thread Craig R. McClanahan
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