Why there are no 'physical' object variables (only references)?

Kristian kjkilpi at gmail.com
Thu Sep 14 03:41:23 PDT 2006


On Wed, 13 Sep 2006 12:02:27 +0300, Reiner Pope  
<reiner.pope at REMOVE.THIS.gmail.com> wrote:
> Steve Horne wrote:
[snip]
>> Pointers even need to be told whether it is the pointer that is const
>> or the value pointed to, or both for that matter.
>>
> This is what I was talking about with the ugliness of const, not the  
> naming system.
>
>    const Fred const * p;
>

Yep, that one doesn't look nice. (And it's a bit confusing too.)


> is a bit excessive, don't you think? Not to mention very illegible. D's  
> move to implicit reference semantics for classes means that we can get a  
>   generally-easier-to-read syntax, like is proposed in Javari:
>
>    readonly final Fred p;
>
> where 'readonly' refers to the actual data, and 'final' means that p  
> can't be used as an lval (ie, the pointer itself is const).

That's indeed more readable. I woundn't mind using it or something similar.


 From time to time I wish that C++ would have a readonly specifier that  
works like this:

class Obj {
     void f() {
         int m_size = 10;  //ok
     }

     readonly int m_size;
}

void func() {
     Obj o = new Obj;
     int v;

     v = o.m_size;  //ok
     o.m_size = 5;  //error
}

'm_size' can be accessed inside 'Obj' as normal, but outside the class the  
variable cannot be modified. Of course, I could provide a read property  
(that is, a function in C++) for accessing 'm_size' (in addition to a  
write property), but when it's not necessary, this way is simplier (and a  
little bit faster, etc.).

In D this, however, is not needed because you can use properties to wrap  
member variables.
(Hopefully the properties will be extended to support the same methods  
that can be applied to variables also... ;) )



More information about the Digitalmars-d mailing list