On Fri, 2004-03-12 at 11:35, robert burrell donkin wrote: > On 10 Mar 2004, at 23:58, Simon Kitching wrote: > > > > One major issue though: the way that rules fire in reverse order at end > > regularly catches users out (see Diego's email of today in the > > commons-user list). > > <snipped useful section i agree with> > > > Users will *really* care if the SetNextRule tries to pass the "parent" > > object to the "grandparent" object, which is what I believe will havven > > with the addCreateComplexObject example above. > > yep > > > Of course all the above code is untested...I hope I'm right that this > > problem actually exists as described above :-) > > i think that it does. i was very hasty in posting last night. this > probably needs to be given a bit more thought. > > > Emmanuel Bourg raised a proposal for having CallMethodRule fire as soon > > as all of its params are available; we had a discussion on this list > > just a week or so ago ["CallMethodRule order, bug 12997"]. The proposal > > was rejected due to backward-compatibility issues, but would have > > avoided this. As this is a new Rule, I guess we could instead take that > > approach. It would make the new rule inconsistent with CallMethodRule > > behaviour, though. > > we should probably look back at emmanuel's problem since i recall that > we could solve it by using a separate stack.
Well, this email (which was posted on this list a few weeks ago) provides some comments on Emmanuel's original patch, and an alternative proposal. http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=107783392913490&w=2 This is also why I'm not particularly keen on making the digester param stack accessor methods public; it would prevent us from making this sort of change. Alternatively, we could indeed have a separate stack; essentially have an "old-style" param stack in order to avoid breaking compatibility with user code that accesses package-private methods and a "new-style" param stack. Personally, I think that anyone writing code to access package-private methods of Digester should expect their code to break with later releases... Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
