Hi, developers!
I created a Transfer Object pattern class, that has an array field. See below:
class TOClass{
privateint[] values;
//notice that I am using clone() method
publicint[] getValues(){
return (int[])values.clone();
}
publicvoid setValues(int[] values){
this.values = (int[])values.clone();
}
}
Would you do like I did?
Thanks in advance!
> (Anyway, if it's a pure containter, I'd omit the
> setters and make the fields final (immuable).)
Many thanks for your reply, I am developing this class in my work, and my doubt is if the solution I chose is appropriated. I want to avoid the data manipulation, as you noticed.
I am very interested in your solution, using final fields. Are you saying to omit setters? It is simply impossible! I need them!!! Or maybe I did not understand you well. May you explain me, with an example of code, please?
> (Not too much use fixing a reference to an array,
> though. Doesn't prevent data manipulation.)
Sorry, I have difficult to understand English sometimes. Do you mean that my solution doesn磘 prevent data manipulation? For me it does prevent. How the values of the array elements can be modified, using the solution above?
final public class IOClass {
final private List<Integer> values;
public IOClass(final List<Integer> values) {
super();
this.values = values;
}
final public int getValueCount() {
return values.size();
}
final publc Iterator<Integer> getAllValues() {
return values.iterator();
}
final public int getValue(final int index) {
return values.get(index).intValue();
}
}
- Saish
Saish, that code doesn't prevent modification. The list passed in can be referenced elsewhere and the iterator may allow remove().
In terms of the OPs question, I assume the problem being referred to is that you have a setter for the array, so it makes little difference that you are making copies of it, you've provided a way to change it. The only think that is useful about copying on setting it is for synchronization, but I don't see any of that here.
In regad to copying and wrapping Collections in immutable wrappers, it really depends on how paranoid you are and how rough the other developers on your teams are going to be on your classes. It's probably a good idea to have some layer of protection but if everyone else is going to copy what you return, it becomes pretty silly.
> > List list = Collections.unmodifiableList(new
> ArrayList());
>
>
> Good point!
>
> - Saish
You still need to make a copy or add all the items to a new list in the constructor.
List<Integer> list = getSomeStuff();
IOClass ioc = new IOClass(list);
// take this, IOClass.
list.removeAll();
> But then I get all the evils of the Cloneable
> interface! :^(
>
> - Saish
Nah, just do this:
public IOClass(final List<Integer> values) {
super();
this.values = new ArrayList<Integer>(values);
}
public List<? extends Integer> getValues() {
// make this wrapper an instance if you worry about performance
return Collections.unmodifiableList(values);
}
Thank you, you all!
I am testing the solution you presented, Saish, and I am verifying yet. But I see that the problem of manipulation of data continues, like dubway said. But, this discussion gave me a lot of ideas! (I didn磘 know Collections.unmodifiableList() method yet, very interesting method). I will continue my researchs for the best solution.
But I have to worry only when the getter method is used, because I don磘 know what other developers will do with the value returned. I don磘 need to worry about setter, because the only person that sets is me, and nobody else.
And one more thing. My TO class does not contain only one field. There are other fields: Strings, BigDecimals, etc, but these other fields are easy, I just have to create getters and setters for them. There is only one field that has the "behaviour of an array". But because of the fact that there are other fields, to not make this class complicated and "dirty" visually, I really want to use simple getters and setters methods, only. Your solution is not providing getters and setters exactly, Saish. I want to follow the Transfer Object pattern, whose feature is the existence of getters and setters, only.
> Nah, just do this:
> >public IOClass(final List<Integer> values) {
>super();
>this.values = new ArrayList<Integer>(values);
>}
>
>public List<? extends Integer> getValues() {
> // make this wrapper an instance if you worry
> u worry about performance
>return Collections.unmodifiableList(values);
>}
>
I will test it. ;-)
Yeah!!! Very good solution, Saish!!! Finally, I made my class like this:
class TOClass implements Serializable {
private List values;
public List getValues() {
return Collections.unmodifiableList(values);
}
public void setValues(List values) {
this.values = values;
}
}
I dont need to use either final field or constructor initialization. Ive already tested, and it works!!! But I noticed a disadvantage of using Collections.unmodifiableList() method: I tried to cast to ArrayList after return the List with getValues() method, and the following exception happened:
java.lang.ClassCastException: java.util.Collections$UnmodifiableList
So, my conclusion is that it is not possible to cast to ArrayList when we use unmodifiableList(). But this solution you gave me already saves me! Thank you, very much!!!
> Yeah!!! Very good solution, Saish!!! Finally, I made
> my class like this:
>
> class TOClass implements Serializable {
>private List values;
>
>public List getValues() {
>return Collections.unmodifiableList(values);
>}
>
>public void setValues(List values) {
>this.values = values;
>}
> }
Try this:
toClass.setValues(values);
values.clear();
and see what happens.
> I dont need to use either final field or constructor
> initialization. Ive already tested, and it works!!!
> But I noticed a disadvantage of using
> Collections.unmodifiableList() method: I tried to
> cast to ArrayList after return the List with
> getValues() method, and the following exception
> happened:
>
> java.lang.ClassCastException:
> java.util.Collections$UnmodifiableList
>
> So, my conclusion is that it is not possible to cast
> to ArrayList when we use unmodifiableList(). But this
> solution you gave me already saves me! Thank you,
> very much!!!
Why are you casting to ArrayList? What do you need that List doesn't provide?
> Hi, developers!
>
> I created a Transfer Object pattern class, that has
> an array field. See below:
> > class TOClass {
>private int[] values;
>
>//notice that I am using clone() method
>
>public int[] getValues() {
>return (int[])values.clone();
>}
>
>public void setValues(int[] values) {
>this.values = (int[])values.clone();
>}
> }
>
> Would you do like I did?
>
> Thanks in advance!
you do not have to do any clonse. int is a primitive value, all primitives are passed by value, meaning they are all duplicated.
if you are using Integer objects, then you would have to clone them, because Integers are objects, they are passed by or as references in java. if they are not cloned, there will be just one set of objects.
keep in mind, parameters are passed by value only in java, primitives are passed by value as well, objects are passed by or as references, aqnd that is the only way in java in which objects are passed: by or as references.
Actually, and fortunately, I dont need any of exclusive methods of ArrayList, like clone(), ensureCapacity(), removeRange().
And you are saying to me to do below to guarantee that the value will not be changed, arent you?
toClass.setValues(values);
values.clear();
As Ive already written, I dont need to worry about setter method, but maybe other developer will want to use setter method, and he/she maybe will be surprised that he/she can modify the value of the field outside the class!!! But it will not happen, I hope...
Maybe the very useful method of ArrayList that the other developer will want to use is clone(). Unfortunately, he/she will not able to use it. He/she will only use the List in read-only way. I think read-write is not possible. See below:
List theList = toClass.getValues();
//the next line will cause UnsupportedOperationException
//because of the use of unmodifiableList()
//and, unfortunately, the clone() method
//is not available in List...
//the developer wont be able to
//modify the values,
//but thats ok!!!!
//I dont need to worry about it
//and if the developer really
//wants to modify the values
//there are other ways to do that
//and to achieve him/her goal
theList.set(1, new Integer(5));
Thank you very much, dubway!!!
For the protection of the unsuspecting.: daFei is the forum crackpot or the village idiot, you might say. Almost every post he makes contains incorrect information.
> you do not have to do any clonse. int is a primitive
> value, all primitives are passed by value, meaning
> they are all duplicated.
int is a primitive int[] is an Object type.
> if you are using Integer objects, then you would have
> to clone them, because Integers are objects, they are
> passed by or as references in java. if they are not
> cloned, there will be just one set of objects.
This is also wrong. Integers are immutable, whether the variables are references is irrelevant.
> keep in mind, parameters are passed by value only in
> java, primitives are passed by value as well, objects
> are passed by or as references, aqnd that is the only
> way in java in which objects are passed: by or as
> references.
Ignore this.
> Actually, and fortunately, I dont need any of
> exclusive methods of ArrayList, like clone(),
> ensureCapacity(), removeRange().
>
> And you are saying to me to do below to guarantee
> that the value will not be changed, arent you?
>
> toClass.setValues(values);
> values.clear();
No, it's to demonstrate that your values can be changed. The list referred to by the member and the list referred to by the local are the same Object.
Another issue to consider is that you don't know what type of List is being passed in. It may be a LinkedList, an ArrayList, a Vector or some unknown anonymous inner class that belongs to some other Object. It could be a wrapper around an open ResultSet acting as a proxy to a database located on Mars. You are taking candy from strangers and handing it out to kids.
daFei, I tried to understand you, but sincerelly I cannot understand you. My impression is that you have your rules and your definitions, in your world. Im not saying that your thoughts doesnt make sense. Probably they make sense, but they make sense only in your world, in your mind. You must consider the real world!.
Let me explain better. Suppose you are color-blind. What you are trying to say us is like this:
daFei: "The sky is red!"
people: "No daFei, the sky is blue!"
daFei: "No!!! Its red!!! For me the sky is red! You all are wrong!"
people: "daFei, the sky is blue!"
blahblahblah...
Sorry, my English is bad. Do you understand me? Of course, I am exagerating a little in my joking, sorry for the joking. ;-)
> daFei, I tried to understand you, but sincerelly I
> cannot understand you. My impression is that you have
i know it is difficult, i do not blame you at all. i debated people here for years on this. many people finally understand this, as they have grown up over the years:)
> int is a primitive int[] is an Object type.
int[] is an object type?
> This is also wrong. Integers are immutable, whether
> the variables are references is irrelevant.
immutable objects, just like muutable ones, are also referenced - it is pointless.
> > keep in mind, parameters are passed by value only in
> > java, primitives are passed by value as well, objects
> > are passed by or as references, aqnd that is the only
> > way in java in which objects are passed: by or as
> > references.
>
> Ignore this.
try to understand this, do NOT ignore this.
> > int is a primitive int[] is an Object type.
>
> int[] is an object type?
Yes. How can you hang around these forums for so many years and still not know this?
Try this in your own test program:
int[] intArray = new int[10];
boolean test = (intArray instanceof Object);
System.out.println("intArray is an Object? " + test);
Object o = intArray;
test = (o == intArray);
System.out.println("o is intArray?" + test);
> > This is also wrong. Integers are immutable,
> whether
> > the variables are references is irrelevant.
>
> immutable objects, just like muutable ones, are also
> referenced - it is pointless.
How about this, write a piece of compilable Java code that demonstates your point. If you can do this and show why I'm wrong, I'll believe you. Otherwise, stop posting incorrect info.
> Try this in your own test program:
> > int[] intArray = new int[10];
>
> boolean test = (intArray instanceof Object);
>
> System.out.println("intArray is an Object? " + test);
>
>
haha...this is wrong, although test will print true. now you chicken heads can get confused for another year:))))))
> haha...this is wrong, although test will print true.
> now you chicken heads can get confused for another
> year:))))))
Sure daFei, everyhing that is provably correct is wrong but your
provably wrong assertions are correct. That makes a lot of sense.
Here's something else you'll surely deny with some absurd statement.
From the JLS: version 2
http://java.sun.com/docs/books/jls/second_edition/html/arrays.doc.html#25550
"
10.8 Class Objects for Arrays
Every array has an associated Class object, shared with all other arrays with the same component type. The direct superclass of an array type is Object. Every array type implements the interfaces Cloneable and java.io.Serializable.
This is shown by the following example code:
class Test {
public static void main(String[] args) {
int[] ia = new int[3];
System.out.println(ia.getClass());
System.out.println(ia.getClass().getSuperclass());
}
}
which prints:
class [I
class java.lang.Object
where the string "[I" is the run-time type signature for the class object "array with component type int".
"
The thing that amazes me about you is that you seem to actually believe these things that you write, even though all evidence shows they are incorrect. When presented with incontrovertible proof that you are wrong, you basically respond with nonsensical jabbering.
I've never actually seen you post any code. You don't do so when challeneged to prove your assertions. I think that you aren't actually a developer and have never written a working Java application. If this is true, it makes your lurking around these forums even more bizarre.
> haha...this is wrong, although test will print true.
> now you chicken heads can get confused for another
> year:))))))
Why don't you explain why it is wrong? Seriously, why don't you? If you are so sure you are right, why can't you explain it? Show me something more that stupid comments.
Just because I screwed up the posts so many times:
static final public void main(final String[] args)
throws Throwable {
int[] foo = new int[5];
System.out.println(Object.class.isInstance(foo));
System.out.println(foo instanceof Object);
}
true
true
- Saish
> > Yes, that returns true, since the int[] inherits
> from
> > Object (as do all Java objects). What's your
> point?
> >
> > - Saish
>
> mine returns false though. i am using 1.3. whats
> yours?
Yes, daFei, the writers of the JLS don't know what they are talking about. We need you to write a new JLS that tells us how Java really works. All these people who are using the JLS are having trouble because they don't get the way that Java really works because only you know it and haven't written it for everyone to read.
All you've demonstrated is that Object is not a subclass of int[] which everyone already knew. Way to demonstrate yet again that you have no idea what you are writing about.
> > if you are using Integer objects, then you would
> have
> > to clone them, because Integers are objects, they
> are
> > passed by or as references in java. if they are
> not
> > cloned, there will be just one set of objects.
>
> This is also wrong. Integers are immutable, whether
> the variables are references is irrelevant.
And I'm still waiting for you to demonstrate why it is necessary to copy the Integers but not the ints.
> try this:
>
> intArray.getClass().isInstance(Object.class)
I also have to point out the irony of calling a getClass() (a method defined in Object) on an intArray in order to attempt to demonstrate that intArray is not an Object. If it's not an Object why you can call getClass() on it?!
> try this:
> > intArray.getClass().isInstance(Object.class)
>
public class Foo {
public static void main(String[] args) {
// By Daffy's logic this means Object[] is not an Object.
Object[] o = new Object[] { };
System.out.println(o.getClass().isInstance(Object.class));
// So by Daffy's logic a String is not an Object either.
String s = new String();
System.out.println(s.getClass().isInstance(Object.class));
}
}
> Now you've done it, he's going to start claiming
> Strings aren't Objects now.
obviously i accidentally got that thing backword; but as for arrays, they are basically a primitive type in many languages, especially in c/c++. althoug it is true an array belongs to a class in java, and so does an int, a float, etc., from the data structure, it is merely a primitive type arranged into a class object as a design choice for the language, in other words, had there been no objects in java, arrays could still have existed.
> > Now you've done it, he's going to start claiming
> > Strings aren't Objects now.
>
> obviously i accidentally got that thing backword; but
> as for arrays, they are basically a primitive type in
> many languages, especially in c/c++. althoug it is
> true an array belongs to a class in java, and so does
> an int, a float, etc., from the data structure, it is
> merely a primitive type arranged into a class object
> as a design choice for the language, in other words,
> had there been no objects in java, arrays could still
> have existed.
Whether they 'could have been' some other way has no bearing on the fact that your advice, 'don't clone int arrays' is absolutely wrong.
> > > Now you've done it, he's going to start claiming
> > > Strings aren't Objects now.
> >
> > obviously i accidentally got that thing backword;
> but
> > as for arrays, they are basically a primitive type
> in
> > many languages, especially in c/c++. althoug it is
> > true an array belongs to a class in java, and so
> does
> > an int, a float, etc., from the data structure, it
> is
> > merely a primitive type arranged into a class
> object
> > as a design choice for the language, in other
> words,
> > had there been no objects in java, arrays could
> still
> > have existed.
>
> Whether they 'could have been' some other way has no
> bearing on the fact that your advice, 'don't clone
> int arrays' is absolutely wrong.
however, that only shows, beyond reasonable doubt, that java does pass object values by or as references.
> however, that only shows, beyond reasonable doubt,
> that java does pass object values by or as references.
No, it doesn't. Java passes Object references by value. You insistence to the contrary shows that you either don't understand the terms or are just too stupid to see what is plainly obvious.
> > however, that only shows, beyond reasonable doubt,
> > that java does pass object values by or as
> references.
>
> No, it doesn't. Java passes Object references by
> value. You insistence to the contrary shows that you
> either don't understand the terms or are just too
> stupid to see what is plainly obvious.
passing an object by reference or pointer always means a reference or a pointer is passed onto it, it has never been the othe way around. this is the wacky part of computer science you kludge will probablly never understand.
> > passing an object by reference or pointer always
> > means a reference or a pointer is passed onto it
>
> What part of "passing a reference" don't you
> understand?
i understand it all very well; but you could only understand a reference is passed by value in java and could not comprehend that it means the referenced object value is passed by or as the ref.
> i understand it all very well; but you could only
> understand a reference is passed by value in java and
> could not comprehend that it means the referenced
> object value is passed by or as the ref.
Your phrase "by or as the ref" is meaningless.
Moreover, you've just shown us yet another feature of Java that you don't understand (arrays) and still expect us to believe you - when we can read the JLS that specifically contradicts you?
Sheesh, you're dumber than I thought.
> > i understand it all very well; but you could only
> > understand a reference is passed by value in java
> and
> > could not comprehend that it means the referenced
> > object value is passed by or as the ref.
>
> Your phrase "by or as the ref" is meaningless.
>
> Moreover, you've just shown us yet another feature of
> Java that you don't understand (arrays) and still
> expect us to believe you - when we can read the JLS
> that specifically contradicts you?
>
> Sheesh, you're dumber than I thought.
as i have explained, ever since there are arrays, they are always a primitve type, even c++, even in java, they are made to be of a type of class as a language design, but if you look deeper, there is no class that defines it, it is in its nature a primitive type, but used as the base for things like arraylist objects. so i think it is merely a design choice, from the data storage, structure perspective, it is still a primitive type.
> as i have explained, ever since there are arrays,
> they are always a primitve type, even c++, even in
> java
There are languages which lack primitive types.
> , they are made to be of a type of class as a
> language design
Yes, much as the decision to pass by value is a "language design" feature. Since we're talking about Java, the design decisions which are embodied in the JLS are precisely what we're talking about.
What you're talking about is confined entirely to your own head.
> , but if you look deeper, there is no
> class that defines it, it is in its nature a
> primitive type
Everything is, when you get down to it, byte values. Did you have a point?
You keep doing this. You're proven wrong on a high level technical front, so you try to re-present the argument at a lower level. About which you are equally clueless.
> > > passing an object by reference or pointer always
> > > means a reference or a pointer is passed onto it
> >
> > What part of "passing a reference" don't you
> > understand?
>
> i understand it all very well; but you could only
> understand a reference is passed by value in java and
> could not comprehend that it means the referenced
> object value is passed by or as the ref.
I understand what you are saying. Everyone does but it doesn't change the fact that you are misusing precise computer science terms. Stop doing it.
Here's a plain language article that can explain this. I know this is a doomed attempt to get your head out of your *** but here it is:
http://javadude.com/articles/passbyvalue.htm
> > > if you are using Integer objects, then you would
> > have
> > > to clone them, because Integers are objects,
> they
> > are
> > > passed by or as references in java. if they are
> > not
> > > cloned, there will be just one set of objects.
> >
> > This is also wrong. Integers are immutable,
> whether
> > the variables are references is irrelevant.
>
> And I'm still waiting for you to demonstrate why it
> is necessary to copy the Integers but not the ints.
Still waiting.
> Still waiting.
when primitives are passed, they are always passed by value, meaning they are duplicated already, therefore you do not have to duplicate them again. the wrappers, Integer, for example, are objects, they are passed by references, so if you do not duplicate them, there will be just one set of them. i do not know why you are questioning this?
as for the article you listed, i was aware of it long time ago. it only shows how a confused person writes delusionally. ever since people figured out how to pass an address, rather than the whole value, followed by passing by pointers and then by references, params are not always the same as the values intended to be passed. as far as java is concerned, there are only two types of values: primitives and object values. when asked how there are paseed, the correct answer is: the former is passed by value, and the latter by or as references. and there are only two type params in java: primitives and references: they are passed by value. when a primitive is passed, it is passed by value: duplicated. when a reference is passed, the referenced object value is not duplicated.
in c++, a reference can be passed either by reference as an alieas or by value, duplicating the reference meaning duplicating the referenced object value as well. in java there is only one option, the reference is passed by value. pass by value means the acutal pram assigns its value to the formal param, the process itself does not necessary mean duplicating, it is just an assignment, may or may not result in duplication. in c++, it will, but not in java.
on swapping: it is delusional to think swapping is the norm. the norm is you can never swap values by swapping refs. it may seems you can do that in c++, but you need to be aware that ref assignment by default is a copy process...
got to stop for now.
> > Still waiting.
>
> when primitives are passed, they are always passed by
> value
As are reference values. Objects are not passed.
> , meaning they are duplicated already, therefore
> you do not have to duplicate them again.
The reason Objects don't have to be duplicated is quite simply because they are not passed.
References are always duplicated when they are passed. They are copied. Which is what pass-by-value means.
> the
> wrappers, Integer, for example, are objects, they are
> passed by references
They are not passed. References to them are passed.
etc.
> References are always duplicated when they are
> passed. They are copied. Which is what pass-by-value
> means.
one more thing:
in java references are not duplicated, they are simply assigned, from the actual param to the formal param:
formalParam = actualParam;
in java, it is not duplication. should this is a c++ code, it is duplicating, the result is the referenced objs are duplicated.
I think this endless discussion will have 500 replies again, like in:
[url=http://forum.java.sun.com/thread.jspa?threadID=208584&tstart=0]
BY VALUE OR BY REFERENCE I[/url]
[url=http://forum.java.sun.com/thread.jspa?threadID=208584&tstart=0]BY VALUE OR BY REFERENCE II - THE STORY CONTINUES...[/url][url=http://forum.java.sun.com/thread.jspa?threadID=661520&tstart=0]
BY VALUE OR BY REFERENCE III - THE VENGEANCE!!!
[/url][url=http://forum.java.sun.com/thread.jspa?threadID=663482&tstart=0]BY VALUE OR BY REFERENCE IV - THE FIGHT WILL CONTINUE, FOREVER!!!
[/url]
Lets break the current record!!! Lets post one thousand replies this time!!!
> > Still waiting.
>
> when primitives are passed, they are always passed by
> value, meaning they are duplicated already, therefore
> you do not have to duplicate them again. the
> wrappers, Integer, for example, are objects, they are
> passed by references, so if you do not duplicate
> them, there will be just one set of them. i do not
> know why you are questioning this?
Precisely, you don't know because you don't understand the basics of Java. That's fine but stop acting like you do.
You say that immutablilty doesn't matter because the Objects are passed by reference. I've challenged you to demostrate your assertion. You haven't done so so I will demostrate that you are wrong.
public class Test
{
public static void main(String[] args)
{
int i1 = 0;
Integer i2 = new Integer(0);
int[] array1 = {i1};
Integer[] array2 = {i2};
System.out.println(i1);
System.out.println(i2);
System.out.println(array1[0]);
System.out.println(array2[0]);
System.out.println();
change(i1);
change(i2);
change(array1);
change(array2);
System.out.println(i1);
System.out.println(i2);
System.out.println(array1[0]);
System.out.println(array2[0]);
}
// can't affect caller
public void changeInt(int i)
{
i = -1;
}
// can't affect caller because Integer is immutable
public void changeInteger(Integer i)
{
i = new Integer(-1);
}
// can affect caller
public void changeIntArray(int[] array)
{
for (int i = 0; i < array.length; i++)
array[i] = -1;
}
// can affect caller
public void changeIntegerArray(Integer[] array)
{
for (int i = 0; i < array.length; i++)
array[i] = new Integer(-1);
}
}
If you run this, you will see that the results are the same for the Object and primitive versions. Explain now how immutability doesn't matter and how the results of the above fit into your theory.
> in java, the ref is passed by value, the referenced
> obj is said to be passed by ref or as ref.
No it is not. That is not said. not by anyone who knows anything about Java. I don't understand how you can deny reality so consistently. I can find a hundred authoratative references that show you are wrong and you still claim this is what is 'said'.
> in java references are not duplicated, they are
> simply assigned, from the actual param to the formal
> param:
>
> formalParam = actualParam;
That is duplication, you cretin. Sure, the Object isn't duplicated, but the Object isn't passed at all.
The reference is duplicated (i.e. copied) and that's exactly what that does.
If it wasn't duplicated, you wouldn't be able to point the two references at different Objects.
> in java, it is not duplication. should this is a c++
> code, it is duplicating, the result is the referenced
> objs are duplicated.
In C++ it is duplication, in C it is in duplication, in Java it is duplication.
Is it time for me to call you stupid again? I think so.
> as for the article you listed, i was aware of it long
> time ago. it only shows how a confused person writes
> delusionally. ever since people figured out how to
> pass an address, rather than the whole value,
> followed by passing by pointers and then by
> references, params are not always the same as the
> values intended to be passed. as far as java is
> concerned, there are only two types of values:
> primitives and object values. when asked how there
> are paseed, the correct answer is: the former is
> passed by value, and the latter by or as references.
So you must think James Gosling is just confused... about the language he created? You really belive that? He created the language without understanding this basic concept? That's really what you believe?
> > Is it time for me to call you stupid again? I
> think
> > so.
>
> you have to be able to distinguish var assignment and
> duplication. they are two different things. or you
> can call yourself stupid or dumb or just about
> anything.
>
> got to go now. later:)
When you get back, don't forget to explain the results of the code I posted in 59.
> you have to be able to distinguish var assignment and
> duplication. they are two different things. or you
> can call yourself stupid or dumb or just about
> anything.
In Java they are identical.
int x = 42;
int y = x; // y contains a copy of x
Object j = "Hello";
Object k = j; // k contains a copy of j
Your problem is that you don't understand what a and b represent. They represent reference values. That's what get copied. They do not represent Objects.
Oh, and yes, you are mightily stupid.
> In Java they are identical.
> > int x = 42;
> int y = x; // y contains a copy of x
>
> Object j = "Hello";
> Object k = j; // k contains a copy of j
>
this is where you got confused:
x and y is pass by value, x and y are two different addresses containing a duplicated value of 42.
j and k is pass by reference. they are two refs pointing to a single object, the point is the object value is NOT duplicated.
to dub:
i guess when you were writing your stupid code, you probablly just hit your head in the toilet! do not you see you are pointing ref i to a new object? and further, your failure to affect the object is clearly due the immutability of the object, and has nothing to do with wheather it is pass by value or by ref or anything. it is such a simple thing, and do not you see it?
// can't affect caller because Integer is immutable
public void changeInteger(Integer i)
{
i = new Integer(-1);
}
> to dub:
>
> i guess when you were writing your stupid code, you
> probablly just hit your head in the toilet! do not
> you see you are pointing ref i to a new object? and
> further, your failure to affect the object is clearly
> due the immutability of the object, and has nothing
> to do with wheather it is pass by value or by ref or
> anything. it is such a simple thing, and do not you
> see it?
Well, this is what you said before:
> if you are using Integer objects, then you would have
> to clone them, because Integers are objects, they are
> passed by or as references in java. if they are not
> cloned, there will be just one set of objects.
So do I have to clone the Integer Objects or not? You said that if the OP used Objects instead of primitives, it would change they way he would have to protect his internal state. Are you contradicitng yourself now? If not explain why that is so.
> further, your failure to affect the object is clearly
> due the immutability of the object, and has nothing
> to do with wheather it is pass by value or by ref or
> anything. it is such a simple thing, and do not you
> see it?
No actually, I don't try to mutate the Integer Object, so what you are saying makes no sense. The code creates a new Integer because the Integer cannot be mutated i.e. it's immutable. If the Integer was pass-by-ref, the new Integer would be seen by the caller too.
> > if you are using Integer objects, then you would have
> > to clone them, because Integers are objects, they are
> > passed by or as references in java. if they are not
> > cloned, there will be just one set of objects.
>
> So do I have to clone the Integer Objects or not?
> You said that if the OP used Objects instead of
> f primitives, it would change they way he would have
> to protect his internal state. Are you contradicitng
> yourself now? If not explain why that is so.
the answer is yes. clone means to have duplicated object. keep your original objects, and let others mess with a clone is a good idea, if you see a need to protect your inner santuary from being disturbed, that is.
be reminded, an Integer object can still be modified using, reflection, for example.
> So you must think James Gosling is just confused...
> about the language he created? You really belive
> that? He created the language without understanding
> this basic concept? That's really what you believe?
what is percieved to be said really has not been said by anyone. james g merely said parameters passing in java employes only pass by value mechanism. he was pointing out a fact that in java references are passed by value, which differs what is percieved by many as the traditional norm that references are passed as alieas. the fact is references can be passed by value in c++ as well, but what adds the confusion is when refs are passed by value in c++, the referenced object values are also passed by value, while in java when the refs are passed by value, the referenced are not pass by value, they are said to be in essence passed by reference or passed as references.
> > > if you are using Integer objects, then you would
> have
> > > to clone them, because Integers are objects, they
> are
> > > passed by or as references in java. if they are
> not
> > > cloned, there will be just one set of objects.
> >
> > So do I have to clone the Integer Objects or not?
> > You said that if the OP used Objects instead of
> > f primitives, it would change they way he would
> have
> > to protect his internal state. Are you
> contradicitng
> > yourself now? If not explain why that is so.
>
> the answer is yes. clone means to have duplicated
> object. keep your original objects, and let others
> mess with a clone is a good idea, if you see a need
> to protect your inner santuary from being disturbed,
> that is.
But you just said it was obvious that you can't change the Integer. So which is it? Make up your mind, daffy.
And do you need to clone an array of ints? Before you said it was only necessary to clone an array of Integers, not ints. Now it seems you are saying that you need tto not only clone the array but also every Integer in the array.
> be reminded, an Integer object can still be modified
> using, reflection, for example.
This is dumb argument.They can also change the internal state of your own custom Objects. So even if you cloen a hundred times, you can't prevent reflection attacks. In any event, regardless of reflection, if somone is in intent on breaking the code, they will find a way to do it.
> > So you must think James Gosling is just
> confused...
> > about the language he created? You really belive
> > that? He created the language without
> understanding
> > this basic concept? That's really what you
> believe?
>
> what is percieved to be said really has not been said
> by anyone. james g merely said parameters passing in
> java employes only pass by value mechanism. he was
> pointing out a fact that in java references are
> passed by value,
This is exactly what everyone here tells you all the time. you constantly deny it, yet you call it a fact here. You are truly insane.
> > In Java they are identical.
> > > > int x = 42;
> > int y = x; // y contains a copy of x
> >
> > Object j = "Hello";
> > Object k = j; // k contains a copy of j
> >
> this is where you got confused:
You're the only person who's confused.
> x and y is pass by value, x and y are two different
> addresses containing a duplicated value of 42.
Roughly right; x and y identify two different addresses which contain (after execution) the value 42.
> j and k is pass by reference.
Wrong. j and k represent references.
> they are two refs
They are reference variables. j and k identify two different addresses which contain (after execution) a value.
That value is the address of the Object - but it's still a value, exactly the same as 42 is a value. It may be 42 for all you know.
> pointing to a single object
The variables contain values which point to the object.
>, the point is the object
> value is NOT duplicated.
Yes, because the object value is not what is passed. The "object value" is never passed. The reference values are passed, and the reference values are copied.
Hence "They represent reference values. That's what get copied. They do not represent Objects"
> i guess when you were writing your stupid code, you
> probablly just hit your head in the toilet!
I've never seen you post working code that you wrote yourself. On the few occasions when you post code at all it's cause for remark if it even compiles, let alone does what you claim.
Largely, no doubt, because your grasp of Java is based on your own fat headed opinions instead of actual facts.
> do not
> you see you are pointing ref i to a new object?
I don't use a reference called "i". I use a reference called j, and a reference called k. The references are pointed at the new object by copy*** the address value returned from the call to the constructor method into the memory address represented by the variables.
In exactly the same way that the primitive variables are assigned by copy*** the primitive value 42 into the memory address represented by the variables.
> and
> further, your failure to affect the object is clearly
> due the immutability of the object, and has nothing
> to do with wheather it is pass by value or by ref or
> anything. it is such a simple thing, and do not you
> see it?
This is unrelated to anything that I posted.
Daffy, you suffer first and foremost from poor English literacy, secondly from poor reasoning skills, and finally from sullen stupidity. But at least you're not Goldie.
[snip]
> to dub:
>
> i guess when you were writing your stupid code, you
> probablly just hit your head in the toilet! do not
> you see you are pointing ref i to a new object? and
> further, your failure to affect the object is clearly
> due the immutability of the object, and has nothing
> to do with wheather it is pass by value or by ref or
> anything. it is such a simple thing, and do not you
> see it?
>
> > // can't affect caller because Integer is immutable
> public void changeInteger(Integer i)
> {
>i = new Integer(-1);
> }
>
So this code you posted illustrates that it's the immutability of Integer that is the reason that this code can't effect the caller? So, if I used, say, StringBuffer (which is mutable) then this code could effect the caller? You mean (copying your code here, and just using a mutable class for Integer)// can affect(sic) caller because StringBuffer is mutable
public void changeStringBuffer(Stringbuffer sb)
{
sb = new StringBuffer("-1");
}
Care to explain yourself?
> can affect(sic) caller because...
While Daffy's English is generally indefensible, on this specific point I believe you are mistaken. "Affect" is correct.
To "effect" the caller would be to cause the caller to come into existence. Effect is more normally used as a noun, to mean the result of an affect.
Dave.
> > > can affect(sic) caller because...
> >
> > While Daffy's English is generally indefensible,
> on
> > this specific point I believe you are mistaken.
> > "Affect" is correct.
>
> ****. That's what I get for assuming.
Well, I was the one who orignall wrote the comment. Daffy just copied it. So your mistake was not assuming daffy was wrong (pretty safe bet) but assuming he wrote it.
