On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix <deadal...@gmail.com> wrote:
On 11/07/2012 19:49, Andrei Alexandrescu wrote:
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take
something
obvious like a class object representing a dataset in a database. How
is
an immutable instance of such a class useful?
This is a good point. It seems we're subjecting all classes to certain
limitations for the benefit of a subset of those classes.
Andrei
Did you saw the proposal of feep/tgehr on #d ?
It basically state that you can overload a const method with a non const
one if :
- You don't mutate any data that belong to the parent.
- You are prevented to create any immutable instance of that classe or
any subclasse.
I don't like this idea. It means you could not use pure functions to
implicitly convert mutable class instances to immutable (something that
should be possible today).
It also seems to allow abuses. For example:
class A
{
private int _x;
public @property x() const { return _x; }
}
class B : A
{
private int _x2;
public @property x() { return _x2++; }
}
Now I've completely changed the logistics of the x property so that it's
essentially become mutable. In effect, I overrode the const piece of x
completely to make it non-const without a cast, and anyone calling x() on
an A instance cannot trust that it won't increment the effective value of
x().
I think the solution to this overall problem is simply to make
object.opEquals use the most derived types available for comparison.
-Steve
