Re: How do java programmers cope with java missing c++ const?



I do not miss const. I do not miss retro-fitting existing non-const
code with const. I do not miss having to use libraries written by
folks that did not know about const at end of method declartions, or
more generally the various uses of const in C++.
There is some joy, for me, when writing C++ code, in using const in
all places it fits, and also there is some joy in correctly casting it
away (or 'mutable' it away if compiler supported) when internal state
changes cannot be logically deduced outside of class.

In Java, to make classes thread-safe and to manage the complexity of
threaded programs I endevour towards immutable classes. Indeed these
are different from const, immutability sort-of-means that every time an
instance of a immutable class is passed, it is being passed as const.
If an object is not immutable it is always being passed as non-const.

What is using const conceptually? Assuming one thinks of object
oriented programming as separate entities that can talk to one another
through explicit means then using const on parameters is like saying to
a person: "I will introduce you to someone I know, but you cannot talk
to him like everyone else talks to him, you need to refrain from
talking about these things: ....".
Kindof funkily the person who you made introduction to can igonore
your qualification (aka cast away constness in C++). But that's asking
for trouble. My point is: A) that the const language construct is,
factually speaking, too complicated for many programmers consideration
(think chemist, or other scientist, who wants some specific program to
"just work, damn it") B) in Java I can always facade mutable objects in
immutable ones if I really want to avoid modifications, C) in Java,
when objects are muttable, I can frequently remove threading concerns
by using synchronized. On this last note, I think the synchronized
keyword in Java is far more valuable then the const keyword in C++.

All the best,

Opalinski
opalpa@xxxxxxxxx
http://www.geocities.com/opalpaweb/

.



Relevant Pages

  • Re: Anders Hejlsberg comment on immutable objects
    ... >>Implicitly const classes are immutable by implementation. ... The immutability could be accomplished ... often cast to get the interface instead of simply hoping that the entire ... >>are apparent and a coder can deal with them, an implicit conversion is a ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anders Hejlsberg comment on immutable objects
    ... >object immutable as either a sideeffect or a matter of const implementation. ... The immutability could be accomplished ... >> look the other way while I cheat, by applying a cast, I expect it to ... >are apparent and a coder can deal with them, an implicit conversion is a ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: const
    ... But const isn't specific to any problem domain, ... that transcend any particular programming language and exist simply to ... implementing a serializer to be able to specify a reference to an object ... able to specify immutability at the class level? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anders Hejlsberg comment on immutable objects
    ... The immutability could be accomplished ... Immutable means that all instances are const. ... >> the case for all built in implicit convertions. ... If you mean that you use cast to mark _improper_ implicit conversions, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anders Hejlsberg comment on immutable objects
    ... Implicitly const classes are immutable by implementation. ... >>cast it away, and as I've said many times, everyone, me and you included, ... > Implicit conversions are quite different. ... I should say immutability should be a design goal for value types. ...
    (microsoft.public.dotnet.languages.csharp)