Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd

Subject: Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
From: Vladimir.Batov_at_[hidden]
Date: 2008-12-01 20:21:08

Andy,

>> ...
> 
> The first thing that comes to mind is size.  A uuid class that holds the 

> data at text ...
> As a much more minor note, ...

I thought you might jump on my mikki-mouse string-based UUID... and in 
fact it was a trap of a sort. :-) I had a strong impression that the 
discussion in this thread revolved too much about actual implementation 
(MAC retrieval springs to mind) and too little about the interface. Yes, 
the implementation is important but it is the interface that makes it or 
breaks it as far as user's acceptance is concerned. That (acceptance) buys 
you time to improve the implementation hidden behind the interface. My 
concern with the proposal is that IMHO the interface has not been given 
enough consideration from the user perspectives.

> I agree that many users do not care about the algorithm used.  If they 
> really don't care, is it an issue to use the
> boost::uuids::uuid_generator 
> since they don't really care what it does anyway? 

I feel that "do not care" is an oversimplification. The user does care -- 
he wants the "best available" without getting bogged down investigating 
what that "best available" exactly is. That is what Linux uuid_generate() 
gives the user right out of the box. To be successful boost::uuid just has 
to match that offer.

> I believe they would 
> just use this function and assume all is well. 

I have to disagree. As a user I do not want to *assume*. I want to *know* 
that my application uses the available infrastructure to the fullest. That 
way if/when something goes wrong, it'll the OS to blame and not my 
application.

> Those who care will look 
> at what boost::uuids::uuid_generator does and decide for themselves. 

Unfortunately, the reality begs for correction. I do care. However, with 
dead-lines approaching and the boss breathing down my neck I simply have 
no resources to look at every damn thing to decide for myself. In fact, I 
do not want to as I expect much-smarter-than-me people to have taken care 
of that for me. Exactly as I do not try reinventing std::map (even though 
I am aware of other than red-black-tree algorithms available). 

> They will likely be happy as long as there are the options that they
> want.

Giving options is merely part of the deal -- people often hate 
choice/options as they have to stop/think/evaluate/decide -- that process 
in time-consuming and draining, it distracts people from their main task. 
The only option pretty much guaranteed to succeed IMHO is the "best 
available" option.

> I do want boost::uuid to provide algorithms to create uuids.  I don't 
> want platforms that don't provide an algorithm to not be able to easily 
> create a uuid.  Thus I don't want boost::uuid to be just a wrapper
> around 
> OS functionality.

I do not think I said I wanted to see boost::uuid to be just a wrapper. In 
a nut-shell I'd like to see boost::uuid providing the user with the "best 
available" option. If that means Linux uuid_generate() or your own 
algorithm under the hood, then it's fine by me.

> > Does boost::uuid provide superior support and a upgrade path? 
>> ...
> 
> I would agree, that boost::uuid will never have the support of 
> industrial/commercial scale.  I now think that boost::uuid should
> provide 
> a windows_uuid_generator (that uses UuidCreate), a linux_uuid_generator 
> (that uses uuid_generate), plus possibility others platform specific
> ones, 
> plus some of it's own.  Then a boost::uuids::uuid_generator could use 
> one of these if available and if not, use it's own generator.  This
> would 
> give users the support and upgrade paths that you are talking about.

Makes a lot of sense to me. Saying to the user -- Dear user, I've done the 
hard yards for you and I've come up with the best option available on your 
platform -- is a lot. I believe the overwhelming majority will be very 
happy. The curious ones (or with too much time :-) on their hands) will 
still be able to play with explicit uuid generators via "uuid 
id(some-generator);"

> ...
> I do believe that a null uuid is a valid uuid, but regardless, if the 
> common use case really is as you say, then sure lets have the default 
> constructor call a function to generate a unique uuid.  And still 
> provide a way to create a null uuid.

Please do not take my word for it. Just look around at your own usage 
pattern of the default constructor beyond the UUID domain. 

> My work also heavily relies on uuids, but we almost never create one 
> ourselves in code.  We get almost all our uuids from the database 
> that our program uses. 

Understood. Our usage is pretty much the same. Still, if my component does 
not create UUIDs, then IMHO it has to state that with

Foo()
:
    uuid_(boost::uuid::null()) // initially invalid
{}

That way the other poor soul coming after me won't be getting any wrong 
ideas/interpretations what the code is actually doing.

> I would be surprised if there aren't many 
> others that use uuids in the same way, they receive them, they don't 
> generate them.

Understood. I do not believe you should be providing the default 
constructor for that usage pattern -- it feels like the copy constructor 
is in order here.

All in all my impression of the *current* situation with the proposal is 
that at *present* we have many useful and promising bits and pieces lying 
around. I see good ideas. I see good suggestions. I fail to see the 
product. It surely is a good start but to me we have not reached the 
destination yet. I'd be more comfortable after I see those bits and pieces 
taking shape. For me that shape primarily would be the interface and the 
documentation -- the initial pieces of the contract between the user and 
the implementor. Once both parties are happy with the contract, you'll 
beaver away providing the content/implementation.

Thanks,
Vladimir.