std.uuid is ready for review

[Robert Jacques]

On Fri, 10 Feb 2012 02:56:36 -0600, Jacob Carlborg <doob at me.com> wrote:
> 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.
>

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.