SharedObject unexpected behavior or bug?

[dmennenoh]

var a:SharedObject = SharedObject.getLocal("test");

trace(a.data.userData);

var d:Array = [1,2];

a.data.userData = d;

a.flush();

d.shift();

I find this behavior odd. If you run this, the first time you'll get nothing in the trace as userData hasn't been initialized. The second time you will get just '2' traced, when I'd expect '1,2'. I find it odd because I've called flush to commit the SO changes to disk. However doing a shift on the array affects the array in userData. I get passed by reference and all, but I think this amounts to a bug - affecting it after the flush() has been run. I've probably seen this before but it caught me off-guard yesterday and took some looking to figure out what was happening.

[kglad]

a.data.userData is a deep copy of the array d.

if you want a shallow copy use the slice method:

a.data.userData=d.slice();

[dmennenoh]

Right. Like I said, I get the pass by reference. I just think once you do a flush the data in the SO should not be affected. Call it what you want, I find it strange behavior.

[kglad]

the flush() method is irrelevant.

this is expected behavior of deep copies of an array whether in actionscript or any other programming language.  once you understand deep vs shallow array copies, you won't find it baffling.

in brief:

var a:Array = [1,2];

var b:Array = a;  // deep copy.

a.push(3);

trace(b);  // 1,2,3 expected

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

var a:Array = [1,2];

var b:Array = a.slice();  // shallow copy

a.push(3);

trace(b);  // 1,2 expected

[dmennenoh]

I do not find it baffling. But thanks for the lesson anyway.

[kglad]

then you're, at least, one step ahead of me because i sure found it strange when i first encountered it.

and you're welcome.

[Andrei1-bKoviI]

This is quite an interesting finding about ShareObject and its handling...

Does it mean that SO retains reference to an object while application is running and writes a value when application closes? Or, perhaps, another way to look at it is that SO instance is held in Flash memory until application is killed? Adobe description states that there are extra processes occurring when application is closing besides automatic  flush(). Is this behavior a manifestation of such behavior?

Did you experiment with this use case?

[kglad]

the so stored in memory is updated by flash at indeterminate times, similar to the way garbage collecting is indeterminate.  however, unlike gc, you can direct flash to update the stored so by using the flush() method.

when you update an so in flash it typically will be updated in memory so quickly that it's difficult (but possible) to close/crash a swf so quickly after an so updates that it fails to save that update to memory.  it's not possible to do that if you execute a flush() after the update.

and this topic is not about so's.  it's about arrays, shallow vs deep. 

it just happend that the op discovered this (shallow vs deep) 'issue' when using an so.data property as a deep copy of an array.  the same 'issue' would be found if a more typical copy (of one array assigned to another array)  were used.

[Aaron Beall]

Forgive me if I misundstood this thread, but it seems like dmennenoh understood the array behavior, just not the SharedObject state behavior. It looks like he assumed that SO data is only saved via flush(). In fact, under normal circumstances, the current state of data of an SO will be written when the SWF is closed, as long as local storage is allowed by the user's Flash Player settings. Using flush() is mostly provided as a way to let your program resolve problems with saving, like prompt the user for more storage space, or deal with write permission problems -- things that you don't have the chance to resolve when the SWF is closing.

Sorry if I simply re-stated what's already been said.

-Aaron

[dmennenoh]

Right, the original issue was not about arrays. My error was in thinking that the flush() somehow severed the link between the array and the object on disk... because it was now written to disk. I expected to have to issue another flush() to update the object, and was surprised when I didn't.

As kglad said: the flush() method is irrelevant.