Support any types of objects about cardinalityestimation HOT 2 CLOSED

Thought a bit about this, seems to me that keeping the default implementation is important for ease of use. A fully generic version would be nice as well, but not very useful IMO (I could be wrong about that, keeping this discussion open).

My reasoning:

1. Objects that need CardinalityEstimation-based counting tend to have IDs with convenient types - string, long etc. That means developers can use the default implementation with code which is almost as pretty as counting the objects themselves, which allowing CardinalityEstimator to keep things simple.
2. In order to count objects of type T, there needs to be a consistent way to produce a (preferably 64-bit) hash code for them. The hash function must be consistent across different instances of the CardinalityEstimator for them to share state (merging), so that burden is on the developer anyway. I'd prefer the code to make that immediately obvious to the developer.
3. For developers who want a fully generic version, it's not hard to wrap CardinalityEstimator with a wrapper. Most developers would have the current, simpler code to work with.

If it turns out I'm a minority opinion on this, I'll reconsider. Feel free to comment.
-Oron

from cardinalityestimation.

No one seems to have requested this, closing. Feel free to contact me if you wish to reopen.

from cardinalityestimation.