On Friday, February 10, 2012 09:56:36 Jacob Carlborg 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.
Agreed. - Jonathan M Davis
