Re: [boost] [uuid] Interface

Subject: Re: [boost] [uuid] Interface
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-20 21:22:08

> What makes the Nil UUID not "valid"?

Scott, I suspect you are asking the questions you already know the answers 
to. Still I'll try answering them. Nil is invalid in the same way as NULL is 
invalid -- it does not deliver the main properties the class has been 
designed for. nil and NULL are specifically introduced to be different and 
distinguishable from normal "valid" objects. *That* makes them "invalid".

> It has its own section in the
> RFC, and regardless of what the default constructor does, there's
> going to be uuids::nil() to get an instance of it.

Yes, I hope there will "be uuids::nil() to get an instance of it" and I'd 
like that to be the only get-nil mechanism. I thought the original 
discussion centered around the default constructor behavior and to me that 
behavior is very important what the default constructor does.

> If it's "invalid", why is it still available?

It is available for the same reason NULL and -1 (for many C functions) (and 
many other objects designated as "invalid") are available and I really do 
not want to be elaborating obvoius things of that kind. Still, it does not 
make uuid::nill() or uuid a pointer.

>>> Do you have some examples of other objects that do (or should) behave
>>> similarly to your desire for uuid?
>>
>> int example = int();
>> double d  = double();
>> std::string str;
>> in fact probably all the classes with the value semantics.
>>
>
> None of those do any generation of any sort;

To me it is application-specific what any constructor does or does not, 
generation or no generation.

> They all have T() == T();

So what? The fact that for some classes T() == T() is purely coincidental. 
Or is it in the Standard? I'll promptly agree/surrender if it is a Standard 
requirement.

> And they all are rarely useful as-is.

An 0 integer and an empty string "are rarely useful as-is"? I do not 
understand what you mean.

> I'd argue that pointers do have value semantics.

I am not sure what to say to that.

> swap(int *, int *) can only swap the pointees, not the pointers 
> themselves.

In fact, swap(int* p1, int* p2) swaps the *pointers* because after the call 
p1 will have the value of p2 and p2 will have the value of p1.

> I'd say that the fundamental property of pointers is that, in the
> relevant domain, there exists an injective map from set the "pointees"
> to the set of pointers (the "address of" operator, for plain pointers)
> and a surjective map from the set of pointer to the set of "pointees"
> (the "dereference" operator, for plain pointer).
> UUIDs fit that definition.  If you label each, say, database record
> with a UUID, there's a surjective map from the UUID to the record
> (with something like "SELECT ... WHERE id = @id" in SQL), and an
> injective map from the record to the UUID (by looking at the id field
> in the record).

The same concept is likely to have different meanings in different areas and 
on different absraction levels. My interpretation of a pointer is pretty 
much as Wikipedia desribes it: In computer science, a pointer is a 
programming language data type whose value refers directly to (or "points 
to") another value stored elsewhere... For me UUID does not fit *that* 
definition.

> The point is that this is a *breaking* change in the standard unless
> you assume that value_type() == value_type() for every type that could
> be put in a std::vector in C++03. I can't think of any applicable type
> that breaks that assumption -- and presumably the committee couldn't
> either -- so I don't think that making UUID break it is a good idea.

I'd appreciate if you could clarify the following for me: Is value_type() == 
value_type() an assumpton you made, or is it an assumption you know the 
committee made or the committee stated somewhere that was an expectation or 
even a requirement for not following which would be a *breaking* change? 
Could you please indicate any documents or parts of the Standard (I could 
not find anything of that kind)? And what exactly "my-style" UUID is 
breaking? These are honest questions. We've been using "my-style" UUID quite 
extensively (over a year) in our project and would like to know what exactly 
we are breaking.

Apologies that I snipped and left unanswered quite a bit of your replies. 
They seem to cover too many different areas/issues and I simply have no 
capacity to agrue of such a wide front. So, I am happy you have it your way.

Best,
V.