The return type can be ignored... Fortress is soon to be released, but not yet. If it really needs to be changed, change it.
> -----Original Message----- > From: Leo Sutic [mailto:leo.sutic@;inspireinfrastructure.com] > Sent: Monday, November 11, 2002 4:33 AM > To: 'Avalon Developers List' > Subject: RE: Chaining Methods and Fortress > > > > > > From: Peter Donald [mailto:peter@;apache.org] > > > > ex-C++ developers > > *Quiet! Don't tell anyone!* > > > The one place where this convention was broken (NIO) ended up > > being regretted by the EG members who pushed through the change. > > I'm not familiar with this. Do you have a link? The reason > I'm asking is that I have written code that way, and I would > like to know if there's some issue with it that I have > overlooked. > > Is it related to subclassing (i.e. subtype can not override > return type, even to subtype of supertype's return type)? > > > If you still want it then I can just create an alternative > > mechanism that follows standard idioms but I would prefer > > to only support one mechanism. > > I would prefer to keep the code as-is. The code you're changing > is three months old and thus released with Fortress 1.0, irrespective > of the technical merits of one solution over another. > http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/fortress/src/ java/org/apache/excalibur/fortress/util/ContextBuilder.java.diff?r1=1.21 &r2=1.22&diff_format=h If the issues surrounding the idiom is serious enough I have no problem fixing it (I can do the proper deprecation cycle). What is your estimate - is it serious enough to warrant deprecation, renaming of methods (as you can not overload on return type)? /LS -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
