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

On Friday, February 10, 2012 16:36:48 Robert Jacques wrote:
> 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.

A factory function is vastly better than any of those suggestions IMHO. I see no problem with having randomUUID as a free function, and I really think that it's best as-is.

- Jonathan M Davis

Jonathan M Davis wrote:

> On Friday, February 10, 2012 16:36:48 Robert Jacques wrote:
>> 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.
> 
> A factory function is vastly better than any of those suggestions IMHO. I see no problem with having randomUUID as a free function, and I really think that it's best as-is.
> 
> - Jonathan M Davis
randomUuid it should be.

On 02/11/2012 12:26 AM, Tobias Pankrath wrote:
> Jonathan M Davis wrote:
>
>> On Friday, February 10, 2012 16:36:48 Robert Jacques wrote:
>>> 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.
>>
>> A factory function is vastly better than any of those suggestions IMHO. I
>> see no problem with having randomUUID as a free function, and I really
>> think that it's best as-is.
>>
>> - Jonathan M Davis
> randomUuid it should be.

No.

Also see http://www.d-programming-language.org/phobos/std_utf.html

On Saturday, February 11, 2012 00:40:39 Timon Gehr wrote:
> On 02/11/2012 12:26 AM, Tobias Pankrath wrote:
> > Jonathan M Davis wrote:
> >> On Friday, February 10, 2012 16:36:48 Robert Jacques wrote:
> >>> 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.
> >> 
> >> A factory function is vastly better than any of those suggestions IMHO. I see no problem with having randomUUID as a free function, and I really think that it's best as-is.
> >> 
> >> - Jonathan M Davis
> > 
> > randomUuid it should be.
> 
> No.
> 
> Also see http://www.d-programming-language.org/phobos/std_utf.html

Yeah. For the most part, Phobos takes the tact of making all letters in acronyms be the same case (all uppercase if the first letter is uppercase and all lowercase if the first letter is lowercase).

- Jonathan M Davis

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

The first item of the book "Effective Java Programming Language Guide" says "Consider providing static factory methods instead of constructors".

But if you want to insist on actual constructs, I would prefer UUID(UUID.random) instead of UUID("random",...) or UUID!"random"(...).

-- 
/Jacob Carlborg