On Fri, 10 Feb 2012 02:56:36 -0600, Jacob Carlborg <d...@me.com> wrote:
On 2012-02-10 06:48, Robert Jacques wrote:
On Thu, 09 Feb 2012 03:57:21 -0600, Johannes Pfau <nos...@example.com>
wrote:
Thanks for your feedback! Comments below:
Am Wed, 08 Feb 2012 23:40:14 -0600
schrieb "Robert Jacques" <sandf...@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.