Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-07 11:01:56

In message <01ad01c018ca$10d615a0$520a24d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>Whether the default op== should return true or false is an interesting
>question. This is the 'value' vs. 'identity' equality semantics problem.
>
>Good arguments exist in favour of either.

It's only a problem until one decides whether or one dealing with
identity-based or value-based objects. The pitch I'm hearing for ref<>
is that it's value-based: If that is true, what are the good arguments
in favour of identity-based equality?

>> Except when they don't have an operator<: How can you produce the same
>> ordering as the statically-typed version when the statically-typed
>> version does not compile? Mu!
>
>Of course. An user that puts objects without an op< defined into refs and
>then sorts the container gets what (s)he deserves.

Why not choose the simpler option? Don't put it in. Provide the user
with a facility that is as clear as it could possibly be.

>> This also brings us back again to T < U being intuitive: Until you
>> started outlining ref<>'s semantics, the only common definition of which
>> I was aware for interpreting this notation was "T is a subtype of U"
>> (which is not in fact a strict weak ordering). Hmm, even since, I still
>> reckon that's the only common definition ;-)
>
>This is discussed in D & E. Good arguments exist against the T < U ::= U
>is-a T definition.

I think you're beginning to catch my drift! ;-)

>> No, in fact, I'm even more convinced: How can "unspecified" be a more
>> intuitive definition than "is a subtype of", or "is included within", or
>> "is less than", or "is lexicographically less than"? Just because it has
>> wings doesn't mean it can fly.
>
>I would have certainly preferred a standard total ordering of types. This
>would have made it possible to write portable persistence libraries that do
>not rely on the user registering all types with some unique identifiers.
>
>A standard type_info::name() could have served that purpose.

That's really the domain of ABI's, but yes I know where you're coming
from, and standard naming would indeed have made life simpler.

>Unfortunately, the standard states that the compiler is not required to
>impose a specified total ordering on types. How could I?

Total ordering is not required, only partial ordering.

I think you misunderstand the issue: It is not whether or not an order
can be specified for types, it is whether such an ordering deserves to
be called operator<, especially if it is unspecified. I would humbly
suggest that it doesn't, and that the cttee were not misguided in naming
type_info::before rather than type_info::operator<. To borrow advice
from Messrs Strunk & White, "prefer the standard to the off beat".
Instead of providing operator< provide a named member function and a
named function object class.
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________