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.