Ok, folks, I agree and quickly code it :-)
Mika ----- Original Message ----- From: "robert burrell donkin" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, December 18, 2001 7:45 PM Subject: Re: Second patch, somewhat easier, replacing the first one.... > > On Tuesday, December 18, 2001, at 03:37 AM, Craig R. McClanahan wrote: > > > > > > > On Tue, 18 Dec 2001, Mika Goeckel wrote: > > > >> Date: Tue, 18 Dec 2001 00:09:48 +0100 > >> From: Mika Goeckel <[EMAIL PROTECTED]> > >> Reply-To: Jakarta Commons Developers List <commons- > >> [EMAIL PROTECTED]> > >> To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > >> Subject: Re: Second patch, somewhat easier, replacing the first one.... > >> > >> Rob, > >> > >> do you think of a callback in the digester to get the information what > >> last > >> matched? > >> The problem with that is that the digester would need to store the > >> information in an instance variable then. > >> Ok, digester is not multithread-safe, but my blood always runs cold when > >> I > >> think about 'global' variables. > >> I'd prefer a clean way of passing the information to the configuration > >> method. > >> > > > > My blood shivers at things like that as well, but there's already 25 or so > > other instance variables ... one more wouldn't matter. I can't really see > > why anyone would need a thread-safe Digester, so I don't see much point in > > making it so (or paying the extra synchronization costs). > > yes, i agree, i know it feels wrong. unfortunately calling digester back > is IMHO the lesser of two evils. > > when we were thinking about those other rules, we considered breaking or > extending the rule interface instead. the problem is that once you start > modifying the rule interface to pass more information in, when do you stop? > with two parameters, ten, twenty? every addition adds complexity or > breaks compatibility. > > hopefully sometime in the future we might know pretty well enough what's > required and then we could think about making it work differently. > > - robert > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
