[digester] Proposal to change Rules interface to return ListIterator for matches

[Simon Kitching <si...@ecnetwork.co.nz>]

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 ;-]

An iterator-based API allows optimisations, like returning an iterator
or FilterIterator over an internal data structure maintained by the
Rules object rather than having to build a new list. And in the Plugins
module case (which I am now working on), it allows me to return a
CursorableLinkedList.Cursor object (which doesn't care about concurrent
modification of the underlying list).

If it is considered desirable to provide support for third-party Rules
implementations, then a stub method could be added to AbstractRulesImpl
and RulesBase as a migration path; any third-party class derived from
these base classes would not need to be changed.

  public ListIterator iterator(uri, pattern) {
    return match(uri, pattern).listIterator();
  }


I've done the modifications locally, and only about 2 dozen lines of
code need changing to completely swap over to a ListIterator-based API.
By that, I mean changing Digester so that it only uses ListIterators to
walk the matching rules, and adding the ListIterator-returning method to
all Rules implementations.

The test case code is a bit nastier - lots of test cases check the size
of the matches list. Still, that is only a problem if the match methods
are actually removed, rather than just deprecated.

Any opinions? Feel free to shoot me down in flames if I have missed a
critical use case that requires a List to be returned :-)


Regards,

Simon

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Monday, September 29, 2003, at 11:29 PM, Simon Kitching wrote:

> On Mon, 2003-09-29 at 22:14, robert burrell donkin wrote:
>>>
>>> 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.
>>
>> still, you original reasoning still seems pretty valid. it seems to me
>> that often when a design seems too inflexible in a particular direction,
>> it's better to fix it immediately rather than wait until solutions to
>> other similar issues are also blocked by this inflexibility.
>
> Yes, I agree. However my spare energy is going into knocking Plugins
> into shape at the moment, so I can't really follow this up at the
> moment.

IMHO this is a thinking problem rather than a doing problem. it should be 
easy to do but we need to work out whether it's worth doing,

> Actually, one solution that really appeals to me is to pass a Functor to
> the Rules engine which is applied to each matching rule. But maybe
> that's just because I am learning Ruby at the moment :-)

i think that this probably depends on the nature of the patterns you're 
trying to match. functors are certainly an elegant way to solve some kinds 
of problem. if you haven't taken a look already, rodney has a functor 
component in the sandbox.

>>> 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.
>>
>> IMHO adding rules dynamically is best avoid where possible. experience
>> with betwixt has shown that it's difficult to mix in custom rules when
>> other rules add rules dynamically. (the main issue is that preserving the
>> order.)
>>
>> the latest solution being using on betwixt is that a single rule will be
>> used and then delegation used to manage dynamic mappings. it sounds like
>> you've managed to hit upon what is (IMHO) the best way to solve this
>> problem more quickly than we did for betwixt.  i'd support the creation 
>> of
>> an abstract delegator rule that allows others to easily understand and 
>> use
>> this pattern if you go down this route.
>
> Hmm .. I suspected that I should learn Betwixt, and that I would be in
> danger of reinventing the wheel if I didn't. Alas, just not enough time
> in the day!

learning betwixt is probably not a good idea (at the moment). it's badly 
factored and is in the process of being taken apart and reassembled. but 
it's worth learning the lessons discovered during development.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Monday, September 29, 2003, at 11:29 PM, Simon Kitching wrote:

> On Mon, 2003-09-29 at 22:14, robert burrell donkin wrote:
>>>
>>> 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.
>>
>> still, you original reasoning still seems pretty valid. it seems to me
>> that often when a design seems too inflexible in a particular direction,
>> it's better to fix it immediately rather than wait until solutions to
>> other similar issues are also blocked by this inflexibility.
>
> Yes, I agree. However my spare energy is going into knocking Plugins
> into shape at the moment, so I can't really follow this up at the
> moment.

IMHO this is a thinking problem rather than a doing problem. it should be 
easy to do but we need to work out whether it's worth doing,

> Actually, one solution that really appeals to me is to pass a Functor to
> the Rules engine which is applied to each matching rule. But maybe
> that's just because I am learning Ruby at the moment :-)

i think that this probably depends on the nature of the patterns you're 
trying to match. functors are certainly an elegant way to solve some kinds 
of problem. if you haven't taken a look already, rodney has a functor 
component in the sandbox.

>>> 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.
>>
>> IMHO adding rules dynamically is best avoid where possible. experience
>> with betwixt has shown that it's difficult to mix in custom rules when
>> other rules add rules dynamically. (the main issue is that preserving the
>> order.)
>>
>> the latest solution being using on betwixt is that a single rule will be
>> used and then delegation used to manage dynamic mappings. it sounds like
>> you've managed to hit upon what is (IMHO) the best way to solve this
>> problem more quickly than we did for betwixt.  i'd support the creation 
>> of
>> an abstract delegator rule that allows others to easily understand and 
>> use
>> this pattern if you go down this route.
>
> Hmm .. I suspected that I should learn Betwixt, and that I would be in
> danger of reinventing the wheel if I didn't. Alas, just not enough time
> in the day!

learning betwixt is probably not a good idea (at the moment). it's badly 
factored and is in the process of being taken apart and reassembled. but 
it's worth learning the lessons discovered during development.

- robert

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[Simon Kitching <si...@ecnetwork.co.nz>]

On Mon, 2003-09-29 at 22:14, robert burrell donkin wrote:
> >
> > 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.
> 
> still, you original reasoning still seems pretty valid. it seems to me 
> that often when a design seems too inflexible in a particular direction, 
> it's better to fix it immediately rather than wait until solutions to 
> other similar issues are also blocked by this inflexibility.

Yes, I agree. However my spare energy is going into knocking Plugins
into shape at the moment, so I can't really follow this up at the
moment.

Actually, one solution that really appeals to me is to pass a Functor to
the Rules engine which is applied to each matching rule. But maybe
that's just because I am learning Ruby 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.
> 
> IMHO adding rules dynamically is best avoid where possible. experience 
> with betwixt has shown that it's difficult to mix in custom rules when 
> other rules add rules dynamically. (the main issue is that preserving the 
> order.)
> 
> the latest solution being using on betwixt is that a single rule will be 
> used and then delegation used to manage dynamic mappings. it sounds like 
> you've managed to hit upon what is (IMHO) the best way to solve this 
> problem more quickly than we did for betwixt.  i'd support the creation of 
> an abstract delegator rule that allows others to easily understand and use 
> this pattern if you go down this route.

Hmm .. I suspected that I should learn Betwixt, and that I would be in
danger of reinventing the wheel if I didn't. Alas, just not enough time
in the day!

Anyway, good to know I'm following a trodden path.

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[Simon Kitching <si...@ecnetwork.co.nz>]

On Mon, 2003-09-29 at 22:14, robert burrell donkin wrote:
> >
> > 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.
> 
> still, you original reasoning still seems pretty valid. it seems to me 
> that often when a design seems too inflexible in a particular direction, 
> it's better to fix it immediately rather than wait until solutions to 
> other similar issues are also blocked by this inflexibility.

Yes, I agree. However my spare energy is going into knocking Plugins
into shape at the moment, so I can't really follow this up at the
moment.

Actually, one solution that really appeals to me is to pass a Functor to
the Rules engine which is applied to each matching rule. But maybe
that's just because I am learning Ruby 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.
> 
> IMHO adding rules dynamically is best avoid where possible. experience 
> with betwixt has shown that it's difficult to mix in custom rules when 
> other rules add rules dynamically. (the main issue is that preserving the 
> order.)
> 
> the latest solution being using on betwixt is that a single rule will be 
> used and then delegation used to manage dynamic mappings. it sounds like 
> you've managed to hit upon what is (IMHO) the best way to solve this 
> problem more quickly than we did for betwixt.  i'd support the creation of 
> an abstract delegator rule that allows others to easily understand and use 
> this pattern if you go down this route.

Hmm .. I suspected that I should learn Betwixt, and that I would be in
danger of reinventing the wheel if I didn't. Alas, just not enough time
in the day!

Anyway, good to know I'm following a trodden path.

Simon

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Sunday, September 28, 2003, at 11:38 PM, Simon Kitching wrote:

> 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.

still, you original reasoning still seems pretty valid. it seems to me 
that often when a design seems too inflexible in a particular direction, 
it's better to fix it immediately rather than wait until solutions to 
other similar issues are also blocked by this inflexibility.

> 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.

IMHO adding rules dynamically is best avoid where possible. experience 
with betwixt has shown that it's difficult to mix in custom rules when 
other rules add rules dynamically. (the main issue is that preserving the 
order.)

the latest solution being using on betwixt is that a single rule will be 
used and then delegation used to manage dynamic mappings. it sounds like 
you've managed to hit upon what is (IMHO) the best way to solve this 
problem more quickly than we did for betwixt.  i'd support the creation of 
an abstract delegator rule that allows others to easily understand and use 
this pattern if you go down this route.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Sunday, September 28, 2003, at 11:38 PM, Simon Kitching wrote:

> 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.

still, you original reasoning still seems pretty valid. it seems to me 
that often when a design seems too inflexible in a particular direction, 
it's better to fix it immediately rather than wait until solutions to 
other similar issues are also blocked by this inflexibility.

> 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.

IMHO adding rules dynamically is best avoid where possible. experience 
with betwixt has shown that it's difficult to mix in custom rules when 
other rules add rules dynamically. (the main issue is that preserving the 
order.)

the latest solution being using on betwixt is that a single rule will be 
used and then delegation used to manage dynamic mappings. it sounds like 
you've managed to hit upon what is (IMHO) the best way to solve this 
problem more quickly than we did for betwixt.  i'd support the creation of 
an abstract delegator rule that allows others to easily understand and use 
this pattern if you go down this route.

- robert

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[Simon Kitching <si...@ecnetwork.co.nz>]

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

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[Simon Kitching <si...@ecnetwork.co.nz>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[robert burrell donkin <ro...@blueyonder.co.uk>]

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

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

[robert burrell donkin <ro...@blueyonder.co.uk>]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

["Craig R. McClanahan" <cr...@apache.org>]

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.

>An iterator-based API allows optimisations, like returning an iterator
>or FilterIterator over an internal data structure maintained by the
>Rules object rather than having to build a new list. And in the Plugins
>module case (which I am now working on), it allows me to return a
>CursorableLinkedList.Cursor object (which doesn't care about concurrent
>modification of the underlying list).
>
>If it is considered desirable to provide support for third-party Rules
>implementations, then a stub method could be added to AbstractRulesImpl
>and RulesBase as a migration path; any third-party class derived from
>these base classes would not need to be changed.
>
>  public ListIterator iterator(uri, pattern) {
>    return match(uri, pattern).listIterator();
>  }
>
>
>I've done the modifications locally, and only about 2 dozen lines of
>code need changing to completely swap over to a ListIterator-based API.
>By that, I mean changing Digester so that it only uses ListIterators to
>walk the matching rules, and adding the ListIterator-returning method to
>all Rules implementations.
>
>The test case code is a bit nastier - lots of test cases check the size
>of the matches list. Still, that is only a problem if the match methods
>are actually removed, rather than just deprecated.
>
>Any opinions? Feel free to shoot me down in flames if I have missed a
>critical use case that requires a List to be returned :-)
>  
>
I don't know of any.

>
>Regards,
>
>Simon
>
>  
>
Craig

Re: [digester] Proposal to change Rules interface to return ListIterator for matches

["Craig R. McClanahan" <cr...@apache.org>]

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.

>An iterator-based API allows optimisations, like returning an iterator
>or FilterIterator over an internal data structure maintained by the
>Rules object rather than having to build a new list. And in the Plugins
>module case (which I am now working on), it allows me to return a
>CursorableLinkedList.Cursor object (which doesn't care about concurrent
>modification of the underlying list).
>
>If it is considered desirable to provide support for third-party Rules
>implementations, then a stub method could be added to AbstractRulesImpl
>and RulesBase as a migration path; any third-party class derived from
>these base classes would not need to be changed.
>
>  public ListIterator iterator(uri, pattern) {
>    return match(uri, pattern).listIterator();
>  }
>
>
>I've done the modifications locally, and only about 2 dozen lines of
>code need changing to completely swap over to a ListIterator-based API.
>By that, I mean changing Digester so that it only uses ListIterators to
>walk the matching rules, and adding the ListIterator-returning method to
>all Rules implementations.
>
>The test case code is a bit nastier - lots of test cases check the size
>of the matches list. Still, that is only a problem if the match methods
>are actually removed, rather than just deprecated.
>
>Any opinions? Feel free to shoot me down in flames if I have missed a
>critical use case that requires a List to be returned :-)
>  
>
I don't know of any.

>
>Regards,
>
>Simon
>
>  
>
Craig



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org