How do you make an array persistent?

[raylopez99]

I have an array that I wish to preserve as "read only". The array
holds references to variables myObjects instantiated by new that
change all the time.

The variables are part of a class that I used ICloneable on, namely
"Clone();" (deep and/or shallow copies worked the same for this
particular class).

Using ICloneable, I am able to successfully make a copy of the
variables like so:

myObjectsArray[j] = (MyObjects)X.Clone(); where X is foreach
(myObject X in myObjectsArray)

Everything is working fine except for one thing: I can only preserve
a copy of the array using IClone one time. After that, the array is
no good. But actually I'm quite happy even that this occurs, since my
purpose was to rollback the state of my program using myObjects just
once. So the program works. But I want to know for future reference
how to make the myObjectsArray persistent.

Do I make it 'readonly'? But this only seems to work for ints,
doubles, etc?

Do I use the template (found in a lot of books) of "memento design
pattern" (used in rollbacks)? It looks complicated, a bit of overkill
for this simple problem.

There is a chance that I'm messing up how I pass the 'read only"
array, myObjectsArray[].

Here is how I use it (perhaps I change it involuntarily?)
public void Rollback (myObjectsArray[] OASnapshot)
{

if (myObjectsList.Count != 0) { myObjectsList.Clear(); } //
clear list

myObjectsList = new
List<myObjects>(OASnapshot.Length); /

myObjectsList.AddRange(OASnapshot); //**
}

//** this works to repopulate the List with the 'old' values in
OASnapshot, which is exactly what I want. However, the second time I
call this method "Rollback", later on when the objects have changed
values, OASnapshot does not seem to have any of the 'old' information
of the objects, as I want, but in fact, OASnapshot seems to have
exactly the same information found in myObjectsList. Somehow
OASnapshot is not holding the old values (the second time around).
I tried using 'ref' for OASnapshot but same thing. I think what is
happening is that because of garbage collection, somehow OASnapshot is
not persistent.

Anyway, does this ring a bell with anybody?

RL

[raylopez99]

Well, I spoke too soon.

Turns out I didn't really have a solution after all (I assume so after
a quick check but it was premature).

Despite my best efforts tweaking the program, using "Clone" instead of
copy everywhere for arrays, using 'new' for arrays and doing a array
element by element clone copy from one array to another (even three
arrays in a row, A->B->C, in a vain attempt to get away from the
dreaded original reference), using Deep Copying for the Clone
function, and making every class I could think of as inheriting
ICloneable, I cannot get the array to be read more than once before it
changes state. That is, undo works just once.

I think the solution is like Marc Gravell said, and that involves
setting up a memento design pattern as I indicated in the OP.

Another solution, which is not really a solution, is to break down the
state you want to reconstruct into primitive data types (int, float,
etc), save this data, and 'reconstruct the state' using this data,
using functions in each of the interacting classes and as the program
dictates. But that 'solution' is hard work, just as hard or harder
than setting up a memento design pattern. In fact it nearly defeats
the purpose of 'undo' if you have to resort to such a drastic solution
(because after the undo you have to reconstruct the present state
too).

I consider this a defect of C#. You should be able to do this more
easily--there should be a library function that will preserve, in
immutable form, all references to mutable objects allowing you to
reconstruct the mutable objects as they were. Of course the memento
design pattern is such a solution, but what I'm saying is that this
memento design pattern should be built into C# as a language feature.
I heard the C# designers deliberately, unlike in C++, did not
introduce the 'const' (constant) keyword for reference objects/
variables, but this deliberate design choice is a defect IMO. A
'const' keyword would go a long way towards solving this problem,
though I'm sure some guru will point out that the IL engine working in
the background will be confused by a 'const' reference, since stuff
changes behind the scenes and nothing is constant save perhaps the
unboxed primitive data types (int, double, bool) on the stack.

RL

[raylopez99]

On Aug 9, 5:26*am, raylopez99 <[e-mail]:

Well, I spoke too soon.

Turns out I didn't really have a solution after all (I assume so after
a quick check but it was premature).

I found a 'solution' and it is rather inelegant--you just keep making
multiple copies of the state you want, then Push it into a Stack.
Then you Pop it from the stack when you want to "undo".

It's basically the same as what I said in my second post, but you
don't use arrays or lists, which were causing problems because of the
"Predicate" (this was a complicated class, and you needed to set up
the Predicate/Action <Tbecause the default apparently was not
working--too much bother, just use Stack)

Still, it would be nice to have something 'built into' the C# language
for readonly instead of depending on a inelegant programmers solution.

RL

[Cor Ligthert[MVP]]

Ray,

Serialize it and write it to disk.

Cor

"raylopez99" <ra********@yahoo.comschreef in bericht
news:1e**********************************@m3g2000h sc.googlegroups.com...

>I have an array that I wish to preserve as "read only". The array
holds references to variables myObjects instantiated by new that
change all the time.

The variables are part of a class that I used ICloneable on, namely
"Clone();" (deep and/or shallow copies worked the same for this
particular class).

Using ICloneable, I am able to successfully make a copy of the
variables like so:

myObjectsArray[j] = (MyObjects)X.Clone(); where X is foreach
(myObject X in myObjectsArray)

Everything is working fine except for one thing: I can only preserve
a copy of the array using IClone one time. After that, the array is
no good. But actually I'm quite happy even that this occurs, since my
purpose was to rollback the state of my program using myObjects just
once. So the program works. But I want to know for future reference
how to make the myObjectsArray persistent.

Do I make it 'readonly'? But this only seems to work for ints,
doubles, etc?

Do I use the template (found in a lot of books) of "memento design
pattern" (used in rollbacks)? It looks complicated, a bit of overkill
for this simple problem.

There is a chance that I'm messing up how I pass the 'read only"
array, myObjectsArray[].

Here is how I use it (perhaps I change it involuntarily?)
public void Rollback (myObjectsArray[] OASnapshot)
{

if (myObjectsList.Count != 0) { myObjectsList.Clear(); } //
clear list

myObjectsList = new
List<myObjects>(OASnapshot.Length); /

myObjectsList.AddRange(OASnapshot); //**
}

//** this works to repopulate the List with the 'old' values in
OASnapshot, which is exactly what I want. However, the second time I
call this method "Rollback", later on when the objects have changed
values, OASnapshot does not seem to have any of the 'old' information
of the objects, as I want, but in fact, OASnapshot seems to have
exactly the same information found in myObjectsList. Somehow
OASnapshot is not holding the old values (the second time around).
I tried using 'ref' for OASnapshot but same thing. I think what is
happening is that because of garbage collection, somehow OASnapshot is
not persistent.

Anyway, does this ring a bell with anybody?

RL

[Marc Gravell]

I consider this a defect of C#.
....

Still, it would be nice to have something 'built into' the C# language

Why? How many other similar languages offer this? C++? java? nope.
Arguably some *libraries* might offer this, but you need to think of
the language and the library as separate entities. Another approach is
to work with immutable objects; immutable objects tend to be more
common in java than C# - but by definition with an immutable object
you don't need to worry about changes... your downstream code might
have a slightly different *copy* of the data, but your upstream code
never, ever, has to care.

So perhaps consider using an immutable design...

Marc

[Peter Duniho]

On Sat, 09 Aug 2008 13:14:56 -0700, Marc Gravell <ma**********@gmail.com>
wrote:

>I consider this a defect of C#.

...

>Still, it would be nice to have something 'built into' the C# language

Why? How many other similar languages offer this? C++? java? nope.
Arguably some *libraries* might offer this, but you need to think of
the language and the library as separate entities. Another approach is
to work with immutable objects; immutable objects tend to be more
common in java than C# - but by definition with an immutable object
you don't need to worry about changes... your downstream code might
have a slightly different *copy* of the data, but your upstream code
never, ever, has to care.

So perhaps consider using an immutable design...

Anyone considering that should probably read Eric Lippert's comments on
the topic:
http://blogs.msdn.com/ericlippert/ar...y/default.aspx

I especially recommend the eleven-part series, starting here:
http://blogs.msdn.com/ericlippert/ar...utability.aspx

(Eleven parts makes it long for something found on a blog, but each part
is a nice, bite-sized piece. It's not really as hard a read as one might
think).

He starts with the idea of an immutable Stack implementation, and
gradually works out the techniques one might apply to creating more
complex collection type classes that are also immutable, in each case
doing his best to preserve efficiency by minimizing copies of the data.
The extent to which this is possible varies, but it's a pretty cool
exercise.

Pete

[raylopez99]

On Aug 9, 9:51*am, "Cor Ligthert[MVP]" <[e-mail]>
wrote:

Ray,

Serialize it and write it to disk.

Cor

Turns out whether you do a deep copy (Serialization) or shallow copy
(MemberwiseClone) the result is the same--success--if you follow the
protocol in this thread, and push/pop the state repeatedly, after
using :ICloneable as the base class for the stuff being cloned.

Trick stuff.

RL

[raylopez99]

On Aug 9, 1:14*pm, Marc Gravell <[e-mail]:

>
So perhaps consider using an immutable design...

Marc

I'm still learning so I appreciate your feedback, and what you
consider (if it's encapsulated in a few words) as "immutable design".
I know strings are immutable, unless you use StringBuilder, but I'm
not sure what an immutable design is.

Anyway, for this project the problem was solved, after a whole day and
half the night beating out my brains trying different things (what
else is new, it's programming in C#).

RL

[Marc Gravell]

or shallow copy (MemberwiseClone)

I suspect you might run into a few issues if you are using nested data
structures... you might have captured obj.Foo, but not necessarily
obj.Bar.Something.Whatever[2].TheOther (if you see what I mean). But
if you have solved your immediate issue, then fine...

Marc

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Marc Gravell wrote:

Another approach is
to work with immutable objects; immutable objects tend to be more
common in java than C# - but by definition with an immutable object
you don't need to worry about changes... your downstream code might
have a slightly different *copy* of the data, but your upstream code
never, ever, has to care.

I am not so sure Java is more into immutable than C#.

In C# structs are bring the immutable discussion on the table.

Java comes with a few immutable classes and it has also
been recommended for programmers to create immutable classes.
But that recommendation has never caught on.

Arne

[Marc Gravell]

In C# structs are bring the immutable discussion on the table.

Now if only we could stop people from creating mutable structs...

[and then asking "why doesn't this work? No: I won't change my design
- but make it work for me anyway?"]

Marc

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Marc Gravell wrote:

>In C# structs are bring the immutable discussion on the table.

Now if only we could stop people from creating mutable structs...

[and then asking "why doesn't this work? No: I won't change my design
- but make it work for me anyway?"]

So you want the immutable keyword:

public immutable struct FooBar {

or

public readonly struct FooBar {

?

Actually I think that could be very useful (and they should
add it to class as well).

I assume that the semantics is that only the constructor
can change the state.

I wonder if there are any implementation issues.

Arne

[Pavel Minaev]

On Aug 12, 4:15*am, Arne Vajhøj <[e-mail]:

Marc Gravell wrote:

In C# structs are bring the immutable discussion on the table.

Now if only we could stop people from creating mutable structs...

[and then asking "why doesn't this work? No: I won't change my design
- but make it work for me anyway?"]

So you want the immutable keyword:

public immutable struct FooBar {

or

publicreadonlystruct FooBar {

?

Actually I think that could be very useful (and they should
add it to class as well).

I assume that the semantics is that only the constructor
can change the state.

I wonder if there are any implementation issues.

Not that I know of. Interestingly enough, there is a Connect ticket
for this feature request since 2004, presently in state "Closed
(Postponed)':

https://connect.microsoft.com/Visual...edbackID=91971

Go ahead and vote for it, and perhaps we'll see it implemented - not
in C# 4.0, it seems, but maybe in the version after that.