A short time ago, Joel Neely, sent an email stating:
> Hi, Volker,
>
> Thanks for the explanations. As Larry Wall said:
>
> Just because something is obviously happening doesn't mean
> that something obvious is happening.
>
> ;-)
>
> However, I'm still left with a puzzled look on my face over
> one aspect of this...
>
> Volker Nitsch wrote:
> > 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,
>
> (Oh, by the way, did you find this documented anywhere, did you
> just figure it out for yourself, or is there another path to
> enlightenment? ;-)
>
> Thanks to your explanation, I have a more compact example...
>
> gub?: make object! [
> data: [1]
> proto: make object! [
> number: 0
> dataref: data
> speak: func [] [print [number mold dataref]]
> ]
> things: []
> append things make proto [number: 1]
> append things make proto [number: 2 dataref: data]
> tweak-n-speak: func [blk [block!]] [
> insert data blk
> foreach thing things [thing/speak]
> ]
> ]
>
> ...which behaves as follows...
>
> >> gub?/tweak-n-speak ["OK,"]
>
> 1 [1]
> 2 ["OK," 1]
>
> My remaining puzzlement is over this contrast:
>
> If I accept the description that (during the construction of
> GUB?/PROTO) GUB?/DATA is copied and GUB?/PROTO/DATAREF is set
> to refer to the copy, then that explains the behavior of
> GUB?/THING/1 .
>
> However, during the construction GUB?/THING/2 the additional
> spec block *also* refers to GUB?/DATA , but apparently the copy
> behavior does *not* occur (even though the referenced data value
> is still only a block).
>
> This makes me wonder if the issue here is a difference in the
> evaluation of the specblock parts of
>
> make object! [...specblock...]
>
> vs.
>
> make some-object [...specblock...]
>
> This is uncomfortably reminiscent of FORTH, in which one must
> have a complete operational model of the interpreter's internal
> state if one is to understand the behavior the more advanced
> (and hence more useful) aspects of the language. At least FORTH
> had both liberal documentation and available source to help with
> the construction/communication of such an operational mental
> model...
>
> -jn-
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
