Add `__hash__` and `__eq__` functionality to all classes
Closed this issue · 4 comments
It would be nice to be able to use ==, != and hash operators with the objects in this library. In order to do this, we need to add some hidden methods to each of the geometry classes. A sample of these methods can be found here:
https://github.com/ladybug-tools/honeybee-energy/blob/master/honeybee_energy/material/opaque.py#L513-L525
It's just that, for the __key, we should use whatever properties make the object unique.
Hi, I started with this process of adding the a __key(), hash(), eq(), and ne() functions to all classes.
So far I have done it for Location, STAT, Sunpath, Sun, and Wea classes, and adding unit tests to verify this functionality. One thing to consider is that for some classes, if an object is part of the keys, you need to evaluate the keys as strings.
This would be my first contribution to this project. I have not finished it, but I am wondering if I should submit a PR for the work I have so far. At any rate, I would love to know how to proceed here, and happy to help.
Thank you for starting to tackle this @javier123454321 . As a general guideline, I would recommend starting with simpler classes like Location, AnalysisPeriod, Color, etc. The == operator will be most helpful on these simpler classes and, as you can can already tell, implementing the operators on complex objects like Wea or STAT presents some issues.
To clarify further, evaluating the sub-objects as strings is NOT the correct way to implement the operators when the properties of an object are other objects. The string representation of an object usually doesn't include everything that is needed define that object. Instead, the correct way to implement it is by hashing the sub-objects as you see here on the DDY class:
https://github.com/ladybug-tools/ladybug/blob/master/ladybug/ddy.py#L200
This requires you to have actually implemented a __hash__ operator on these sub-objects, hence, why I said that it's better to start with simple objects and work your way up to the complex ones. I'd recommend sending a PR that is just for a few simple objects first. Then, we can verify that those operators are correct, merge that in, and you can use them to write the operators for more complex classes.
It makes sense to tackle it through hashes rather than the string version of the keys. I sent in a small pr just tackling analysisperiod. If this is a go, I'll do more classes in this way.
I think we can call this one pretty much done. We have everything needed to check the equality of data collections, which is the main use case.