World: r3wp

and yes the span (# of columns) is the same  for sorting and skipping

so no prob, if you don't insert or remove data

Right. I am more concerned with movement that happens *before both* 
of the two references. That is what can mess up positions.

the initial offset  (which column)  the sort is on changes, but that 
is 
sort/skip/compare/part  ref1 span   column  ref2

Brian's concern is what does this sort do to ref5 and ref 6  position. 
are they still valid.

time to experiment

as this is building a tree, structure later operations always occur 
strictly within earlier operation boundaries

thanks Brian and Steeve. good night

Good night.

how can this avoided?


does a object! defined within a object! (embedded) breaks with the 
clone/ingherit rule?

calling a function within a object! which e.g. changing a value within 
the embedded object!
changing the parent AND the child object!.

template: make object! [
	obj-in-obj: 	make object! [a: make integer! 0]
	b: 		make integer! 0
	c: func [val] [
		obj-in-obj/a:   val
		b:		val
	]
]  

wcopy: make template []
probe template
probe wcopy
wcopy/c 1000
probe template
probe wcopy

what I am doing wrong here?
and is there any easy way to clear a object at once
without resetting every single variable in the object

I have a big loop (20.000+) which fills many objects with datas.
the objects contains also functions writing and calculating
data within other objects (all within a global context/object). 

each loop is a new run, so I need a new or cleared set of objects 

for every loop. looks like cloning doesn't work for me (see above). 

I could reset every single value, but this will cost me a day minimum.

do I overseen some simple solution here?

Not sure what your trying to do but in your function change the object 
reference to self such as:

self/obj-in-obj/a:

see if that makes a difference

Why you do not make your template just an unevaluated block and then 
you always generate a new object or you never change your template, 
just the descendants ?

Its by design : subojbect are not copied by 'make. All R2 VID is 
build on this concept (shared objects).

You need a 'make-deep function that (recursively ?) digg into the 
copied object and copy each subobject it find. I'm sure people arround 
have one in their HD (not me).

paul, makes no difference..sqlab, wrap the object into a unevaluated 
block?

DideC, yes I guessed that. thx

a copy/deep second or third object! doesn't work either.

Have you considered using a construct?

paul, I never used construct. can it serve nested constructs also?

will take a look into the docs about it...

does this work?

create-template: func [ d [integer!]
] [
	make object! [
		obj-in-obj: 	make object! [a: make integer! d]
		b: 		make integer! 0
		c: func [val] [
			obj-in-obj/a:   val
			b:		val
		]
	]
]

a: create-template 0
b: create-template 1000
probe a
probe b
b/c 3000
probe a 
probe b

TomBon, here is the construct docs http://www.rebol.com/docs/changes.html#section-4.1

TomBon, here is the purpose of a construct:

>> ct: construct [int: (1 + 1)]
>> ct/int
== (1 + 1)
>> do ct/int
== 2
>>


Notice that it doesn't automatically evaluate /int as an object would 
do.

YES! thx a lot graham and paul. it works.

yepp, just made a check with real data. works fine. again thx for 
help...

Now, you have to tell us why it works :)

you have read my mind graham :-) but to be honest I have no idea. 
does the function preserve the scope?

I have no idea :)

Where is the parent object now?

:-)) well sounds thrustfull to built a comercial software on that 
;-)

I presume it's recreated anew each time the create-template runs

encapsulated within the function space?

You still can't clone from the objects it creates ...  ie. e: make 
a [] has the same problems

the parent object is an unevaluated block

do you think this solution is stable?

it doesn't exist as an object.

so, this is sqlabs solution

the object! will be a central part for the lib I am currently building.

wow, fractal programming at it's best

sure it's stable.

cool

TomBon, keep in mind that you can create the spec for an object and 
use it as your template as well.

>> blk: [a: 1 b: 2]
== [a: 1 b: 2]
>> obj: context blk
>> obj/a
== 1
>> obj/b
== 2

If you look at the source for 'function, you will see that the parameters 
are just 2 blocks ....

yes but the objects also containing functions and nested objects 
etc. graham approach is very compatible with the current codebase 
I have so far but thx for reminding me with this paul.

Your welcome TomBon, glad to see that you got the problem resolved.

What part of this is a bug:

>> val: 'blah
== blah
>> type? val
== word!
>> lit-word? val
== false
>> help val
VAL is a word of value: blah
>> val: to-lit-word val
== 'blah
>> type? val
== word!
>> lit-word? val
== false
>> help val
VAL is a lit-word of value: 'blah

Lit-words reduce to words pretty easily, so try this instead:
	type? :val

Yeah I actually realized that after I posted it.

What was confusing me is assignment and how it works with lit-word

Consider the following:

>> a: 'test
== test
>> lit-word? :a
== false
>> a: to-lit-word 'test
== 'test
>> lit-word? :a
== true