
Signature
The comp.lang.java.gui FAQ:
http://gd.tuwien.ac.at/faqs/faqs-hierarchy/comp/comp.lang.java.gui/
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
> > I get paid for C++
>
[quoted text clipped - 5 lines]
>
> You won't get a const_itertator. Java is not C++.
I know. One has four letters other has one letter plus two symbol!
> a) You will hopefully soon find out that it is typically a waste of time
> trying to protect objects from getting modified. If you have designed
[quoted text clipped - 3 lines]
> objects, don't give them the objects at all. If you trust them, let them
> do whatever they want.
The world is not binary. I can trust someone, but that does not mean I
need to trust every one. You should check the book by Joshua Bloch and
how it created problem when a non mutable class like Dimension is
returned from every Java Swing component. None of the resizing event
will get fired if one modifies the returning dimension. So one had to
make a defensive copy! And that is a pretty simple example (where it
stores only two int , and some equivalent like getWidth() can be
prescribed) . Think of a complex class and how to deal with it. Will
you make a defensive copy of everything! Thats ridiculous! apart from
being inefficient.
I found out that Java seriously lacks here. It reserves const keyword
though. What I can say only is that it is very very very baaaaad.
(Though I understand it is not just a compile time saga to add const in
the language vocabuulary, one need to put is in JVM function signature
also, but there is workaround without modifing the JVM, just like the
way Java generic has done! )
Check the beautiful article
http://david.tribble.com/text/javaconst.html
> > As the List returns a get
> > reference to object, the object always can be modified.
[quoted text clipped - 5 lines]
> then wrap them in some immutable wrapper object before you add them to
> the list. Typically, however, that is a waste of time and resources.
Really waste of time and resource. Not efficient at all. This can be
termed as a fix. If I am having 20 lac objects in a list ( I really do
have ) , I can't think of it.
> public class ValuableObject {
> public int getData() { ...}
[quoted text clipped - 28 lines]
> /Thomas
> --
<quote>
As Chris Uppal says, you're on a loser if you're wanting stl-like
functionality from Java.
</quote>
No, I am not. A programmer always want to use best of all language, and
simply ignore all other way.
> The comp.lang.java.gui FAQ:
> http://gd.tuwien.ac.at/faqs/faqs-hierarchy/comp/comp.lang.java.gui/
> ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
Thomas Weidenfeller - 05 Oct 2006 09:45 GMT
> The world is not binary. I can trust someone, but that does not mean I
> need to trust every one. You should check the book by Joshua Bloch and
[quoted text clipped - 6 lines]
> you make a defensive copy of everything! Thats ridiculous! apart from
> being inefficient.
You are wasting our time here. And your time, too.
You won't get what you want from Java, and we are not particular
interested in your "but C++ is so much better" rant. Most here know Java
and C++ very well. For us Java works and we really see no point in
reading well known books and articles once again.
> I found out that Java seriously lacks here.
Trust me, your finding will not earn you a Nobel Price.
F'up set to a more appropriate group.
/Thomas

Signature
The comp.lang.java.gui FAQ:
http://gd.tuwien.ac.at/faqs/faqs-hierarchy/comp/comp.lang.java.gui/
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
Chris Uppal - 05 Oct 2006 12:55 GMT
> Check the beautiful article
> http://david.tribble.com/text/javaconst.html
I would much prefer mutability to be controllable at the object level (regular
readers will recall that I am no fan of static typechecking ;-). I agree that
there is /some/ benefit in static analysis of mutability control[*], but there
is /much/ more mileage to be gained by allowing objects to be marked immutable.
Also it doesn't involve adding yet /another/ layer of horrible complexity to
Java.
-- chris
[*] Indeed the only time I remember when static analysis pointed out a more
serious error in my code than just a typo, or similar, was when the C++
const-checking pointed out that I had misfactored the responsibilities amongst
a group of objects.