Declared Type vs Actual Type

[richriley]

Hi, I'm facing a problem where I would like to compare the properties in the actual run time type of an object, as opposed to the declared type of the object. For example, the declared type might be Human, but the run time time Man, which extends Human. As far as I can tell the compare method only considers the attributes in the declared type, not the run time type. Is there a way to make it consider the run time type's attributes as well?

Really impressed with this library.. just need to get this last step working if possible.

Thanks,
Rich.

[SQiShER]

Hi Rich,

I'll look into it over the weekend. I think I understand what you mean, but it would help me a lot, if you could provide a small code example (or even better: a failing unit test) that makes the problem very clear. This way we can make sure that I fix/improve the right thing. ;-)

A great way to do this would be to fork this repository and send me a pull request with your sample code or unit test. Just throw it somewhere in src/test/java. I'll handle the rest.

In case I'm asking too much of you or you don't have time to do it, don't worry. I'll try to fix it anyway. It would just speed things up a little!

Cheers,
Daniel

[richriley]

I'm a bit limited on what I can do on this computer. But here are the classes that I've been playing with:

import de.danielbechler.diff.ObjectDiffer;
import de.danielbechler.diff.ObjectDifferFactory;
import de.danielbechler.diff.node.Node;
import de.danielbechler.diff.visitor.Visit;

public class MainApp {

/**
 * @param args
 */
public static void main(final String[] args) {
    final ObjectDiffer objectDiffer = ObjectDifferFactory.getInstance();

    final TopHat hat1 = new TopHat(1, 10);
    final TopHat hat2 = new TopHat(2, 20);

    final Person p1 = new Person(hat1);
    final Person p2 = new Person(hat2);

    final Node root = objectDiffer.compare(p1, p2);

    root.visit(new Node.Visitor() {
        @Override
        public void accept(final Node node, final Visit visit) {
            System.out.print(node.getPropertyPath() + " :: ");
            System.out.print(node.canonicalGet(p1));
            System.out.print(" -> ");
            System.out.print(node.canonicalGet(p2));
            System.out.println();
        }
    });

}

}

and

public class Person {

private Hat hat;

public Person(final Hat hat) {
    super();
    this.hat = hat;
}

public Hat getHat() {
    return hat;
}

public void setHat(final Hat hat) {
    this.hat = hat;
}

}

and

public class Hat {
int size;

public Hat() {
    super();
}

public Hat(final int size) {
    super();
    this.size = size;
}

public int getSize() {
    return size;
}

public void setSize(final int size) {
    this.size = size;
}
}

and

public class TopHat extends Hat {
private int height;

public TopHat() {
    super();
}

public TopHat(final int height, final int size) {
    super(size);
    this.height = height;
}

public int getHeight() {
    return height;
}

public void setHeight(final int height) {
    this.height = height;
}
}

I get the following output:

/ :: Person@246fee3a -> Person@30813486
/hat :: TopHat@2cf889c8 -> TopHat@711dc088
/hat/size :: 10 -> 20

But I need the hat/height to be included in the comparison as well. About an hour ago I thought changing the type Hat in Person to TopHat would mean that both 'size' and 'height' were compared. However now I can't seem to get that to work either (though it's Friday and I've been staring at this screen for over 8 hours so I'm probably doing something wrong). Anyway, the behavior I require is that I need both the attributes in the parent class (Hat) and the child class (TopHat) to be compared. Please let me know if anything is not clear.

Thanks for your help and quick response.
Rich.

[SQiShER]

This helped a lot! Thanks!

I think I found a pretty good way to determine the runtime type without sacrificing simplicity. The biggest problem was to deal with different runtime types in the base and the working version, since the library requires the property accessor methods to be present in both versions. Otherwise it wouldn't be able to properly handle read and write access. So now it does its best to determine the most specific shared type between the base and working versions.

A quick look at the specification should make this a little bit easier to understand:

    expect:
    Classes.mostSpecificSharedType(types) == expectedResult

    where:
    types                                     || expectedResult
    [TreeMap, TreeMap]                        || TreeMap
    [ConcurrentSkipListMap, TreeMap]          || AbstractMap
    [ConcurrentSkipListMap, TreeMap, HashMap] || AbstractMap
    [ArrayList, AbstractList]                 || AbstractList
    [CharSequence, String]                    || CharSequence
    [Serializable, Serializable]              || Serializable
    [String, Map, Date]                       || null

You can give it a try by checking out the master branch. Functionally it's already fully implemented. But I also want to make this behavior configurable and add some more tests, so I won't release a new version until that's done.

I hope this helps! Let me know if this solves your problem.

[SQiShER]

The more I think about it, the less I think this needs to be configurable, as the new behavior is actually consistent with the way collections and maps are handled. So theoretically it should be all done. For your convenience, I deployed a snapshot release of the current master branch here. Give it a spin. If it works for you, I'll release a new version.

[richriley]

Hey that's really great work. I've just tried it out on a couple of examples I was playing with last week and its behaving exactly as I expected. Thanks very much for your quick response to this.

I should be using this library a fair bit over the next 12 months and will give you feedback if we discover any unusual behavior or have any suggestions for future versions.

Thanks again.

[mjg123]

I was confused why the most specific type of Map, String and Date should be null rather than Object - but having checked it with Object references pointing to specific objects it works as expected. Look forward to using it.

[SQiShER]

@mjg123 String, Map and Date don't share any base types. That's why the method simply returns null. The object differ will then try to fall back to the declared type of the property (if available)

[SQiShER]

@richriley Great, happy to hear that! I'll try to release a new version tonight, so you don't have to stick with the snapshot for too long. Looking forward to your feedback!