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
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 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
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 "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 "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
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 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 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
prev sibling next sibling parent 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
prev sibling next sibling 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.

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 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 next sibling parent 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
prev sibling next 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 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 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

Feb 10 2012
parent 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


No. Also see http://www.d-programming-language.org/phobos/std_utf.html
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
prev sibling next sibling parent 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.

 
 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 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.

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.

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()?

descriptive as ver
Feb 09 2012
prev sibling next sibling parent "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.

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()?

descriptive as ver

Shrug. One's long, one's short, neither is perfect, version is a keyword.
Feb 09 2012
prev sibling 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>:

 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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