Re: [boost] [UUID] PODness Revisited

Subject: Re: [boost] [UUID] PODness Revisited
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-28 21:20:29

Scott,

I feel the discussion highlighted the fact that our design priorities and 
usage patterns seem quite irreconcilable within one class. More so, the 
discussion seems to have introduced new requirements like 
old-standard-compliant low-level copying, ability to create an uninitialized 
uuid instance, efficient and economic initialization from hard-coded uuids 
(mentioned by Adam) that might not have been addressed in Andy's 
implementation yet. Therefore, I feel that yours and Dave's suggestions of 
"a low-level representation class as well as a higher-level wrapper with 
stronger invariants" might be the best approach to cater for those widely 
differing deployments. At present it'll probably be Andy's call if/how he 
decides to incorporate your suggestions and package it all as two classes or 
to discard one or the other. Ideally, I'd probably like to see two classes. 
Something like boost::aggregate_uuid and a boost::uuid wrapper as I suspect 
that wrapper to be the most common deployment choice. If the decision is 
made to go only for one aggregate-type uuid, then I'd like we make sure the 
documentation spells out how to "objectify" (what'd be a better term?) that 
aggregate type.

Best,
V.

P.S. As a side note, I am glad we had the discussion and I appreciate you 
kept it going -- it forced me to have a fresh look at aggregates from a 
completely different perspective. Due to the specifics of my work I am 
unlikely to deploy any of that in the short timeframe. However, it surely 
enriched me. Thank you.