World: r3wp

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

Seems to me that the assignment aspect is still buggy.  i would expect 
to get lit-word? true on the first call in that example.

The way I see it:

In your second post,

'test is a lit-word! being evaulated to a word! before assignment 
to 'a, in the first part

In the second part, the lit-word! 'test is being evaluated to a word!, 
passed into the function to-lit-word, then the lit-word is assigned 
to 'a


In the first post, why "type? val" returns word! on a lit-word!, 
I see as the same as this - the type is a subset:
>> X: %One
== %One
>> type? X
== file!
>> series? X
== true

It just seems inconsistent to me but I suppose it is needed to be 
this way to deal with the manner in which REBOL operates.  For example, 
consider its inconsistency in this regard:

>> string? "this"
== true
>> file? %file
== true
>> lit-word? 'this
== false

Also consider this:

>> a: first ['test]
== 'test
>> lit-word? :a
== true
>>

It's always felt consistent to me - the context is being evaluated, 
and lit-word!s reduce to word!s, word!s reduce to functions and values, 
while other datatypes reduce to themselves:
>> X: [{One} 'Two]
== ["One" 'Two]
>> ? X/1 ? X/2
X/1 is a string of value: "One"
X/2 is a lit-word of value: 'Two

>> X: reduce X   ;Here is where typing it in on the terminal evaluates 
to
== ["One" Two]
>> ? X/1 ? X/2
X/1 is a string of value: "One"
X/2 is a word of value: Two
>> X: reduce X
** Script Error: Two has no value
** Near: Two

...and the reasoning behind lit-word!/word! acting differently is 
that those are special datatypes where other values can be bound 
to them

My point is that I don't see why the to-lit-word isn't implied when 
performing assignment.  Such as a: 'test

BTW, it is more efficient to assign a lit-word with a: first ['test] 
then it is to use a: to-lit-word 'test.

(I participatted in this discussion already one time and it also 
seems consistent to me)

Paul: I think Brian or Henrik told that time that 'word is "active" 
something and rebol reduces it when encounters it in the same way 
as it would auto-reduce function a: get-two not assign it to a (at 
least that was my compilation of it that time :) )

and we all know that blocs don't get evaluated / reduced by itself 
so [ word ]  stays [ word ] even fi word is undefined or func or 
anything so [ 'word ] also stays [ 'word ]