Simon Kitching wrote:
Hi,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).
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 ;-]
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
