Suppose I have two classes: ComplexThing, and Thing.

ComplexThing is a composite object, made up of Things, which has some special powers as a result (night vision, omnipotence, etc.). It has a simple variable, Things, which is an ArrayList, and holds all Things that make up ComplexThing.

ComplexThing has a method, getThings(), which returns all the Things from which it's made:

I have another class, Thingulator, which operates on ComplexThings.

ArrayList theseThings = bigThing.getThings();

Obviously, aThing gets removed from theseThings, but does it also get removed from ComplexThings.Things? I have a sinking feeling it does, as this makes perfect sense, given the whole idea of referencing, but that would also kind of suck if it did. I think there are a few places where I've done this sort of "removal", without realizing how far-reaching the references are...

Also, if my fears are well-founded, is the only way around it a deep copy of ComplexThings.Things? I'm guessing so, but that also kind of sucks, as deep copies in Java are such a pain (why has this not been made simpler, over the years?).

ArrayList getThings()     {return Things;}

if(theseThings.contains(aThing))
   theseThings.remove(aThing);

perils-of-referencing

ArrayList getThings() { return Things.clone(); }

Then at least you have a copy that you can mess with in your 

Thingulator, and removing items from there shouldn't delete them in 

your ComplexThing. You don't really want a deep copy do you, just a 

shallow copy of the actual ArrayList so you can mess with it in the 

Thingulator, while leaving the management of the Thing object 

lifetimes to the Things array in ComplexThing? Your sinking feeling 

should be easy to verify with a small test class..

> Suppose I have two classes: ComplexThing, and Thing.

> ComplexThing is a composite object, made up of Things, which has 

> some special powers as a result (night vision, omnipotence, etc.). 

> It has a simple variable, Things, which is an ArrayList, and 

> holds all Things that make up ComplexThing.

> ComplexThing has a method, getThings(), which returns all the Things 

> I have another class, Thingulator, which operates on ComplexThings.

> ArrayList theseThings = bigThing.getThings();

> Obviously, aThing gets removed from theseThings, but does it also 

> get removed from ComplexThings.Things? I have a sinking feeling it 

> does, as this makes perfect sense, given the whole idea of 

> referencing, but that would also kind of suck if it did. I think 

> there are a few places where I've done this sort of "removal", 

> without realizing how far-reaching the references are...

> Also, if my fears are well-founded, is the only way around it a deep 

> copy of ComplexThings.Things? I'm guessing so, but that also kind of 

> sucks, as deep copies in Java are such a pain (why has this not been 

Couldn't you say
ArrayList getThings() { return Things.clone(); }

Then at least you have a copy that you can mess with in your  
Thingulator, and removing items from there shouldn't delete them in  
your ComplexThing. You don't really want a deep copy do you, just a  
shallow copy of the actual ArrayList so you can mess with it in the  
Thingulator, while leaving the management of the Thing object  
lifetimes to the Things array in ComplexThing? Your sinking feeling  
should be easy to verify with a small test class..

>
> Hello All,
>
> I need to clear something up...
>
> Suppose I have two classes: ComplexThing, and Thing.
>
> ComplexThing is a composite object, made up of Things, which has  
> some special powers as a result (night vision, omnipotence, etc.).  
> It has a simple variable, Things, which is an ArrayList, and  
> holds all Things that make up ComplexThing.
>
> ComplexThing has a method, getThings(), which returns all the Things  
> from which it's made:
>
> ArrayList getThings()     {return Things;}
>
> I have another class, Thingulator, which operates on ComplexThings.
>
> if Thingulator does something like:
>
> ComplexThing bigThing;
> Thing aThing;
>
> ArrayList theseThings = bigThing.getThings();
>
> if(theseThings.contains(aThing))
>   theseThings.remove(aThing);
>
> Obviously, aThing gets removed from theseThings, but does it also  
> get removed from ComplexThings.Things? I have a sinking feeling it  
> does, as this makes perfect sense, given the whole idea of  
> referencing, but that would also kind of suck if it did. I think  
> there are a few places where I've done this sort of "removal",  
> without realizing how far-reaching the references are...
>
> Also, if my fears are well-founded, is the only way around it a deep  
> copy of ComplexThings.Things? I'm guessing so, but that also kind of  
> sucks, as deep copies in Java are such a pain (why has this not been  
> made simpler, over the years?).
>
> Any clarification welcome.
>
> cheers,
>
> J.
>
>


That's right. Except for primitives, everything in Java is a 

reference to an object somewhere in memory, and it's the reference 

that you're passing around. There's a book called Effective Java by 

Josh Bloch which I found quite useful on such topics, and recommended 

by many. It's very readable, and not too heavy.

On 7 Feb 2008, at 19:59, jbmaxwell wrote:

> ComplexThing has a method, getThings(), which returns all the 

> Also, if my fears are well-founded, is the only way around it a 

> deep copy of ComplexThings.Things? I'm guessing so, but that also 

> kind of sucks, as deep copies in Java are such a pain (why has this 

> not been made simpler, over the years?).

That's right. Except for primitives, everything in Java is a  
reference to an object somewhere in memory, and it's the reference  
that you're passing around. There's a book called Effective Java by  
Josh Bloch which I found quite useful on such topics, and recommended  
by many. It's very readable, and not too heavy.

>
> Hello All,
>
> I need to clear something up...
>
> Suppose I have two classes: ComplexThing, and Thing.
>
> ComplexThing is a composite object, made up of Things, which has  
> some special powers as a result (night vision, omnipotence, etc.).  
> It has a simple variable, Things, which is an ArrayList, and  
> holds all Things that make up ComplexThing.
>
> ComplexThing has a method, getThings(), which returns all the  
> Things from which it's made:
>
> ArrayList getThings()     {return Things;}
>
> I have another class, Thingulator, which operates on ComplexThings.
>
> if Thingulator does something like:
>
> ComplexThing bigThing;
> Thing aThing;
>
> ArrayList theseThings = bigThing.getThings();
>
> if(theseThings.contains(aThing))
>    theseThings.remove(aThing);
>
> Obviously, aThing gets removed from theseThings, but does it also  
> get removed from ComplexThings.Things? I have a sinking feeling it  
> does, as this makes perfect sense, given the whole idea of  
> referencing, but that would also kind of suck if it did. I think  
> there are a few places where I've done this sort of "removal",  
> without realizing how far-reaching the references are...
>
> Also, if my fears are well-founded, is the only way around it a  
> deep copy of ComplexThings.Things? I'm guessing so, but that also  
> kind of sucks, as deep copies in Java are such a pain (why has this  
> not been made simpler, over the years?).
>
> Any clarification welcome.
>
> cheers,
>
> J.
>
>


Oh yeah, jeepers... You're right. A deep copy would copy all the Things in the ArrayList, as well, wouldn't it! I just want a copy of the ArrayList itself. Good point.

I don't know if I'll change my accessor method, but I get the idea.

ArrayList theseThings = bigThing.getThings().clone();

That would leave my accessor method getThings() untouched, and a bit more efficient for most situations.

It does make sense to me, actually, but I like to get confirmation on things before I commit them to the "learned" pile... Passing references around is generally really handy, so I suppose it's not fair of me to complain about it now! ;-)

oh, duh... I just looked over some of my older code, and it looks like I've generally used something more like this:

theseThings.addAll(ComplexThing.getThings());

That avoids the problem, too, doesn't it?

You should grab Effective Java book that Oliver mentioned. It has some 

good tips in this area, including defensive copying. Its a good habit 

to let the callee do the copying, as you can't always control who the 

caller is (for example if you're writing a library that provides your 

Things to third party clients, they may accidentally do something 

malicious to it (as you have perhaps discovered)).

Worry about efficiency when it becomes a problem, make sure it's 

> Oh yeah, jeepers... You're right. A deep copy would copy all the 

> Things in the ArrayList, as well, wouldn't it! I just want a copy of 

> I don't know if I'll change my accessor method, but I get the idea.

> ArrayList theseThings = bigThing.getThings().clone();

> That would leave my accessor method getThings() untouched, and a bit 

> It does make sense to me, actually, but I like to get confirmation 

> on things before I commit them to the "learned" pile... Passing 

> references around is generally really handy, so I suppose it's not 

> fair of me to complain about it now! ;-)

You should grab Effective Java book that Oliver mentioned. It has some  
good tips in this area, including defensive copying. Its a good habit  
to let the callee do the copying, as you can't always control who the  
caller is (for example if you're writing a library that provides your  
Things to third party clients, they may accidentally do something  
malicious to it (as you have perhaps discovered)).

Worry about efficiency when it becomes a problem, make sure it's  
correct first =)

>
> Oh yeah, jeepers... You're right. A deep copy would copy all the  
> Things in the ArrayList, as well, wouldn't it! I just want a copy of  
> the ArrayList itself. Good point.
>
> I don't know if I'll change my accessor method, but I get the idea.
>
> Is it possible to do something like:
>
> ArrayList theseThings = bigThing.getThings().clone();
>
> That would leave my accessor method getThings() untouched, and a bit  
> more efficient for most situations.
>
> J.
>
> --------------
>
> Thanks Ollie.
>
> It does make sense to me, actually, but I like to get confirmation  
> on things before I commit them to the "learned" pile... Passing  
> references around is generally really handy, so I suppose it's not  
> fair of me to complain about it now! ;-)
>
> cheers.
>
>


Okay, sounds good. I'll try to track down the book.

It's interesting that the callee would be a better place for the copy. I would have thought that such an accessor would be best left really simple in the callee. But it does make sense to do the copying there, as it is "safer", preventing callers from mucking about with the data - as you pointed out (and as I experienced!).

I suppose I could have both the simple accessor getThings() and a "safer" one, getCopyOfThings(). But maybe there's not much point...

Anyway, good to know... I really appreciate when a post helps me *think* about something from a different angle. It's nice to be given some insight into the reason for a particular practice, not just a "do this" reply - though I realize it takes more time to explain. 

Quote: maxmspjit wrote on Thu, 07 February 2008 23:27

----------------------------------------------------

> You should grab Effective Java book that Oliver mentioned. It has some 

> good tips in this area, including defensive copying. Its a good habit 

> to let the callee do the copying, as you can't always control who the 

> caller is (for example if you're writing a library that provides your 

> Things to third party clients, they may accidentally do something 

> malicious to it (as you have perhaps discovered)).

> Worry about efficiency when it becomes a problem, make sure it's 

> > Oh yeah, jeepers... You're right. A deep copy would copy all the 

> > Things in the ArrayList, as well, wouldn't it! I just want a copy of 

> > I don't know if I'll change my accessor method, but I get the idea.

> > ArrayList theseThings = bigThing.getThings().clone();

> > That would leave my accessor method getThings() untouched, and a bit 

> > It does make sense to me, actually, but I like to get confirmation 

> > on things before I commit them to the "learned" pile... Passing 

> > references around is generally really handy, so I suppose it's not 

> > fair of me to complain about it now! ;-)

Okay, sounds good. I'll try to track down the book. 

Anyway, good to know... I really appreciate when a post helps me *think* about something from a different angle. It's nice to be given some insight into the reason for a particular practice, not just a "do this" reply - though I realize it takes more time to explain. 
So, thanks for that.

Quote: maxmspjit wrote on Thu, 07 February 2008 23:27
----------------------------------------------------
> You should grab Effective Java book that Oliver mentioned. It has some  
> good tips in this area, including defensive copying. Its a good habit  
> to let the callee do the copying, as you can't always control who the  
> caller is (for example if you're writing a library that provides your  
> Things to third party clients, they may accidentally do something  
> malicious to it (as you have perhaps discovered)).
>
> Worry about efficiency when it becomes a problem, make sure it's  
> correct first =)
>
> r.
>
> On 7-Feb-08, at 1342, jbmaxwell wrote:
>
> >
> > Oh yeah, jeepers... You're right. A deep copy would copy all the  
> > Things in the ArrayList, as well, wouldn't it! I just want a copy of  
> > the ArrayList itself. Good point.
> >
> > I don't know if I'll change my accessor method, but I get the idea.
> >
> > Is it possible to do something like:
> >
> > ArrayList theseThings = bigThing.getThings().clone();
> >
> > That would leave my accessor method getThings() untouched, and a bit  
> > more efficient for most situations.
> >
> > J.
> >
> > --------------
> >
> > Thanks Ollie.
> >
> > It does make sense to me, actually, but I like to get confirmation  
> > on things before I commit them to the "learned" pile... Passing  
> > references around is generally really handy, so I suppose it's not  
> > fair of me to complain about it now! ;-)
> >
> > cheers.
> >
> >
>
>
----------------------------------------------------


perils of referencing