From: Phil Hunt on
I have a simple object I load up from DB, Is there a easy way to clone it to
a new object of the same type ?

Thanks


From: ralph on
On Mon, 9 Aug 2010 19:15:55 -0400, "Phil Hunt" <aaa(a)aaa.com> wrote:

>I have a simple object I load up from DB, Is there a easy way to clone it to
>a new object of the same type ?
>

Probably not. <g>

Depends on what you mean by "clone", ie, how much of a duplicate/copy
do you need, or if you even need one?

Cloning 'data' always takes you into the realm of "Shallow Copies" or
"Deep Copies", but in some cases it isn't the data but the objects's
behavior or state we want to 'clone'. (The ADO Recordset.Clone is an
example of the latter.)

We need more information.

-ralph
From: phil hunt on
I am more interested in the data. As I am changing data, I want to 'undo'
the change just by reverting back to the clone.


"ralph" <nt_consulting64(a)yahoo.net> wrote in message
news:haa166hspc24r3esjk8h0u712u2jebjcng(a)4ax.com...
> On Mon, 9 Aug 2010 19:15:55 -0400, "Phil Hunt" <aaa(a)aaa.com> wrote:
>
>>I have a simple object I load up from DB, Is there a easy way to clone it
>>to
>>a new object of the same type ?
>>
>
> Probably not. <g>
>
> Depends on what you mean by "clone", ie, how much of a duplicate/copy
> do you need, or if you even need one?
>
> Cloning 'data' always takes you into the realm of "Shallow Copies" or
> "Deep Copies", but in some cases it isn't the data but the objects's
> behavior or state we want to 'clone'. (The ADO Recordset.Clone is an
> example of the latter.)
>
> We need more information.
>
> -ralph


From: ralph on
On Mon, 9 Aug 2010 21:41:28 -0400, "phil hunt" <a(a)abc.com> wrote:

>I am more interested in the data. As I am changing data, I want to 'undo'
>the change just by reverting back to the clone.
>
>

Don't know what your 'data' looks like, but assuming it is a group of
properties, this is often accomplished by storing the last value for
each of your properties/attributes as a backup. Which is something I
figure you have already considered. Takes a bit of work.

It means everytime you change something, you have to reassign the
'backup'. If for some reason you want to undo, you either have to
create new 'Undo' method for each value, or do a blanket 'put-back'.

So it depends on how and when you feel you might need to undo, and the
granularity - per item, per process, per run, etc.

Perhaps 'Serialization' would be something to look into. For objects
that actually refers to packaging up all the data/state, etc and
trasporting it, or storing it, so you can come back later and read the
info to recreate the object. But you can also simply considered the
serialized data as a backup.

Your object would have a 'Save' method, just before you planned to do
something dangerous, where it simply stores everything. Then an 'Undo'
on an Oops. <g>

This also has the advantage of being able to perform muliple undos.

For an example, I have often done this for disconnected
ADODB.Recordsets, by wrapping the Recordset with my own object. Then
use the contained Recordset.Save feature to store a copy to a file.
Bang around on the original Recordset, then if I have to go back,
reload a new from the file.

But again it depends on what is needed for YOUR problem domain.

Any option you chose will look like a lot of typing, thus not easy,
but once you pick a particular strategy, most of it will be
boiler-plate.

-ralph
From: ralph on
On Mon, 09 Aug 2010 21:28:53 -0500, ralph <nt_consulting64(a)yahoo.net>
wrote:

>On Mon, 9 Aug 2010 21:41:28 -0400, "phil hunt" <a(a)abc.com> wrote:
>
>>I am more interested in the data. As I am changing data, I want to 'undo'
>>the change just by reverting back to the clone.
>>
>>
>

Another strategy that is occasionally useful, is based on a timeless
principle of programming: "There is no problem that can't be resolve
with another layer of indirection". <g>

Wrap your object with one that combines a factory with storage.

-ralph