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

... 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.
Now that I looked at the code once again, I think I'd like to take back the "bits and pieces lying around" bit (as it feels plain wrong and I think I need better glasses to see things the first time around :-)). In fact, I feel that all the pieces are more/less in place and I'll be very much in content if I see something along the following lines: namespace boost { class uuid { struct time_generator; struct random_generator; struct best_generator; template<class Generator> uuid(Generator const&) {...} or template<class Generator> uuid(Generator const& =best_generator()) {...} static uuid null() { ... } typedef void (base::*bool_type)(); void internal_bool() {}; operator bool_type() const { return *this == null() ? 0 : &base::internal_bool; } ... }; struct uuid::time_generator { ... }; struct uuid::random_generator { ... }; struct uuid::best_generator { ... }; } // boost Replacing is_null() with the implicit "bool" converter is not a syntactic sugar. It's very much idiomatic along the same lines as "a + b" is better than "a.add(b)". I'd probably look at deploying Boost.Range functionality as I see many constructors working with ranges. With that caveat I think I am all willing to abandon my original (a very lonely BTW) position and run over to the happy 'yes' campers. Thanks, Vladimir.

On Wed, 3 Dec 2008 18:42:50 +1100, "Vladimir Batov" <batov@people.net.au> said:
... 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.
Now that I looked at the code once again, I think I'd like to take back the "bits and pieces lying around" bit (as it feels plain wrong and I think I need better glasses to see things the first time around :-)).
Thanks.
In fact, I feel that all the pieces are more/less in place and I'll be very much in content if I see something along the following lines:
namespace boost {
class uuid { struct time_generator; struct random_generator; struct best_generator;
template<class Generator> uuid(Generator const&) {...} or template<class Generator> uuid(Generator const& =best_generator()) {...}
static uuid null() { ... }
typedef void (base::*bool_type)(); void internal_bool() {}; operator bool_type() const { return *this == null() ? 0 : &base::internal_bool; }
... };
struct uuid::time_generator { ... }; struct uuid::random_generator { ... }; struct uuid::best_generator { ... };
} // boost
I like the look of this.
Replacing is_null() with the implicit "bool" converter is not a syntactic sugar. It's very much idiomatic along the same lines as "a + b" is better than "a.add(b)".
I like the implicit "bool" converter too.
I'd probably look at deploying Boost.Range functionality as I see many constructors working with ranges.
With that caveat I think I am all willing to abandon my original (a very lonely BTW) position and run over to the happy 'yes' campers.
Thanks, Vladimir.
Thanks, Andy Tompkins
participants (2)
-
Andy Tompkins
-
Vladimir Batov