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

Add isEmpty() and empty() methods #99

Closed
FredLackeyOfficial opened this Issue Jan 19, 2015 · 6 comments

Comments

Projects
None yet
5 participants
@FredLackeyOfficial

FredLackeyOfficial commented Jan 19, 2015

Please add a method to generate an empty UUID ('00000000-0000-0000-0000-000000000000') as well as checking if a supplied value is an empty UUID.

@broofa

This comment has been minimized.

Collaborator

broofa commented Jan 19, 2015

Empty ID is not a valid RFC ID. (implies version = 0, which isn't part of the spec.) What use case do you have for this?

@tracker1

This comment has been minimized.

tracker1 commented Jan 19, 2015

.Net in particular is strongly typed, and .Net (C#) will default a Guid/UUID to the above empty value. When interacting with data generated from such a source, you'll often need this check to see if a reference or default value is present.

It may be of value to add this, even if it's outside of spec.

@broofa

This comment has been minimized.

Collaborator

broofa commented Jan 19, 2015

Is there more to the implementions of isEmpty() (return id === '00000000-0000-0000-0000-000000000000) and empty() (return '00000000-0000-0000-0000-000000000000';) than I imagine? If not, it's not clear how much added value there is in this. I guess I could see adding these if these were useful within this module but currently they aren't.

@tracker1

This comment has been minimized.

tracker1 commented Jan 21, 2015

I would think that maybe defining an "empty" constant/property on the export might be useful... other than that, don't know if making it a function is really useful at all..

var uuid = require('uuid');
...
  if (inputId === uuid.empty) {
    ...

Something like that... wrapping that in methods is probably not worth the effort.

@FredLackeyOfficial

This comment has been minimized.

FredLackeyOfficial commented Jan 21, 2015

First off, thanks for even considering the addition.

As for the use of a constant, I agree. While other teams may use a method to generate an empty, this deviates from [I think] every OO language. An UUID has no special functional abilities. It's an identifier and, therefore, a constant is clearly the right choice (regardless of the syntax I originally supplied).

From an LOB standpoint, I believe standardizing on an "empty" constant (i.e. ) helps simplify validation and increase data integrity. Other than the difference they may be parsed from a larger number of formats, dates are a good example of this. It is clear what value is or is not a Date, regardless how it is stored. Not providing a standard "empty" value moves the burden to the developer and invites an unlimited number of variations. Is an empty string valid but empty OR simply invalid? What about nulls? It is a common need to prove that a value has been confirmed but is nothing. The "empty" constant accomplishes this.

As for the isEmpty() operation and deviating from the spec, maybe an optional parameter may be supplied to indicate IF an empty is to be considered "valid". This would allow the basic operation to adhere to the spec while still allowing the "empty" constant to be standardized.

Just my $0.01552771662.

@DanielCaspers

This comment has been minimized.

DanielCaspers commented May 3, 2016

+1. Also, thanks for considering! Having an empty constant would be nice. I do respect the decision to not add it (and close this ticket), however, since it is outside of RFC spec. The reason I would like it is the same as @tracker1; I need to work with a REST interface with a C# (.Net) back end.

For now, I'm happy using the earlier deprecated 'Guid' package though.

@broofa broofa added wontfix and removed wontfix labels Jun 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment