On Mon, 2003-09-29 at 03:40, robert burrell donkin wrote: > On Saturday, September 27, 2003, at 06:43 PM, Craig R. McClanahan wrote: > > > Simon Kitching wrote: > > > >> Hi, > >> > >> The current Rules interface defines > >> > >> public List match(String uri, String patern); > >> > >> This is giving me significant problems for the Plugins module I am > >> working on. I also think it is simply the wrong type to be returning > >> here; a List has many operations available on it which are not > >> appropriate in this situation. > >> > >> I would like to suggest that the following method be added to the Rules > >> interface, and the "matches" methods be deprecated: > >> > >> public ListIterator iterator(String uri, String pattern);
> >> > >> This seems to me to encapsulate the goal of the existing "matches" > >> method: to provide access to the set of Rule objects matching the > >> criteria. [I'm flexible on the method name ;-] > >> > > I'm OK with the concept of returning an iterator from a Rules > > implementation, but would suggest (if we do it) that the signature say > > Iterator instead of ListIterator (the implementation in RulesBase can, of > > course, return a ListIterator if it wants to). > > > > We'd certainly need to keep the existing match() signature around for > > backwards compatibility. Adding methods to interfaces is also a nasty > > thing to do, but I suspect most people will be extending RulesBase > > already. > > i'm not so sure about that. when i developed the RegexRules i discovered > that when creating a very different implementation, RulesBase is > unsuitable. (that's why i added AbstractRulesImpl.) > > > if we are thinking about changing Rules yet again then it seems to me that > we should consider whether making this class an interface was the correct > design decision in the first place. if Rules had been an abstract class > then it would have been very easy to make the change suggested by simon > without breaking compatibility. maybe it should be an abstract class. > > we could think about deprecating Rules in favour of an abstract class > (AbstractMatchingRules or something). getRules and setRules would be > deprecated but would continue to be supported via wrappers. we could add > getMatchingRules and setMatchingRules methods which take instances of the > abstract class. > > i'd prefer to go down this route (if possible) since it would not only > preserve backward compatibility but also allow more flexible modifications > to be made in the future. > > - robert Well, I just want to note that the original reason I raised the possibility of returning ListIterator for matches was to resolve a problem I had with implementing a Plugins module. I have since had an "epiphany" :-) and have found a promising solution to my problem that hopefully will not require any change to the way Digester works. So from my point of view, I hopefully don't *need* any change to Digester at the moment. FYI: the problem I am struggling with is being able to add rules to the set of "matches" for a particular element after Digester's startElement method has begun iterating over the set of matching rules. eg given that pattern "foo/bar" matches 2 rules: a PluginCreateRule, and a SetNextRule, when the PluginCreateRule fires, new rules such as a SetPropertiesRule may need to be added to the rules associated with that same "foo/bar" pattern. The possible solution I have come up with is to *not* add rules matching the current pattern to the Digester, but instead have the PluginCreateRule object record these rules, and fire them from its begin(), body() and end() methods. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
