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