Congratulations to the D Team!

Steven Schveighoffer schveiguy at yahoo.com
Wed Jul 11 11:21:24 PDT 2012


On Wed, 11 Jul 2012 14:01:44 -0400, deadalnix <deadalnix at 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


More information about the Digitalmars-d mailing list