std.uuid is ready for review

Robert Jacques sandford at jhu.edu
Thu Feb 9 21:48:45 PST 2012


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.

[snip]

>>
>> There's an additional toString signature which should be supported.
>> See std.format.
> You're talking about this, right?
> 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()?
> I'm not sure, uuidVersion is indeed quite long, but it is more
> descriptive as ver

Shrug. One's long, one's short, neither is perfect, version is a keyword.


More information about the Digitalmars-d mailing list