how to make an instance equal to another

Hey, say I have two instances of a class, A and B: how do I make the first instance "equal" to the second in all fields?

A=B passes a pointer and screws

I create an Assign method on my objects.

Type TMyType
   Field A%
   Field B%

   Method Assign(P_source: TMyType)
      A% = P_source.A%
      B% = P_source.B%
   End Method

End Type

local aType: TMyType
local bType: TMyType

aType = New TMyType
bType = New TMyType

aType.A% = 100
aType.B% = 200

bType.Assign(aType)

'
' bType now has all the same values as aType but is a
' different Instance.
'

I create a "Deep Clone" of mine:

Type TVector
	Field xcomponent:Double, ycomponent:Double

	Method deepClone:TVector()
		Local myVector:TVector = New TVector
		myVector.xcomponent = xcomponent
		myVector.ycomponent = ycomponent
		Return myVector
	End Method
End Type

then you just invoke it as if you where creating a new object:

myVectorAClone = myVectorA.deepClone()

Idealy such behaviour should be determined by an Interface, but BlitzMax sadly doesn't have those.

This works in much the same way as the technique above, except it makes it somewhat simpler to make a copy of composite objects (objects that contain other objects), providing they also have a deepClone method (which you could have enforced with an Interface).

no automatic method... crazy!

Do other languages support this?

It's not possible.

No. All other languages also have some sort of "IClonable" interface you have to implement.

It is possible using memcopy and byte ptr conversion.

Method clone:Type ()
		' actually not implemented!
		Local t:Type  = new Type 
		MemCopy(Byte Ptr (t), Byte Ptr (Self),SizeOf(Self))
		Return t
	End Method

I'm not sure if memcopy copies the data (fields) of the object or it's internal pointers. Be careful.

Once you have the process in a type method isn't it the same as being automatic? I thought this was the beauty of having the source code. If something is missing you can add it.

It contains the same data as the original. if it was a reference in the original the copy will be as well

Data in types is not stored contigously, the contigous data conteined by are pointers, so you copy the pointers but not the data, so you access to the same data, not to a copy of the same data. And I don't know how this may affect the reference counting of fileds that are instances of other objects.

one supposes that there should be a built in thing that does that. After all it's a pretty natural feature to say A=B and expect A to be a copy of B, maybe with some other notation to distinguish it from the pointer pass.

Is there some precise technical reason why this is not done, i.e. is it "theorically impossible"?

Najdorf: yeah, in a way, I think it is theoretically impossible. With the addition of pointers to a language, you can't always know what to copy.

Lets say that the object you wanted to copy had a reference to another object, and each of these referenced objects were unique to the object you're copying. In this case, you would want to copy the referenced object as well. However, in another example, lets say the object you wanted to copy referenced to a master object, so to speak, which kept a list of all objects for it. In this case you wouldn't want to copy the referenced object.

So it all comes down to the kind of data structure you have. Rather than setting up a bunch of keywords to decide what gets copied and what doesn't, it's probably easier anyway to simply code up a copying routine.

Anyone else agree, or am I way off track?

Dreamora's way is the quickest and best, as far as I'm concerned.

Yeah I understand that there might be problems with objects containing themselvs or containing a superset of themselvs or that kind of stuff.

Wait a sec, how can an object reference a master object? (Not certainly with "field")

I don't understand why this can't be built in, couldn't it just generate the code for the copy function for you?

That sounds about accurate to me.

Yeah. Too bad it doesn't work. (As in it's not a deep clone, just a shallow one).

Why not? Many GUI's have parent container type classes...

No. Because the compiler cannot read your mind, and even if it could, it would screw up when someone with a different mind tried to compile your source. :o>

What if it just makes all the new fields equal the same thing as the old instance. The new one's pointers will point to the same address as the old instance does.