Hi Joel,
>> a: context [ b: [1]]
>> c: make a[]
>> d: make a[]
>> same? a/b c/b
== false
>> same? c/b d/b
== false
when you 'make an 'object!, all strings, blocks and functions are copied.
that allows for example in 'layout :
box with[append init[my-inits]]
without destroying the original in box.
also blocks, like functions, are rebound.
so [make child-proto []] gives a copy of 'dataref, not the original.
but objects are not copied,
so the 'face/feel are all the same after [make face[]].
or in your case,
do [
ex: func ["probe-tool" block] [print [">>" mold/only block "^/"] do block]
bug?: make object! [
width: 2
data: context [block: [1]] ;;; object!
plop: func [b [block!]] [append data/block b]
child-proto: make object! [
label: "no such"
dataref: data
dump: func [] [print [label newline tab mold dataref]]
reset: func [] [dataref/block: head dataref/block]
]
children: make block! width
repeat i width [
append children make child-proto [
label: join "Child-" i
]
]
fizz: func [] [
foreach child children [
child/dump
]
]
]
ex [bug?/fizz]
ex [bug?/plop [3 5 7]]
ex [bug?/fizz]
]
>> bug?/fizz
Child-1
make object! [
block: [1]
]
Child-2
make object! [
block: [1]
]
>> bug?/plop [3 5 7]
>> bug?/fizz
Child-1
make object! [
block: [1 3 5 7]
]
Child-2
make object! [
block: [1 3 5 7]
]
greetings
-volker
Am Dienstag, 14. Mai 2002 06:17 schrieb Joel Neely:
> I don't have a good explanation for this bit of surprising behavior.
> All donations of wisdom gladly accepted.
>
> Here's a odd-looking little object:
>
> bug?: make object! [
> width: 3
> data: [1]
> plop: func [b [block!]] [append data b]
> child-proto: make object! [
> label: "no such"
> dataref: data
> dump: func [] [print [label newline tab mold dataref]]
> reset: func [] [dataref: head dataref]
> ]
> children: make block! width
> repeat i width [
> append children make child-proto [
> label: join "Child-" i
> ]
> ]
> fizz: func [] [
> foreach child children [
> child/dump
> ]
> ]
> ]
>
>
> It contains a data store (called DATA surprisingly enough) and
> a block of subordinate objects that need to share access to DATA.
> Within each child object, DATAREF is supposed to refer to the
> same series as DATA. That way, after BUG?/PLOP is used to add
> entries to DATA, the DUMP routine of each child should show the
>
> additions. Let's try it:
> >> bug?/fizz
>
> Child-1
> [1]
> Child-2
> [1]
> Child-3
> [1]
>
> >> bug?/plop [3 5 7]
>
> == [1 3 5 7]
>
> >> bug?/fizz
>
> Child-1
> [1]
> Child-2
> [1]
> Child-3
> [1]
>
>
> Wozzattt?? It appears that each child's DATAREF has become a
> completely independent block!? Howesomever...
>
> If we add one line to the initialization of CHILDREN (inside
> the REPEAT about a dozen lines in) like so:
>
> bug?: make object! [
> width: 3
> data: [1]
> plop: func [b [block!]] [append data b]
> child-proto: make object! [
> label: "no such"
> dataref: data
> dump: func [] [print [label newline tab mold dataref]]
> reset: func [] [dataref: head dataref]
> ]
> children: make block! width
> repeat i width [
> append children make child-proto [
> label: join "Child-" i
> dataref: data ;;; this line added
> ]
> ]
> fizz: func [] [
> foreach child children [
> child/dump
> ]
> ]
> ]
>
> ... we now get the expected behavior!
>
> >> bug?/fizz
>
> Child-1
> [1]
> Child-2
> [1]
> Child-3
> [1]
>
> >> bug?/plop [3 5 7]
>
> == [1 3 5 7]
>
> >> bug?/fizz
>
> Child-1
> [1 3 5 7]
> Child-2
> [1 3 5 7]
> Child-3
> [1 3 5 7]
>
>
> As tempted as I am to sing
>
> "Plop, plop, fizz, fizz,
> Oh what a relief it is!"
>
> I'm not feeling relieved. Why does the second version behave
> differently? Both are initializing DATAREF to DATA, just at
> different times, so I'm a bit puzzled.
>
> Do I need more coffee?
>
> -jn-
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
