> 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... ;) ) 

Hmm. IMHO, this would be very easy to implement in the compiler. It would make class definitions clearer, and in many cases would lessen the need to write code.

Just off-hand I can imagine quite a few situations where I'd use this.

On Thu, 14 Sep 2006 16:59:56 +0300, Georg Wrede <georg.wrede@nospam.org> wrote:
>> 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... ;) )
>
> Hmm. IMHO, this would be very easy to implement in the compiler. It would make class definitions clearer, and in many cases would lessen the need to write code.
>
> Just off-hand I can imagine quite a few situations where I'd use this.

Well, when I said that this woundn't be needed in D, I didn't realize the fact that will reduce the amount of written code, a little (no need to write a read property). So maybe there is a demand for such a feature in D after all...

In addition, what if it would be possible then to have a write property using the same name? For example:

class Obj {
    int size(int newSize) {
        return(size = newSize);
    }

    readonly int size;
}

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

    v = o.size;  //variable used
    o.size = 1;  //function 'size()' used
}

Defining a read function woundn't be possible, I think, so the 'read access' couldn't be overridden. The 'size' variable should then hold a cached value, so to speak. (When the size value is changed in the class, the 'size' variable is updated correspondingly.)

I am not sure if this is a good idea or not. For instance, if you write "size = 1;" _inside_ the class, should the function be called or the variable modified directly? If the function is used, how to access the variable, etc. So, apparently, the function should be only used outside the class. It'll notify that the user wants to change the value.

Ever heard of "private"?

Georg Wrede wrote:
>> 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... ;) ) 
> 
> 
> Hmm. IMHO, this would be very easy to implement in the compiler. It would make class definitions clearer, and in many cases would lessen the need to write code.
> 
> Just off-hand I can imagine quite a few situations where I'd use this.

Hasan Aljudy wrote:
> Ever heard of "private"?

Ever heard of "private for writing, public for reading"? "Readonly" would be both.

On Thu, 14 Sep 2006 09:59:56 -0400, Georg Wrede <georg.wrede@nospam.org> wrote:

>> 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... ;) )
>
> Hmm. IMHO, this would be very easy to implement in the compiler. It would make class definitions clearer, and in many cases would lessen the need to write code.
>
> Just off-hand I can imagine quite a few situations where I'd use this.

D's const has this ability..
class Obj
{
   this(int foo) { m_size = foo; }
   const int m_size;
}

On Fri, 15 Sep 2006 04:40:11 +0300, Chris Miller <chris@dprogramming.com> wrote:
> On Thu, 14 Sep 2006 09:59:56 -0400, Georg Wrede <georg.wrede@nospam.org> wrote:
>
>>> 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... ;) )
>>
>> Hmm. IMHO, this would be very easy to implement in the compiler. It would make class definitions clearer, and in many cases would lessen the need to write code.
>>
>> Just off-hand I can imagine quite a few situations where I'd use this.
>
> D's const has this ability..
> class Obj
> {
>     this(int foo) { m_size = foo; }
>     const int m_size;
> }

If I am not completely mistaken here, you're mistaken. ;)

One can use 'const' as you demostrated, but 'm_size' can be set only in constructor(s) to initialize it. A 'readonly' variable would be assignable everywhere inside 'Obj' (but only inside the class). That is, it's public for reading and protected for writing.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4509605C.3040408@nospam.org...

>> 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
>> }

> Hmm. IMHO, this would be very easy to implement in the compiler. It would make class definitions clearer, and in many cases would lessen the need to write code.

class Obj
{
    void f()
    {
        int mSize = 10;
    }

    public int size()
    {
        return mSize;
    }

    private int mSize;
}

..

Obj o = new Obj;
o.f();
writefln(o.size);
o.size = 4; // illegal

Properties, broperties.

On Sat, 16 Sep 2006 00:22:12 +0300, Jarrett Billingsley <kb3ctd2@yahoo.com> wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
> news:4509605C.3040408@nospam.org...
>
>>> 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
>>> }
>
>> Hmm. IMHO, this would be very easy to implement in the compiler. It would
>> make class definitions clearer, and in many cases would lessen the need to
>> write code.
>
> class Obj
> {
>     void f()
>     {
>         int mSize = 10;
>     }
>
>     public int size()
>     {
>         return mSize;
>     }
>
>     private int mSize;
> }
>
> ..
>
> Obj o = new Obj;
> o.f();
> writefln(o.size);
> o.size = 4; // illegal
>
> Properties, broperties.

Yep, you're right. However, I think you miss the point of this thread by a little... ;)

In the very first post (the quoted part) I said that this feature isn't needed in D because of the properties. Then Georg pointed out that it would lesses the need to write code (no need to create a read property). Then I stated that this feature is faster also so that it could be useful in some time critical cases.

Few hours ago ephemeros send a message "Properties set/get huge speed difference?" to digitalmars.D.learn. He was wondering why a read property is so much slower (about 20 times) than accessing directly a member variable. (That's because a virtual function call is slower than accessing a variable, of course.)

If this feature, lets call it "sub-property", would be possible, then reading a property value will always be *very* fast (just access a variable).

And if my another thought, a write property using the same name as the member variable, would be possible, then you could use it just like normal properties (that is, outside the class).

For example:

class Obj {
    void f() {
        size = 10;  //ok; use member variable
    }

    int size(int newSize) {
        return(size = newSize);  //use member variable
    }

    readonly int size;
}

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

    s = o.size;  //use member variable
    o.size = 1;  //use write property
}

Of course, this creates an ambiguous situation in 'Obj': a function and a variable uses the same name. So, variable should overrule a write property inside the class.

It's a pretty neat concept, your suggesting, of course. Yet, it'd introduce a new keyword to D, so efficiency and demand would have to be there, realistically.

I disagree; I like the short list of keywords, and wouldbe glad if it kept like this. Also, maybe there's another way to get some speed into properties. Doesn't have to be a whole new ZOMGfeature.

Best regards,
Alex

On Thu, 2006-09-14 at 16:59 +0300, Georg Wrede wrote:
> > 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... ;) )
> 
> Hmm. IMHO, this would be very easy to implement in the compiler. It would make class definitions clearer, and in many cases would lessen the need to write code.
> 
> Just off-hand I can imagine quite a few situations where I'd use this.