You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that the ConsulFactory implementation has equals and hashCode even though it doesn't seem like you would ever need to compare two ConsulFactory objects. I do not plan to add these new properties to the existing equals and hashCode methods, and after seeing these methods am considering several future changes:
Split ConsulFactory into separate classes, one that contains only configuration, and one for taking that configuration and building the Consul instance.
Remove equals and hashCode from the factory class
Maybe make the configuration class a "value" or "data" class, where it would (maybe) make more sense to have equals and hashCode
Change all the Optional handling across the library, i.e. don't declare fields as Optional and don't pass Optional to methods, etc.
This would be a somewhat large design change, since it would change public APIs. Then again, since we have not released this yet under kiwiproject, we don't need to adhere to the original APIs, at the cost of a little migration pain (in our own services).
Note that the
ConsulFactory
implementation hasequals
andhashCode
even though it doesn't seem like you would ever need to compare twoConsulFactory
objects. I do not plan to add these new properties to the existingequals
andhashCode
methods, and after seeing these methods am considering several future changes:ConsulFactory
into separate classes, one that contains only configuration, and one for taking that configuration and building theConsul
instance.equals
andhashCode
from the factory classequals
andhashCode
Optional
handling across the library, i.e. don't declare fields asOptional
and don't passOptional
to methods, etc.This would be a somewhat large design change, since it would change public APIs. Then again, since we have not released this yet under kiwiproject, we don't need to adhere to the original APIs, at the cost of a little migration pain (in our own services).
Originally posted by @sleberknight in #23 (comment)
The text was updated successfully, but these errors were encountered: