Re: [boost] [UUID] uuid.hpp Objective C++ conflict.

Subject: Re: [boost] [UUID] uuid.hpp Objective C++ conflict.
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2009-08-21 05:10:36

On Thu, 20 Aug 2009 10:53:08 -0700, Scott McMurray  
<me22.ca+boost_at_[hidden]> wrote:

> 2009/8/18 Mostafa <mostafa_working_away_at_[hidden]>:
>>
>> 1.0) Why not make a static class variable named NIL, since nil() returns
>> the same value all the time?
>>
>
> Actually, is there a define for Objective C like __cplusplus?  Since
> the value-initializer of a POD uuid gives a nil UUID, the function is
> just in case someone wishes added clarity, and could be #ifndef'ed out
> entirely.
>

Yes, it's "__OBJC__".

I actually like the idea of an explicit function or const variable for nil  
uuid *exactly for the purpose of adding clarity*.  With instances of POD  
types I don't assume that declaration implies initialization, since that's  
not the case with the usual cast of characters, i.e., pointers, int,  
float, etc.  Hence, I automatically initialize any instance of a POD type  
that I declare.

For the time being and for my internal copy of the lib, I'm just following  
Mathias' suggestion.

>>
>> As for 2), now I'm wondering why this particular function is a namespace
>> function and not a method (static) of class uuid?  (I'll scrounge the
>> mailing lists for an answer in the mean time).
>>
>
> Part of the point of the alt v13 was to turn the uuid class itself
> into a completely minimal dumb value type.  All UUID generation (be it
> random, time-based, hash-based, known values, ...) was moved outside.
> Part of the advantage of this is in making uuid.hpp as limited as
> possible, avoiding the need to pull SHA1 hashing or Mercenne Twisters,
> for instance, into an interface header just because it has a uuid
> parameter somewhere.

Maybe I'm missing something, but a static method does not negate the  
PODness of a type, and the nil uuid is already being generated in  
uuid.hpp.  The only reason I ask this question, and I guess I would  
advocate this position, is because it makes sense from an OO perspective.   
The creation of an empty instance is usually the responsibility of the  
class type of that instance.  (That doesn't mean that the class is  
responsible for creating all useful variations of itself, that task can  
and should be delegated to utility classes.)

A little more into my thought process:

It would seem that all other namespace functions in uuid.hpp must be  
namespace functions for two reasons:
1) the language forces it, in the case of the operator functions.
2) it's existing practice for their use in STL, for the case of swap and  
hash_value

Also, via Koenig lookup, these functions would qualify being part of class  
uuid's public interface.  Let's just say it's OOP with C++ characteristics  
:)

But nil didn't fit into the above two categories, therefore no special  
reason for it to be a stand alone function, and Koenig lookup does not  
apply to it, therefore it really can't be be considered as part of class  
uuid's public interface.  So, it either should be part of a util class  
that generates various uuid values or it should be part of class uuid  
itself.  Because generating the trivial instance has traditionally been  
done by the instance's class, I thought that nil should be moved into the  
uuid class.

Hopefully it doesn't seem that I'm beating a dead horse, I just like to  
spell out my rationale.

-Mostafa