std.uuid is ready for review

Jacob Carlborg doob at me.com
Fri Feb 10 00:56:36 PST 2012


On 2012-02-10 06:48, Robert Jacques wrote:
> On Thu, 09 Feb 2012 03:57:21 -0600, Johannes Pfau <nospam at example.com>
> wrote:
>> Thanks for your feedback! Comments below:
>> Am Wed, 08 Feb 2012 23:40:14 -0600
>> schrieb "Robert Jacques" <sandford at 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


More information about the Digitalmars-d mailing list