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

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