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

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

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

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

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.

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

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:

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:

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