std.uuid is ready for review
sandford at jhu.edu
Fri Feb 10 14:36:48 PST 2012
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>
>>> Thanks for your feedback! Comments below:
>>> Am Wed, 08 Feb 2012 23:40:14 -0600
>>> schrieb "Robert Jacques" <sandford at 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.
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.
More information about the Digitalmars-d