Re: Using collections

[glen e. p. ropella]

> Thanks, Glen.

No problem.

> 1. If you pass a collection to another class which in turn
> creates another reference to the same collection.  Then, in
> the original class, the collection goes out of scope. The
> second class now has a dangling reference, right?
> 
> For example:
>    Our agents are given a list of goals (coordinates) to
> attain. As the agent approaches it current goal, the goal is
> set to the next on the list.  (BTW, goals are analogous to a
> carrot on a stick, i.e. all other things being equal, the
> agent will move towards its goal... but, I digress...)
> 
>    The goal list is created in the model swarm's build
> objects method and passed to the agent.  The goal list is
> local to the build objects method and should therefore be
> "freed" when the build objects method returns.
> 
>    However, after trying it both ways, it doesn't seem to
> matter whether the receiving agent copyies the goal 
> list or simply makes a reference to the list.  ...Hmmm?
> ...Perhaps this is blind luck?

Excellent question!!!  As a matter of fact, the hive's been discussing
this very issue recently.

Anyway, if the "list" you're "copying" or "simply making a reference
to" is an instance of the List class, then no matter what you do, the
objects in the list stay put wherever they happen to be in memory.
That's the first thing to realize.  In order to get rid of them, you
would need to a) remove each one from the list then b) drop each one.

Now, when you "pass a reference" pointing to the list to some other
piece of the program, then the List, which is really just a bunch of
links between the objects, remains intact and usable as such.

When you "copy" the list, however, a new bunch of links is created
linking all those same objects together, then the pointer to the new
list is passed wherever.

So, the simple answer to your question is, "No."  The second list
consists of valid links to still resident objects in memory, whether
you use "copy" or pass a pointer.

In order to generate the error you're expecting, you would have to
"drop" the List object (regardless of whether you successfully
"drop"ped all the objects on the list) and try to reference it via a
passed pointer.  If you plan on dropping the list, then you have to
use "copy."

Am I making sense here?  Sometimes I ramble without saying anything
understandable.


> 2. I've discovered that a list index doesn't perform any
> bounds checking in the "next" method.  That is, if you call
> [index next] when you are at the "End" of the list, then you
> get a core dump.
> 
>    However, [index getLoc] doesn't return "End" until after
> you moved past the last list element.  Therefore, when I'm
> traversing the list, I test two conditionals:  
>      ([index getLoc] != End) and ([index next] != nil).
> 
>    Have I overlooked an more direct way of stopping at the
> end of a list?  Is there a method to "peek" ahead without
> moving the index?  Perhaps the "getOffset" method can be
> used to accomplish this?

I'm not sure what the problem is, here.  The first statement I understand.
If one has a list: