www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.uuid is ready for review

reply Johannes Pfau <nospam example.com> writes:
Hi,

std.uuid is ready to be reviewed. As far as I know there's nothing
being reviewed right now, so we could start the review as soon as 
a review manager has been found.

About std.uuid (copied from the module documentation):
---------------------
This is a port of boost.uuid from the boost project with some minor
additions and API changes for a more D-like API. A UUID, or Universally
unique identifier, is intended to uniquely identify information in a
distributed environment without significant central coordination. It
can be used to tag objects with very short lifetimes, or to reliably
identify very persistent objects across a network. UUIDs have many
applications. [...]
---------------------

Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html

Note: The code and documentation for shaUUID has already been written,
but until phobos has support for SHA1, that can't be included. The code
is currently commented out in the source file (it's well tested
with some 3rd party SHA1 code), but the documentation for those
functions is included in the API-docs. I think those functions should
be reviewed as well, so that it's possible to add them to phobos with a
simple pull request at a later date.

Note2: std.uuid also need this pull request:
https://github.com/D-Programming-Language/phobos/pull/398
It adds a isRandomNumberGenerator template to detect if a template
parameter is a random-number generator type.
Feb 02 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-02 22:26, Johannes Pfau wrote:

 Hi,

 std.uuid is ready to be reviewed. As far as I know there's nothing
 being reviewed right now, so we could start the review as soon as
 a review manager has been found.

 About std.uuid (copied from the module documentation):
 ---------------------
 This is a port of boost.uuid from the boost project with some minor
 additions and API changes for a more D-like API. A UUID, or Universally
 unique identifier, is intended to uniquely identify information in a
 distributed environment without significant central coordination. It
 can be used to tag objects with very short lifetimes, or to reliably
 identify very persistent objects across a network. UUIDs have many
 applications. [...]
 ---------------------

 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html

 Note: The code and documentation for shaUUID has already been written,
 but until phobos has support for SHA1, that can't be included. The code
 is currently commented out in the source file (it's well tested
 with some 3rd party SHA1 code), but the documentation for those
 functions is included in the API-docs. I think those functions should
 be reviewed as well, so that it's possible to add them to phobos with a
 simple pull request at a later date.

 Note2: std.uuid also need this pull request:
 https://github.com/D-Programming-Language/phobos/pull/398
 It adds a isRandomNumberGenerator template to detect if a template
 parameter is a random-number generator type.


My serialization library Orange was in the review queue before, for a 
pre-review, but nothing happened with that. I you want to review 
std.uuid before I have no problem with that.

-- 
/Jacob Carlborg
Feb 03 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 03 Feb 2012 09:54:32 +0100
schrieb Jacob Carlborg <doob me.com>:


 On 2012-02-02 22:26, Johannes Pfau wrote:

 Hi,

 std.uuid is ready to be reviewed. As far as I know there's nothing
 being reviewed right now, so we could start the review as soon as
 a review manager has been found.

 About std.uuid (copied from the module documentation):
 ---------------------
 This is a port of boost.uuid from the boost project with some minor
 additions and API changes for a more D-like API. A UUID, or
 Universally unique identifier, is intended to uniquely identify
 information in a distributed environment without significant
 central coordination. It can be used to tag objects with very short
 lifetimes, or to reliably identify very persistent objects across a
 network. UUIDs have many applications. [...]
 ---------------------

 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html

 Note: The code and documentation for shaUUID has already been
 written, but until phobos has support for SHA1, that can't be
 included. The code is currently commented out in the source file
 (it's well tested with some 3rd party SHA1 code), but the
 documentation for those functions is included in the API-docs. I
 think those functions should be reviewed as well, so that it's
 possible to add them to phobos with a simple pull request at a
 later date.

 Note2: std.uuid also need this pull request:
 https://github.com/D-Programming-Language/phobos/pull/398
 It adds a isRandomNumberGenerator template to detect if a template
 parameter is a random-number generator type.


 
 My serialization library Orange was in the review queue before, for a 
 pre-review, but nothing happened with that. I you want to review 
 std.uuid before I have no problem with that.
 


I thought orange wasn't 100% ready for review yet, but if it is I don't
mind if it's reviewed first. std.uuid has the benefit that it's small,
simple and ported from boost, so it's kinda 'well-tested' and the
review hopefully won't be very controversial.
Feb 03 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-03 23:18, Johannes Pfau wrote:

 Am Fri, 03 Feb 2012 09:54:32 +0100
 schrieb Jacob Carlborg<doob me.com>:

 My serialization library Orange was in the review queue before, for a
 pre-review, but nothing happened with that. I you want to review
 std.uuid before I have no problem with that.


 I thought orange wasn't 100% ready for review yet, but if it is I don't
 mind if it's reviewed first. std.uuid has the benefit that it's small,
 simple and ported from boost, so it's kinda 'well-tested' and the
 review hopefully won't be very controversial.


It depends on how you see it. I've requested, what I would like to call 
a pre-review. I want to have a regular review on what I have, but with 
the assumption that if it gets approved I will remove all Tango support. 
I don't want to waste time on removing the Tango support if I don't know 
for sure it will be included in Phobos.

-- 
/Jacob Carlborg
Feb 04 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-03 23:18, Johannes Pfau wrote:

 I thought orange wasn't 100% ready for review yet, but if it is I don't
 mind if it's reviewed first. std.uuid has the benefit that it's small,
 simple and ported from boost, so it's kinda 'well-tested' and the
 review hopefully won't be very controversial.


Actually I don't care in what order the modules are reviewed.

-- 
/Jacob Carlborg
Feb 04 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Johannes Pfau wrote:

 Hi,


Hi,

SHA1 and MD5 should work in CTFE now.
Feb 05 2012
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 06.02.2012, 03:44 Uhr, schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:


 Johannes Pfau wrote:

 Hi,


 Hi,

 SHA1 and MD5 should work in CTFE now.


So I could in theory do import("important.binary") and calculate and store  
it's checksums in the executable. You never know when you need this  
feature!
Feb 05 2012
parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Monday, 6 February 2012 at 04:46:16 UTC, Marco Leise wrote:

 So I could in theory do import("important.binary") and 
 calculate and store it's checksums in the executable. You never 
 know when you need this feature!


Hmm, wouldn't doing that also mean that important.binary is also 
included as part of the executable, even though you just want the 
checksum?
Feb 06 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/2/2012 1:26 PM, Johannes Pfau wrote:

 std.uuid is ready to be reviewed. As far as I know there's nothing
 being reviewed right now, so we could start the review as soon as
 a review manager has been found.


I'd like to see a string constant that is a regex for a UUID in its canonical 
form. The user could then simply pass that string to std.regex and pick UUIDs 
out of text.
Feb 05 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 05 Feb 2012 21:48:36 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:


 On 2/2/2012 1:26 PM, Johannes Pfau wrote:

 std.uuid is ready to be reviewed. As far as I know there's nothing
 being reviewed right now, so we could start the review as soon as
 a review manager has been found.


 
 I'd like to see a string constant that is a regex for a UUID in its
 canonical form. The user could then simply pass that string to
 std.regex and pick UUIDs out of text.


done
Feb 08 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/8/2012 9:38 AM, Johannes Pfau wrote:

 Am Sun, 05 Feb 2012 21:48:36 -0800
 schrieb Walter Bright<newshound2 digitalmars.com>:
 done


danke
Feb 08 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Johannes Pfau wrote:

 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html


<snip>
 trusted UUID shaUUID(const(char[]) name, UUID namespace = nilUUID);
 trusted UUID shaUUID(const(ubyte[]) data, UUID namespace = nilUUID);
</snip>

When casting from void[] to ubyte[] will be working in CTFE (if ever), 
you might use just one function taking const(void[]) and cast it to 
ubyte[] internally.

About name, I think it should be sha1UUID.
Feb 06 2012
parent Johannes Pfau <nospam example.com> writes:
Am Tue, 07 Feb 2012 00:00:26 +0100
schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:


 Johannes Pfau wrote:

 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html


 
 <snip>
  trusted UUID shaUUID(const(char[]) name, UUID namespace = nilUUID);
  trusted UUID shaUUID(const(ubyte[]) data, UUID namespace = nilUUID);
 </snip>
 
 When casting from void[] to ubyte[] will be working in CTFE (if
 ever), you might use just one function taking const(void[]) and cast
 it to ubyte[] internally.


I'm not sure, most of the time you'd use the string version anyway and
in the few cases when you really want to use raw data a cast to ubyte[]
doesn't seem that bad.


 About name, I think it should be sha1UUID.


done
Feb 08 2012
prev sibling next sibling parent reply bls <bizprac orange.fr> writes:
On 02/02/2012 01:26 PM, Johannes Pfau wrote:

 Hi,

 std.uuid is ready to be reviewed. As far as I know there's nothing
 being reviewed right now, so we could start the review as soon as
 a review manager has been found.

 About std.uuid (copied from the module documentation):
 ---------------------
 This is a port of boost.uuid from the boost project with some minor
 additions and API changes for a more D-like API. A UUID, or Universally
 unique identifier, is intended to uniquely identify information in a
 distributed environment without significant central coordination. It
 can be used to tag objects with very short lifetimes, or to reliably
 identify very persistent objects across a network. UUIDs have many
 applications. [...]
 ---------------------

 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html

 Note: The code and documentation for shaUUID has already been written,
 but until phobos has support for SHA1, that can't be included. The code
 is currently commented out in the source file (it's well tested
 with some 3rd party SHA1 code), but the documentation for those
 functions is included in the API-docs. I think those functions should
 be reviewed as well, so that it's possible to add them to phobos with a
 simple pull request at a later date.

 Note2: std.uuid also need this pull request:
 https://github.com/D-Programming-Language/phobos/pull/398
 It adds a isRandomNumberGenerator template to detect if a template
 parameter is a random-number generator type.


Vote + (yes, works fine)

I want it and I need it. A Databases Access Layer (may it be a full 
blown  ORM  or even "just" a (D)ata (A)ccess (L)ayer ) depends on having 
unique IDs. ?

A convenience wish : string OID = GetUUID(); // RA UUID
Feb 07 2012
parent Johannes Pfau <nospam example.com> writes:
Am Tue, 07 Feb 2012 06:54:49 -0800
schrieb bls <bizprac orange.fr>:


 On 02/02/2012 01:26 PM, Johannes Pfau wrote:

 Hi,

 std.uuid is ready to be reviewed. As far as I know there's nothing
 being reviewed right now, so we could start the review as soon as
 a review manager has been found.

 About std.uuid (copied from the module documentation):
 ---------------------
 This is a port of boost.uuid from the boost project with some minor
 additions and API changes for a more D-like API. A UUID, or
 Universally unique identifier, is intended to uniquely identify
 information in a distributed environment without significant
 central coordination. It can be used to tag objects with very short
 lifetimes, or to reliably identify very persistent objects across a
 network. UUIDs have many applications. [...]
 ---------------------

 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html

 Note: The code and documentation for shaUUID has already been
 written, but until phobos has support for SHA1, that can't be
 included. The code is currently commented out in the source file
 (it's well tested with some 3rd party SHA1 code), but the
 documentation for those functions is included in the API-docs. I
 think those functions should be reviewed as well, so that it's
 possible to add them to phobos with a simple pull request at a
 later date.

 Note2: std.uuid also need this pull request:
 https://github.com/D-Programming-Language/phobos/pull/398
 It adds a isRandomNumberGenerator template to detect if a template
 parameter is a random-number generator type.


 
 Vote + (yes, works fine)
 
 I want it and I need it. A Databases Access Layer (may it be a full 
 blown  ORM  or even "just" a (D)ata (A)ccess (L)ayer ) depends on
 having unique IDs. ?
 
 A convenience wish : string OID = GetUUID(); // RA UUID
 


Sorry, I don't understand that example. What should GetUUID() return? a
Random UUID? What is the difference to randomUUID() then?
Feb 08 2012
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 02 Feb 2012 15:26:48 -0600, Johannes Pfau <nospam example.com> wrote:

 Hi,

 std.uuid is ready to be reviewed. As far as I know there's nothing
 being reviewed right now, so we could start the review as soon as
 a review manager has been found.

 About std.uuid (copied from the module documentation):
 ---------------------
 This is a port of boost.uuid from the boost project with some minor
 additions and API changes for a more D-like API. A UUID, or Universally
 unique identifier, is intended to uniquely identify information in a
 distributed environment without significant central coordination. It
 can be used to tag objects with very short lifetimes, or to reliably
 identify very persistent objects across a network. UUIDs have many
 applications. [...]
 ---------------------

 Code: https://github.com/jpf91/phobos/blob/std.uuid/std/uuid.d
 API-Docs: http://dl.dropbox.com/u/24218791/d/src/uuid.html

 Note: The code and documentation for shaUUID has already been written,
 but until phobos has support for SHA1, that can't be included. The code
 is currently commented out in the source file (it's well tested
 with some 3rd party SHA1 code), but the documentation for those
 functions is included in the API-docs. I think those functions should
 be reviewed as well, so that it's possible to add them to phobos with a
 simple pull request at a later date.

 Note2: std.uuid also need this pull request:
 https://github.com/D-Programming-Language/phobos/pull/398
 It adds a isRandomNumberGenerator template to detect if a template
 parameter is a random-number generator type.


Comments in order of generation, not importance:

"This is a port of  boost.uuid from the boost project with some minor additions
and API changes for a more D-like API." shouldn't be the first line in the docs.

"A UUID, or Universally unique identifier," one of these (or both) should link
to the Wikipedia article.

Variant is the name of an existing Phobos library type and version is a D
keyword. Now, thanks to Wikipedia I understand that variants and versions are a
core part of UUIDs, but a lack of documentation explanation sent me for a loop.
These terms should be explained better.

Suggested rewrite:
"This library implements a UUID as a struct allowing a UUID to be used in the
most efficient ways, including using memcpy. A drawback is that a struct can
not have a default constructors, and thus simply declaring a UUID will not
initialize it to a value generated by one of the defined mechanisms. Use the
struct's constructors or the UUID generator functions to get an initialized
UUID."->
"For efficiency, UUID is implemented as a struct. UUIDs therefore default to
nil. Use UUID's constructors or generator static members to get an initialized
UUID."

Also, this snippet needs to be part of the introductory example.
  UUID id;
  assert(id.isNil);
Oh, and the example should be fully commented. i.e.
  assert(id.isNil); // UUIDs default to nil
And shouldn't use writelns. i.e.
  assert(entry.uuidVersion == UUID.Version.nameBasedSha1);

All the generators have the function name [name]UUID. Instead, make these
function static member functions inside UUID and remove the UUID from the name.
i.e. nilUUID -> UUID.nil randomUUID -> UUID.random., etc. I'm not sure if you
should also do this for dnsNamespace, etc. (i.e. dnsNamespace -> UUID.dns) or
not.

UUID.nil should be an alias/enum to UUID.init, not an immutable.

There's an additional toString signature which should be supported. See
std.format.

uuidVersion() -> ver()?
Feb 08 2012
parent reply Johannes Pfau <nospam example.com> writes:
Thanks for your feedback! Comments below:

Am Wed, 08 Feb 2012 23:40:14 -0600
schrieb "Robert Jacques" <sandford jhu.edu>:


 
 Comments in order of generation, not importance:
 
 "This is a port of  boost.uuid from the boost project with some minor
 additions and API changes for a more D-like API." shouldn't be the
 first line in the docs.
 
 "A UUID, or Universally unique identifier," one of these (or both)
 should link to the Wikipedia article.


done


 
 Variant is the name of an existing Phobos library type and version is
 a D keyword. Now, thanks to Wikipedia I understand that variants and
 versions are a core part of UUIDs, but a lack of documentation
 explanation sent me for a loop. These terms should be explained
 better.


done


 Suggested rewrite:
 "This library implements a UUID as a struct allowing a UUID to be
 used in the most efficient ways, including using memcpy. A drawback
 is that a struct can not have a default constructors, and thus simply
 declaring a UUID will not initialize it to a value generated by one
 of the defined mechanisms. Use the struct's constructors or the UUID
 generator functions to get an initialized UUID."-> "For efficiency,
 UUID is implemented as a struct. UUIDs therefore default to nil. Use
 UUID's constructors or generator static members to get an initialized
 UUID."


This was a leftover from boost, fixed.


 Also, this snippet needs to be part of the introductory example.
   UUID id;
   assert(id.isNil);
 Oh, and the example should be fully commented. i.e.
   assert(id.isNil); // UUIDs default to nil


done


 And shouldn't use writelns. i.e.
   assert(entry.uuidVersion == UUID.Version.nameBasedSha1);


ok. I had to rewrite the example, but the writelns are gone now


 
 All the generators have the function name [name]UUID. Instead, make
 these function static member functions inside UUID and remove the
 UUID from the name. i.e. nilUUID -> UUID.nil randomUUID ->
 UUID.random., etc. I'm not sure if you should also do this for
 dnsNamespace, etc. (i.e. dnsNamespace -> UUID.dns) or not.


UUID.nil makes sense and looks better. I don't have an opinion about
the other functions, but struct as namespace vs free functions
has always led to debates here, so I'm not sure if I should change it.
I need some more feedback here first. (Also imho randomUUID() looks
better than UUID.random(), but maybe that's just me)


 
 UUID.nil should be an alias/enum to UUID.init, not an immutable.


alias UUID.init nilUUID;
doesn't work, it would work if nil was a member of UUID, but see above
for comments on that.
Made it an enum for now.


 
 There's an additional toString signature which should be supported.
 See std.format.


You're talking about this, right?
const void toString(scope void delegate(const(char)[]) sink);

Nice, when did the writeTo proposal get merged? I must have totally
missed that, actually writeTo is a way better choice here, as it can
avoid memory allocation.

but it seems to!string doesn't support the new signature?

BTW: How should sink interact with pure/safe versions? Can't we just
change that declaration to?

const  safe [pure] void toString(scope  safe pure void
delegate(const(char)[]) sink);


 
 uuidVersion() -> ver()?


I'm not sure, uuidVersion is indeed quite long, but it is more
descriptive as ver
Feb 09 2012
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 09 Feb 2012 03:57:21 -0600, Johannes Pfau <nospam example.com> wrote:

 Thanks for your feedback! Comments below:
 Am Wed, 08 Feb 2012 23:40:14 -0600
 schrieb "Robert Jacques" <sandford jhu.edu>:


[snip]


 All the generators have the function name [name]UUID. Instead, make
 these function static member functions inside UUID and remove the
 UUID from the name. i.e. nilUUID -> UUID.nil randomUUID ->
 UUID.random., etc. I'm not sure if you should also do this for
 dnsNamespace, etc. (i.e. dnsNamespace -> UUID.dns) or not.


 UUID.nil makes sense and looks better. I don't have an opinion about
 the other functions, but struct as namespace vs free functions
 has always led to debates here, so I'm not sure if I should change it.
 I need some more feedback here first. (Also imho randomUUID() looks
 better than UUID.random(), but maybe that's just me)


Hmm... I'd agree that randomUUID reads better than UUID.random. IMO well named
free-functions are generally better than fake namespaces via structs. However,
fake namespaces via structs a generally better than fake namespaces via
free-function naming convention (i.e. [function][namespace] or
[namespace][function]. That said, I think the bigger problem is that all these
functions are effectively constructors. I'd suspect that overloading UUID(...)
would be a clearer expression of the concepts involved. As for syntax, maybe
something like: UUID(Flag!"random", ... ) to disambiguate when necessary.

[snip]


 There's an additional toString signature which should be supported.
 See std.format.


 You're talking about this, right?
 const void toString(scope void delegate(const(char)[]) sink);

 Nice, when did the writeTo proposal get merged? I must have totally
 missed that, actually writeTo is a way better choice here, as it can
 avoid memory allocation.


I missed it to, then I saw code using it and smiled.


 but it seems to!string doesn't support the new signature?


I think that's worthy of a bug report.


 BTW: How should sink interact with pure/safe versions? Can't we just
 change that declaration to?

 const  safe [pure] void toString(scope  safe pure void
 delegate(const(char)[]) sink);


Since the to!, etc. are all templated, adding extra attributes is okay.


 uuidVersion() -> ver()?


 I'm not sure, uuidVersion is indeed quite long, but it is more
 descriptive as ver


Shrug. One's long, one's short, neither is perfect, version is a keyword.
Feb 09 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-10 06:48, Robert Jacques wrote:

 On Thu, 09 Feb 2012 03:57:21 -0600, Johannes Pfau <nospam example.com>
 wrote:

 Thanks for your feedback! Comments below:
 Am Wed, 08 Feb 2012 23:40:14 -0600
 schrieb "Robert Jacques" <sandford jhu.edu>:


 [snip]


 All the generators have the function name [name]UUID. Instead, make
 these function static member functions inside UUID and remove the
 UUID from the name. i.e. nilUUID -> UUID.nil randomUUID ->
 UUID.random., etc. I'm not sure if you should also do this for
 dnsNamespace, etc. (i.e. dnsNamespace -> UUID.dns) or not.


 UUID.nil makes sense and looks better. I don't have an opinion about
 the other functions, but struct as namespace vs free functions
 has always led to debates here, so I'm not sure if I should change it.
 I need some more feedback here first. (Also imho randomUUID() looks
 better than UUID.random(), but maybe that's just me)


 Hmm... I'd agree that randomUUID reads better than UUID.random. IMO well
 named free-functions are generally better than fake namespaces via
 structs. However, fake namespaces via structs a generally better than
 fake namespaces via free-function naming convention (i.e.
 [function][namespace] or [namespace][function]. That said, I think the
 bigger problem is that all these functions are effectively constructors.
 I'd suspect that overloading UUID(...) would be a clearer expression of
 the concepts involved. As for syntax, maybe something like:
 UUID(Flag!"random", ... ) to disambiguate when necessary.


UUID(Flag!"random", ... ) is just ugly. It's far better to use a static 
function with a descriptive name.

-- 
/Jacob Carlborg
Feb 10 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, February 10, 2012 09:56:36 Jacob Carlborg wrote:

 On 2012-02-10 06:48, Robert Jacques wrote:

 On Thu, 09 Feb 2012 03:57:21 -0600, Johannes Pfau <nospam example.com>
 
 wrote:

 Thanks for your feedback! Comments below:
 Am Wed, 08 Feb 2012 23:40:14 -0600


 

 schrieb "Robert Jacques" <sandford jhu.edu>:


 [snip]
 

 All the generators have the function name [name]UUID. Instead, make
 these function static member functions inside UUID and remove the
 UUID from the name. i.e. nilUUID -> UUID.nil randomUUID ->
 UUID.random., etc. I'm not sure if you should also do this for
 dnsNamespace, etc. (i.e. dnsNamespace -> UUID.dns) or not.


 
 UUID.nil makes sense and looks better. I don't have an opinion about
 the other functions, but struct as namespace vs free functions
 has always led to debates here, so I'm not sure if I should change it.
 I need some more feedback here first. (Also imho randomUUID() looks
 better than UUID.random(), but maybe that's just me)


 
 Hmm... I'd agree that randomUUID reads better than UUID.random. IMO well
 named free-functions are generally better than fake namespaces via
 structs. However, fake namespaces via structs a generally better than
 fake namespaces via free-function naming convention (i.e.
 [function][namespace] or [namespace][function]. That said, I think the
 bigger problem is that all these functions are effectively constructors.
 I'd suspect that overloading UUID(...) would be a clearer expression of
 the concepts involved. As for syntax, maybe something like:
 UUID(Flag!"random", ... ) to disambiguate when necessary.


 
 UUID(Flag!"random", ... ) is just ugly. It's far better to use a static
 function with a descriptive name.


Agreed.

- Jonathan M Davis
Feb 10 2012
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 10 Feb 2012 02:56:36 -0600, Jacob Carlborg <doob me.com> wrote:

 On 2012-02-10 06:48, Robert Jacques wrote:

 On Thu, 09 Feb 2012 03:57:21 -0600, Johannes Pfau <nospam example.com>
 wrote:

 Thanks for your feedback! Comments below:
 Am Wed, 08 Feb 2012 23:40:14 -0600
 schrieb "Robert Jacques" <sandford jhu.edu>:


 [snip]


 All the generators have the function name [name]UUID. Instead, make
 these function static member functions inside UUID and remove the
 UUID from the name. i.e. nilUUID -> UUID.nil randomUUID ->
 UUID.random., etc. I'm not sure if you should also do this for
 dnsNamespace, etc. (i.e. dnsNamespace -> UUID.dns) or not.


 UUID.nil makes sense and looks better. I don't have an opinion about
 the other functions, but struct as namespace vs free functions
 has always led to debates here, so I'm not sure if I should change it.
 I need some more feedback here first. (Also imho randomUUID() looks
 better than UUID.random(), but maybe that's just me)


 Hmm... I'd agree that randomUUID reads better than UUID.random. IMO well
 named free-functions are generally better than fake namespaces via
 structs. However, fake namespaces via structs a generally better than
 fake namespaces via free-function naming convention (i.e.
 [function][namespace] or [namespace][function]. That said, I think the
 bigger problem is that all these functions are effectively constructors.
 I'd suspect that overloading UUID(...) would be a clearer expression of
 the concepts involved. As for syntax, maybe something like:
 UUID(Flag!"random", ... ) to disambiguate when necessary.


 UUID(Flag!"random", ... ) is just ugly. It's far better to use a static  
 function with a descriptive name.


These functions are _constructors_; ideally, they should be expressed as  
such. In a managed language, we'd probably for with UUID("random",...).  
And if explicit template ctors were valid syntax, we'd used  
UUID!"random"(...) or UUID!Mt19937() or UUID!randomNumberBased or  
something. There's also the enum/aliases, i.e. UUID(UUID.random) or  
UUID(Enum!"random") or UUID(UUID.Version.randomNumberBased). And at least  
for random, overloading works decently well, i.e. UUID(mySeed) or  
UUID(Mt19937(unpredictableSeed)). My point, or lack thereof, was to  
brainstorm ways of expressing a large variety of construction routines  
_as_ actual constructors.
Feb 10 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, February 10, 2012 16:36:48 Robert Jacques wrote:

 These functions are _constructors_; ideally, they should be expressed as
 such. In a managed language, we'd probably for with UUID("random",...).
 And if explicit template ctors were valid syntax, we'd used
 UUID!"random"(...) or UUID!Mt19937() or UUID!randomNumberBased or
 something. There's also the enum/aliases, i.e. UUID(UUID.random) or
 UUID(Enum!"random") or UUID(UUID.Version.randomNumberBased). And at least
 for random, overloading works decently well, i.e. UUID(mySeed) or
 UUID(Mt19937(unpredictableSeed)). My point, or lack thereof, was to
 brainstorm ways of expressing a large variety of construction routines
 _as_ actual constructors.


A factory function is vastly better than any of those suggestions IMHO. I see 
no problem with having randomUUID as a free function, and I really think that 
it's best as-is.

- Jonathan M Davis
Feb 10 2012
parent reply Tobias Pankrath <tobias pankrath.net> writes:
Jonathan M Davis wrote:


 On Friday, February 10, 2012 16:36:48 Robert Jacques wrote:

 These functions are _constructors_; ideally, they should be expressed as
 such. In a managed language, we'd probably for with UUID("random",...).
 And if explicit template ctors were valid syntax, we'd used
 UUID!"random"(...) or UUID!Mt19937() or UUID!randomNumberBased or
 something. There's also the enum/aliases, i.e. UUID(UUID.random) or
 UUID(Enum!"random") or UUID(UUID.Version.randomNumberBased). And at least
 for random, overloading works decently well, i.e. UUID(mySeed) or
 UUID(Mt19937(unpredictableSeed)). My point, or lack thereof, was to
 brainstorm ways of expressing a large variety of construction routines
 _as_ actual constructors.


 
 A factory function is vastly better than any of those suggestions IMHO. I
 see no problem with having randomUUID as a free function, and I really
 think that it's best as-is.
 
 - Jonathan M Davis


randomUuid it should be.
Feb 10 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/11/2012 12:26 AM, Tobias Pankrath wrote:

 Jonathan M Davis wrote:


 On Friday, February 10, 2012 16:36:48 Robert Jacques wrote:

 These functions are _constructors_; ideally, they should be expressed as
 such. In a managed language, we'd probably for with UUID("random",...).
 And if explicit template ctors were valid syntax, we'd used
 UUID!"random"(...) or UUID!Mt19937() or UUID!randomNumberBased or
 something. There's also the enum/aliases, i.e. UUID(UUID.random) or
 UUID(Enum!"random") or UUID(UUID.Version.randomNumberBased). And at least
 for random, overloading works decently well, i.e. UUID(mySeed) or
 UUID(Mt19937(unpredictableSeed)). My point, or lack thereof, was to
 brainstorm ways of expressing a large variety of construction routines
 _as_ actual constructors.


 A factory function is vastly better than any of those suggestions IMHO. I
 see no problem with having randomUUID as a free function, and I really
 think that it's best as-is.

 - Jonathan M Davis


 randomUuid it should be.


No.

Also see http://www.d-programming-language.org/phobos/std_utf.html
Feb 10 2012
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, February 11, 2012 00:40:39 Timon Gehr wrote:

 On 02/11/2012 12:26 AM, Tobias Pankrath wrote:

 Jonathan M Davis wrote:

 On Friday, February 10, 2012 16:36:48 Robert Jacques wrote:

 These functions are _constructors_; ideally, they should be
 expressed as such. In a managed language, we'd probably for with
 UUID("random",...). And if explicit template ctors were valid
 syntax, we'd used
 UUID!"random"(...) or UUID!Mt19937() or UUID!randomNumberBased or
 something. There's also the enum/aliases, i.e. UUID(UUID.random) or
 UUID(Enum!"random") or UUID(UUID.Version.randomNumberBased). And at
 least for random, overloading works decently well, i.e.
 UUID(mySeed) or UUID(Mt19937(unpredictableSeed)). My point, or lack
 thereof, was to brainstorm ways of expressing a large variety of
 construction routines _as_ actual constructors.


 
 A factory function is vastly better than any of those suggestions
 IMHO. I see no problem with having randomUUID as a free function, and
 I really think that it's best as-is.
 
 - Jonathan M Davis


 
 randomUuid it should be.


 
 No.
 
 Also see http://www.d-programming-language.org/phobos/std_utf.html


Yeah. For the most part, Phobos takes the tact of making all letters in 
acronyms be the same case (all uppercase if the first letter is uppercase and 
all lowercase if the first letter is lowercase).

- Jonathan M Davis
Feb 10 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-10 23:36, Robert Jacques wrote:

 On Fri, 10 Feb 2012 02:56:36 -0600, Jacob Carlborg <doob me.com> wrote:

 UUID(Flag!"random", ... ) is just ugly. It's far better to use a
 static function with a descriptive name.


 These functions are _constructors_; ideally, they should be expressed as
 such. In a managed language, we'd probably for with UUID("random",...).
 And if explicit template ctors were valid syntax, we'd used
 UUID!"random"(...) or UUID!Mt19937() or UUID!randomNumberBased or
 something. There's also the enum/aliases, i.e. UUID(UUID.random) or
 UUID(Enum!"random") or UUID(UUID.Version.randomNumberBased). And at
 least for random, overloading works decently well, i.e. UUID(mySeed) or
 UUID(Mt19937(unpredictableSeed)). My point, or lack thereof, was to
 brainstorm ways of expressing a large variety of construction routines
 _as_ actual constructors.


The first item of the book "Effective Java Programming Language Guide" 
says "Consider providing static factory methods instead of constructors".

But if you want to insist on actual constructs, I would prefer 
UUID(UUID.random) instead of UUID("random",...) or UUID!"random"(...).

-- 
/Jacob Carlborg
Feb 11 2012