"Chris Cain" wrote in message news:[email protected]...
If you want just to specify that (and not ask the compiler to check for
you), documentation will do.
Heh, if only the world was so ideal...
That's _any_ kind of modification of state. If you change state, you can't
use immutable/const (nor would you really want to).
Okay...
D's const/immutable require a different way of thinking of it. What are
they useful for? Consider a multithreaded program where some threads
depend on information that others have.
I guess this answers my question then: const/immutable are useful for
multithreading.
So it means, essentially, they're pretty useless for Objects, but only
useful for structs.
Why? Objects have **behavior** (not just data), and depending on the
_internal details_ of that behavior would be depending on an implementation
detail.
Sure, the method writer can call the method 'const', but he really has no
idea whether someone will override it down the road and get struck by
lightning because of that.
What D's const seems to be is for *data*, pure and simple (no pun intended).
Using it for behavior would be trying to predict the future implementations,
and that is pretty damn hard.
Because of that, I think we disallow direct instantiation of const() or
immutable() Objects altogether, because they're pretty useless.
In C++, you'd be foolish to not have locks set up even for const variables
because they can change at any time for any reason.
Huh? Not if they're instance variables.
It's kind of silly to lock against something so you can modify instance
variables.
It's hardly a guarantee and it's so common to violate (look at yourself,
for instance) that it means _nothing_.]
I don't think I ever violated C++'s 'const'... (?)
I liked how it was described as a glorified comment, because that's
precisely how I think of it.
More like, a **CHECKED** comment.
Big difference.
