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

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.

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/

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

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.

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

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.
>
>
That it would.

-- 
-Anderson: http://badmama.com.au/~anderson/

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

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!