Support for functional equals

[leolux]

Persistable json objects usually carry some kind of technical identifier with them. Is there some way to compare two json objects without technical properties?

For example:
{"id":"1","type":"car","model":"Ferrari","color":"red"}
{"id":"2","type":"car","model":"Ferrari","color":"red"}

Both objects represent the same car (functional equality) but they are not equal/identical because of their different IDs. If there would be a way to exclude/ignore certain properties during the equals operation would be a great feature. Maybe the API could look something like car1.functionalEquals(car2,"id"); whereas the last argument is a variable parameter list. Or maybe it would be better to mark technical properties within the interal data structure of mjson itself for beeing able to handle nested/more complex objects. This would require some API for marking properties as beeing "excluded" from the functional equals comparison.

[bolerio]

Is this something that you would see as a separate method or as modifying the behavior of the standard Java Object.equals method?

[leolux]

Both ways would be possible. But I think there are good reasons against modifying the behaviour of the standard equals method. Especially when dealing with abstracted objects like in this case the json object. Some reasons against a modification of the equals are

• additional obscurity when equals() would have two different kind of behaviours
• opinionated implementation of equals()
• touching the contract between hashCode() and equals()
• violation of the Open/closed principle (functions should be open for extensions but closed for modifications)
• violation of the minimal suprise principle (introduces additional complexity)
• violation of the dependency inversion principle (APIs should not depend on details but details on APIs)
• violation of the speration of concerns principle (different tasks should be represented in different elements)

Therefore I would prefer to implement this functionality in a seperate method making its behaviour clearly understandable in the Javadoc of the new signature.

[bolerio]

Ok, then if it's a separate function, does it really have to be part of the library?

I'm currently setting up a separate project, called mjson-ext, which would be in a separate repo and encompass several extra modules, e.g. for Java Beans serialization, for MongoDB, interfacing with JDK's embedded browser JSObject and perhaps that could contain a utilities module with generic functions like this. Maybe something like this should go into that separate project.

[leolux]

Sounds great!
I agree that a seperate project would be the best solution and I think it should be possible without touching the core library. However I don't know any details about the concept of "extra modules" for this library or the details about the concept of functional equals either. This means that if the API of the library would not be sufficient for the implenentation of the new function then yes, there could be a need for extending the core library. But this should be avoided of course.

Btw, I want to say that the library is more powerful than any other library I have tested so far and it deserves much more than 9 stars in my eyes. I am looking forward to any links and plans about the upcomping mjson-ext repo.

As we agreed on moving such a functionality into a seperate project I can close the issue here.

[bolerio]

Ok, thanks for the kind words! I do need to find more time to work on it and have some extras. I guess one of the reasons some of the other libraries are more popular (besides getting there first) would be that they offer more functionality like Java bean serialization etc.