Re: [boost] [review] Review of Flyweight library started January 21and still running!: equality semantic

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2008-01-27 14:52:03

----- Mensaje original -----
De: "vicente.botet" <vicente.botet_at_[hidden]>
Fecha: Domingo, Enero 27, 2008 7:10 pm
Asunto: Re: [boost] [review] Review of Flyweight library started 
January 21and still running!: equality semantic
Para: boost_at_[hidden]

> Hi all,
> equality semantic
> bool b=(&(fw1.get())==&(fw2.get())); versus bool 
> b=((fw1.get())==(fw2.get())); Why not delegate this responsability 
> to the factory, the factory knows better when the two handles are
> equal, isn't it?
> 
>  friend bool operator==(const flyweight& x,const flyweight& y)
>  {
>    return core:are_equals(x.h==y.h);
>  }
> 
> The factories provided by the library could define this are_equals 
> function 
> as
>     return (&x==&y); Regards---------------------------

Umm, this approach is interesting! Better yet, instead of relying on an
explicit are_equals function, we can just require that
Factory::handle_type is EqualityComparable and use that:

  friend bool operator==(const flyweight& x,const flyweight& y)
  {
    return x.h==y.h;
  }

As a matter of fact, all the current factories have EqualityComparable
handles that precisely implement reference equality semantics, so
it looks all very natural. This approach would solve the second
problem of the list I presented at the review notes:

 * The resulting equality semantics might not coincide with that of
  the underlying T; the possibility of this hapenning and making a
  real difference is probably small, though. 
 * The assumption that equal flyweight objects always share their value
  interfere with potential extensions to the library, like the
  no-factory proposal by Throsten Ottosen. 

but would not address the first point. 

Thanks for your suggestion,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo