Re: [boost] [uuid] Interface

Subject: Re: [boost] [uuid] Interface
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-24 15:15:04

> But there's always the other way to resolve a disagreement over
> semantics: parametrization!
>
> What if there was an initialization policy?  boost::uuid could be
> boost::uuids::uuid<no_default>, since I think there are a fairly large
> number of use cases that don't need one at all.  lexical_cast<uuid<T>
>> could be overloaded to call lexical_cast<uuid<aggregate> >, the
> fastest option.  People could have map<string, uuid<nil_default> > if
> they want the "if (m[foo])" shortcut.  And you could have
> uuid<native_generator>.

It's got me thinking about uuid parametrization and I think there is part of 
it that I am warming up to and the other part that I am unsure of. What I 
think we indeed could parameterize on might be the generator, i.e.

template<class Generator>
uuid { ... };

Reasoning behind it is that it is probably most likely that the developer 
once chosen a particular generator will stick with it throughout its 
application rather than juggling different generators at run-time. 
Therefore, parameterizing of the generator seems to make the code more solid 
and easier to maintain as the variability (and the room for an error --  
calling the wrong generator) out of the equation. The "bad" thing is that 
this seem to better fit the def. cnstr (with generating behavior):

template<class Generator>
uuid
{
    typedef ... nil_type;
    static nil_type nil;

    uuid()
    {
        typename Generator::range range = Generator::generate();
        this->initialize(range.begin(), range.end());
    }
    uuid(nil_type)
    {
        for (boost::array<char, 16>::iterator i = data.begin(), end =
data.end(); i != data.end(); *i = 0, ++i);
    }
};

As for parameterization of policy, then I am honestly not sure. As a proof 
of the concept it indeed sounds good. My fear though is that for 
maintainability/readability purposes that might be a nightmare.

Having said that, that my view about hte def. cnstr and its behavior is just 
my view. If there is a good number of people thinking that the def. cnstr 
wih the nil behavior might be better/more practical, we should adapt the 
view, clearly document that and move forward. The certainly good part of it 
it'll make a lot of things easier to implement.

Best,
V.