Objects - to copy or not to copy?

Carl Sassenrath, CTO
REBOL Technologies
22-Aug-2009 15:58 GMT

Article #0239
Main page || Index || Prior Article [0238] || Next Article [0240] || 15 Comments || Send feedback


This article has been updated and sorry that I am repeating the same issues as discussed in #212. Sometimes, it seems that the "continuation" stack is not large enough. Anyway, a more specific article is being prepared and will be posted soon.

In R3, object creation from a parent object will deep copy internal strings, blocks, and objects, but not images and vectors.

There are advantages and disadvantages to this policy. By deep copying, you don't need to worry about conflicts in sharing. Each object has its own copies. But, the cost is memory. If your object contains a 10K string, every instance of it will add another 10K.

Maxim's recent posting on CureCode about this topic has got me thinking that we don't want to deep copy by default. This allows developers to be smart about their code. They don't have to chew up memory if they don't want to.

This issue is fairly major, and we need to finalize it soon in order for R3 to go beta. Not much code is written for R3 yet, so we won't break too much (mainly the GUI code - depends heavily on objects.)

And, it would be possible to write...

obj: make copy/deep parent [...]

for those that want it. (That code deep copies the parent object values before creating the new object.)


Updated 23-Mar-2017 - Edit - Copyright REBOL Technologies -