Jesse Eichar wrote:
Ok good points. But in order to have a useful interface I think we
will have to specify the equals methods. I believe, but you can
correct me if I'm wrong, that .equals is frequently used.
Yep - and we do implement the mojo of Filter.ALL and Filter.NONE to be
okay..
But y
Ok good points. But in order to have a useful interface I think we will
have to specify the equals methods. I believe, but you can correct me
if I'm wrong, that .equals is frequently used.
Jesse
Martin Desruisseaux wrote:
Jesse Eichar a écrit :
I agree with you for the most part Martin.
Jesse Eichar a écrit :
I agree with you for the most part Martin. But if you look at some
implementations of equals, such as java.util.AbstractList, you will find
that it checks only that the object implements the interface and only
uses public methods to determine equality.
Yes, but they ca
Jesse Eichar wrote:
I agree with you for the most part Martin. But if you look at some
implementations of equals, such as java.util.AbstractList, you will
find that it checks only that the object implements the interface and
only uses public methods to determine equality. Because only the
in
I agree with you for the most part Martin. But if you look at some
implementations of equals, such as java.util.AbstractList, you will find
that it checks only that the object implements the interface and only
uses public methods to determine equality. Because only the interface
methods are u
Justin Deoliveira a écrit :
I had a look at some of the style model objects implementations. I
notice the equals() methods all look for an instance of the same Impl
class, and not of the actual interface. For example FillImpl:
[...snip...]
Isn't this a problem? If someone comes along with th
Justin Deoliveira wrote:
I had a look at some of the style model objects implementations. I
notice the equals() methods all look for an instance of the same Impl
class, and not of the actual interface. For example FillImpl:
public boolean equals(Object oth) {
if (this == oth) {
I had a look at some of the style model objects implementations. I
notice the equals() methods all look for an instance of the same Impl
class, and not of the actual interface. For example FillImpl:
public boolean equals(Object oth) {
if (this == oth) {
return true;
Jody Garnett wrote:
I do not see facilities in the toolkit for duplicating Filter /
Expression / Style.
I am finding some errors in the test cases as bad assumptions are made
about Symbolizer reuse
Found a scary example of Styles being cloned in a test case:
Style clone = (Style) ((Clonea
I do not see facilities in the toolkit for duplicating Filter /
Expression / Style.
I am finding some errors in the test cases as bad assumptions are made
about Symbolizer reuse
More hack lest chat ...
Jody
---
This SF.net email is spo
10 matches
Mail list logo
