D - Idea for 2.0: "nevermodify" modifier for class members
- Russ Lewis (7/7) Feb 04 2004 I'm starting to write a small game in D, and I'm hitting the same
- Andres Rodriguez (4/11) Feb 04 2004 Isn't that what final fields are? At least in Java, but since
- Russ Lewis (5/25) Feb 05 2004 I see on the website that D has "final", but I don't see any
- Andres Rodriguez (9/11) Feb 05 2004 No, that it's the meaning for methods. I don't see what you mean
- Russ Lewis (3/18) Feb 05 2004 Time for some experimentation with D code, I guess!
- Russ Lewis (6/15) Feb 04 2004 Perhaps we should just have an extendable syntax, such as
- J Anderson (4/11) Feb 04 2004 You could do a run-time check with a setter.
- Russ Lewis (5/6) Feb 05 2004 Sure. The current code doesn't do any checking, I just don't use the
- J Anderson (4/10) Feb 05 2004 That it would.
- C (4/11) Feb 04 2004 Hmm , will final work ? Maybe some tricks with class invariants ?
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:Right. I didn't realize that Java allowed you to add 'final' to fields.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; }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...You could do a run-time check with a setter. -- -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:That it would. -- -Anderson: http://badmama.com.au/~anderson/You could do a run-time check with a setter.
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