D - Idea for 2.0: "nevermodify" modifier for class members
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Feb 04 2004
- "Andres Rodriguez" <rodriguez ai.sri.com> Feb 04 2004
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Feb 05 2004
- "Andres Rodriguez" <rodriguez ai.sri.com> Feb 05 2004
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Feb 05 2004
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Feb 04 2004
- J Anderson <REMOVEanderson badmama.com.au> Feb 04 2004
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Feb 05 2004
- J Anderson <REMOVEanderson badmama.com.au> Feb 05 2004
- "C" <dont respond.com> Feb 04 2004
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
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
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
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
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
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
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
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
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
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









Russ Lewis <spamhole-2001-07-16 deming-os.org> 