www.digitalmars.com         C & C++   DMDScript  

D - Idea for 2.0: "nevermodify" modifier for class members

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I'm starting to write a small game in D, and I'm hitting the same 
situation over and over.  I'm writing classes which don't ever modify 
(at least some) of their members except in constructors.

Of course, there's nothing wrong with the language as it is...but it 
would be nice to be able to define a contract which estated that nobody 
(other than the constructor) would modify ever it.

Just something to ponder for 2.0...
Feb 04 2004
next sibling parent reply "Andres Rodriguez" <rodriguez ai.sri.com> writes:
Isn't that what final fields are?  At least in Java, but since
D also has final I assumed they were the same thing.


"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bvrikg$2ak3$1 digitaldaemon.com...
 I'm starting to write a small game in D, and I'm hitting the same
 situation over and over.  I'm writing classes which don't ever modify
 (at least some) of their members except in constructors.

 Of course, there's nothing wrong with the language as it is...but it
 would be nice to be able to define a contract which estated that nobody
 (other than the constructor) would modify ever it.

 Just something to ponder for 2.0...

Feb 04 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I see on the website that D has "final", but I don't see any 
documentation on what it does.

IIRC, in Java "final" means that you can't override the field, not that 
you can't write to it outside of a constructor.


Andres Rodriguez wrote:
 Isn't that what final fields are?  At least in Java, but since
 D also has final I assumed they were the same thing.
 
 
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bvrikg$2ak3$1 digitaldaemon.com...
 
I'm starting to write a small game in D, and I'm hitting the same
situation over and over.  I'm writing classes which don't ever modify
(at least some) of their members except in constructors.

Of course, there's nothing wrong with the language as it is...but it
would be nice to be able to define a contract which estated that nobody
(other than the constructor) would modify ever it.

Just something to ponder for 2.0...


Feb 05 2004
parent reply "Andres Rodriguez" <rodriguez ai.sri.com> writes:
 IIRC, in Java "final" means that you can't override the field, not that
 you can't write to it outside of a constructor.

No, that it's the meaning for methods. I don't see what you mean by overriding a field, since you can always declare a field with the same name. The following compiles fine in Java: class A { final int i = 0; } class B extends A { int i; }
Feb 05 2004
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Andres Rodriguez wrote:
IIRC, in Java "final" means that you can't override the field, not that
you can't write to it outside of a constructor.

No, that it's the meaning for methods.

Right. I didn't realize that Java allowed you to add 'final' to fields.
 I don't see what you mean
 by overriding a field, since you can always declare a field with the
 same name.  The following compiles fine in Java:
 
 class A {
 final int i = 0;
 }
 class B extends A {
 int i;
 }

Time for some experimentation with D code, I guess!
Feb 05 2004
prev sibling next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Russ Lewis wrote:
 I'm starting to write a small game in D, and I'm hitting the same 
 situation over and over.  I'm writing classes which don't ever modify 
 (at least some) of their members except in constructors.
 
 Of course, there's nothing wrong with the language as it is...but it 
 would be nice to be able to define a contract which estated that nobody 
 (other than the constructor) would modify ever it.
 
 Just something to ponder for 2.0...

Perhaps we should just have an extendable syntax, such as contract(expr) which would add a contract property to a variable, and contract(expr) { ... } which would add a contract block of some sort.
Feb 04 2004
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Russ Lewis wrote:

 I'm starting to write a small game in D, and I'm hitting the same 
 situation over and over.  I'm writing classes which don't ever modify 
 (at least some) of their members except in constructors.

 Of course, there's nothing wrong with the language as it is...but it 
 would be nice to be able to define a contract which estated that 
 nobody (other than the constructor) would modify ever it.

 Just something to ponder for 2.0...

-- -Anderson: http://badmama.com.au/~anderson/
Feb 04 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Sure.  The current code doesn't do any checking, I just don't use the 
fields.  I just thought that this is likely to be a common usage 
pattern, and it would be nice to have it as one more part of DBC, some 
time in the future.

J Anderson wrote:
 You could do a run-time check with a setter.

Feb 05 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Russ Lewis wrote:

 Sure.  The current code doesn't do any checking, I just don't use the 
 fields.  I just thought that this is likely to be a common usage 
 pattern, and it would be nice to have it as one more part of DBC, some 
 time in the future.

 J Anderson wrote:

 You could do a run-time check with a setter.


-- -Anderson: http://badmama.com.au/~anderson/
Feb 05 2004
prev sibling parent "C" <dont respond.com> writes:
Hmm , will final work ?  Maybe some tricks with class invariants ?

C
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bvrikg$2ak3$1 digitaldaemon.com...
 I'm starting to write a small game in D, and I'm hitting the same
 situation over and over.  I'm writing classes which don't ever modify
 (at least some) of their members except in constructors.

 Of course, there's nothing wrong with the language as it is...but it
 would be nice to be able to define a contract which estated that nobody
 (other than the constructor) would modify ever it.

 Just something to ponder for 2.0...

Feb 04 2004