-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose the reference UUID generator constructor #42
Conversation
generator.go
Outdated
// address for all the future UUIDs generated by it. If you'd like to switch the | ||
// MAC address being used, you'll need to create a new generator using this | ||
// function. | ||
func NewGenHWAF(hwaf HWAddrFunc) *Gen { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll be the first to admit that I'm not sold on this function name. Couldn't think of anything better in the moment, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally tend to name things with With
in such cases: NewGenWithHWAF
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds better to me.
Pull Request Test Coverage Report for Build 127
💛 - Coveralls |
This change exposes the reference UUID generator in the package, so that consumers can create a new instance and make use of it. This is being done so that consumers can provide their own Hardware Address generation function, in case they want to randomize the MAC address as to not expose it. This works by now exposing the `rfc4122Generator` type as `Gen`, and adding constructor functions that scaffold the generator appropriately. The tests were also enhanced to confirm that the `HWAddrFunc` we provide is indeed being invoked. Fixes #41 Signed-off-by: Tim Heckman <t@heckman.io>
e34074b
to
97e53ed
Compare
Are we sure we even want a So existing calls could be replaced with:
and if the user wants an alternate address:
|
@jadr2ddude having it as a factory function abstracts UUID client from its constructor: you as a client may generate new UUIDs and be isolated from making a decision on how and where from the hardware address is obtained from. |
@jadr2ddude I am assuming less than 10% of users will make use of this functionality, and so I don't think it makes sense to require the 90% to consider their hardware address as part of the API they interact with. For the majority we should silently do what they expect. We can then expose knobs that allow the minority to have the control they want. |
Expose the reference UUID generator constructor Signed-off-by: Tim Heckman <t@heckman.io>
This change exposes the reference UUID generator in the package, so that
consumers can create a new instance and make use of it. This is being done so
that consumers can provide their own Hardware Address generation function, in
case they want to randomize the MAC address as to not expose it.
This works by now exposing the
rfc4122Generator
type asGen
, and addingconstructor functions that scaffold the generator appropriately. The tests were
also enhanced to confirm that the
HWAddrFunc
we provide is indeed beinginvoked.
Fixes #41
Signed-off-by: Tim Heckman t@heckman.io