You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/07/29 08:58:05 UTC
Semantic bug in Framework?
Gang,
Since I am digging in Framework, I also stumbled upon another problem. Either
it is a semantic bug in the intentions, or a bug in the
ConfigurationUtils.equals() method.
The problem is highlighted in an added testcase, which now fails in Framework
implementation.
It goes something like this;
The two configurations
Configuration a =
<a>
<b>1</b>
<b>2</b>
</a>
and
Configuration b =
<a>
<b>2</b>
<b>1</b>
</a>
then
a.equals( b ) --> TRUE
It is not specified in the Javadocs of Configuration, but it is said in
Javadocs of DefaultConfiguration that getChild( String element ), will return
the FIRST child.
SO;
String v1 = a.getChild( "b" ).getValue();
String v2 = b.getChild( "b" ).getValue();
return v1.equals( v2 );
evaluates to FALSE !!!!
In which case the two Configurations can NOT be considered equal.
I can imagine this is quite a headache, and the only way out as I see it, is
that Configurations must be same in order of its children as well, to be
considered equal.
Furthermore, the current equals() implementation is very slow for large
configurations, as it does at worst O(n!) iterations through the tree.
What are we going to do about this?
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Semantic bug in Framework?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 29 July 2004 16:31, Leo Sutic wrote:
> Reasoning goes like this:
>
> getChildren
> public Configuration[] getChildren()
> Return an Array of Configuration elements containing all node children.
> The array order will reflect the order in the source config file.
>
> Since order matters in the translation from source file to
> Configuration, we must conclude that order is significant. Otherwise,
> if you have code that is based on the assumption that the node order
> == order in config file, then that code will not consider two
> configurations equal, even if equals() does.
Agree.
And in fact, the equals() implementation along these lines are a lot simpler.
Just do an equals() on each of the members in the instances.
Attributes are internally stored in HashMap, which is not order sensitive,
whereas children are stored in an ArrayList, which is order-sensitive.
Hence, I have now committed the change to the subversion repo, together with a
supporting testcase.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Semantic bug in Framework?
Posted by Alex Karasulu <ao...@bellsouth.net>.
On Thu, 2004-07-29 at 03:58, Niclas Hedhman wrote:
> On Thursday 29 July 2004 15:53, Leo Sutic wrote:
> > That's a bug in ConfigurationUtils.equals.
> >
> > Child order ***is*** significant.
Absolutely order should be relavent. Some components depend on the
ordering of elements within a configuration. Hence equals should
consider element order.
> I was hoping for that, but since someone spent a lot of time taking order out
> of the equation, I suspected the worst.
>
> Since you seems very confident, I'll start with re-implementing a proper
> equals() / hashCode() for DefaultConfiguration.
+1
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Semantic bug in Framework?
Posted by Alex Karasulu <ao...@bellsouth.net>.
On Thu, 2004-07-29 at 03:58, Niclas Hedhman wrote:
> On Thursday 29 July 2004 15:53, Leo Sutic wrote:
> > That's a bug in ConfigurationUtils.equals.
> >
> > Child order ***is*** significant.
Absolutely order should be relavent. Some components depend on the
ordering of elements within a configuration. Hence equals should
consider element order.
> I was hoping for that, but since someone spent a lot of time taking order out
> of the equation, I suspected the worst.
>
> Since you seems very confident, I'll start with re-implementing a proper
> equals() / hashCode() for DefaultConfiguration.
+1
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Semantic bug in Framework?
Posted by Leo Sutic <le...@gmail.com>.
On Thu, 29 Jul 2004 15:58:08 +0800, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Thursday 29 July 2004 15:53, Leo Sutic wrote:
> > That's a bug in ConfigurationUtils.equals.
> >
> > Child order ***is*** significant.
>
> I was hoping for that, but since someone spent a lot of time taking order out
> of the equation, I suspected the worst.
>
> Since you seems very confident, I'll start with re-implementing a proper
> equals() / hashCode() for DefaultConfiguration.
Reasoning goes like this:
getChildren
public Configuration[] getChildren()
Return an Array of Configuration elements containing all node children.
The array order will reflect the order in the source config file.
Since order matters in the translation from source file to
Configuration, we must conclude that order is significant. Otherwise,
if you have code that is based on the assumption that the node order
== order in config file, then that code will not consider two
configurations equal, even if equals() does.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Semantic bug in Framework?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 29 July 2004 15:53, Leo Sutic wrote:
> That's a bug in ConfigurationUtils.equals.
>
> Child order ***is*** significant.
I was hoping for that, but since someone spent a lot of time taking order out
of the equation, I suspected the worst.
Since you seems very confident, I'll start with re-implementing a proper
equals() / hashCode() for DefaultConfiguration.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Semantic bug in Framework?
Posted by Leo Sutic <le...@gmail.com>.
That's a bug in ConfigurationUtils.equals.
Child order ***is*** significant.
/LS
On Thu, 29 Jul 2004 15:03:38 +0800, Niclas Hedhman <ni...@hedhman.org> wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Semantic bug in Framework?
Posted by Niclas Hedhman <ni...@hedhman.org>.
Please excuse the slightly wrong code-level errors in the sample below. The
<a></a> needs to be the root level for it to make sense... I am sure you get
the message any way.
Cheers
Niclas
On Thursday 29 July 2004 14:58, Niclas Hedhman wrote:
> Gang,
>
> Since I am digging in Framework, I also stumbled upon another problem.
> Either it is a semantic bug in the intentions, or a bug in the
> ConfigurationUtils.equals() method.
>
> The problem is highlighted in an added testcase, which now fails in
> Framework implementation.
>
> It goes something like this;
>
> The two configurations
> Configuration a =
> <a>
> <b>1</b>
> <b>2</b>
> </a>
>
> and
>
> Configuration b =
> <a>
> <b>2</b>
> <b>1</b>
> </a>
>
> then
> a.equals( b ) --> TRUE
>
> It is not specified in the Javadocs of Configuration, but it is said in
> Javadocs of DefaultConfiguration that getChild( String element ), will
> return the FIRST child.
>
> SO;
> String v1 = a.getChild( "b" ).getValue();
> String v2 = b.getChild( "b" ).getValue();
> return v1.equals( v2 );
>
> evaluates to FALSE !!!!
> In which case the two Configurations can NOT be considered equal.
>
> I can imagine this is quite a headache, and the only way out as I see it,
> is that Configurations must be same in order of its children as well, to be
> considered equal.
>
> Furthermore, the current equals() implementation is very slow for large
> configurations, as it does at worst O(n!) iterations through the tree.
>
> What are we going to do about this?
>
>
> Cheers
> Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Semantic bug in Framework?
Posted by Niclas Hedhman <ni...@hedhman.org>.
Please excuse the slightly wrong code-level errors in the sample below. The
<a></a> needs to be the root level for it to make sense... I am sure you get
the message any way.
Cheers
Niclas
On Thursday 29 July 2004 14:58, Niclas Hedhman wrote:
> Gang,
>
> Since I am digging in Framework, I also stumbled upon another problem.
> Either it is a semantic bug in the intentions, or a bug in the
> ConfigurationUtils.equals() method.
>
> The problem is highlighted in an added testcase, which now fails in
> Framework implementation.
>
> It goes something like this;
>
> The two configurations
> Configuration a =
> <a>
> <b>1</b>
> <b>2</b>
> </a>
>
> and
>
> Configuration b =
> <a>
> <b>2</b>
> <b>1</b>
> </a>
>
> then
> a.equals( b ) --> TRUE
>
> It is not specified in the Javadocs of Configuration, but it is said in
> Javadocs of DefaultConfiguration that getChild( String element ), will
> return the FIRST child.
>
> SO;
> String v1 = a.getChild( "b" ).getValue();
> String v2 = b.getChild( "b" ).getValue();
> return v1.equals( v2 );
>
> evaluates to FALSE !!!!
> In which case the two Configurations can NOT be considered equal.
>
> I can imagine this is quite a headache, and the only way out as I see it,
> is that Configurations must be same in order of its children as well, to be
> considered equal.
>
> Furthermore, the current equals() implementation is very slow for large
> configurations, as it does at worst O(n!) iterations through the tree.
>
> What are we going to do about this?
>
>
> Cheers
> Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/