More on "embedded" objects (an enhancement)

The enhanced version with a /SHARED refinement appears below, followed by new and improved (I hope) documentation. 8<---------------------------------------------------------- instantiate: func [ [catch] spec1 [block! object!] /unique spec2 [block!] /shared spec3 [block!] /local ospec uspec uattr result ][ ospec: copy [] uspec: copy [] uattr: to-word "; unique" if all [object? spec1 found? in spec1 uattr] [ append uspec get in spec1 uattr ] if unique [ append uspec spec2 ] if 0 < length? ospec: copy/deep uspec [ append ospec reduce [to-set-word uattr 0] ] if shared [ append ospec spec3 ] result: either object? spec1 [ make spec1 ospec ][ make object! append copy/deep spec1 ospec ] if 0 < length? uspec [ set in result uattr uspec ] result ] 8<---------------------------------------------------------- INSTANTIATE constructs objects. In the simplest case (i.e. no refinements -- ever!) it is almost the same as MAKE OBJECT! with the following exceptions: new-object: instantiate spec-block creates an object from the supplied block, but words in that block are NOT bound to the new objects context. In addition new-object: instantiate spec-object creates a new object from the supplied object, without the need for an empty block when no modifications are desired. The /UNIQUE refinement requires an additional block, which is combined with the original spec (block or object) to override and/or extend attributes for the new object, just as new-object: make spec-object extra-block can incorporate changes/additions to attributes. However, there's another difference. When creating an object via new-object: instantiate/unique spec-thing u-block (where SPEC-THING can be either a block or another object) the new object will distinguish between its "shared" parts and its "unique" parts. If yet another object is created later using newer-object: instantiate new-object the *current* state of the shared parts will be used as the basis of the newer object, but the *original* unique spec will be used to create a fresh copy of all unique parts. To illustrate: o1: instantiate/unique [ a: 1 ][ b: 10 gimme: func [] [print ["I contain" a "and" b]] ] creates an object with a shared A and unique B, with the following behavior

I contain 1 and 10

== 2

== 20

I contain 2 and 20 Using O1 as the basis for a later object give the following results,

I contain 2 and 10 where the unique attribute O2/B is initialized per the original unique spec block, rather than coming from the current state in O1. The /SHARED refinement allows an additional spec block to be supplied to override/extend the original specification, but *without* marking its content as unique. Therefore,

I contain 100 and 10 overrides the current O2/A, but that change is not marked as unique. As the following transcript shows

== 200

== 30

I contain 200 and 30

I contain 200 and 10 the A attribute still comes from the current spec object, while future B attributes still revert to the original specification. The /SHARED refinement is allowed when building from a spec block as well. It will extend/override the base spec block, which creates "shared" attributes by default. Finally, both the /UNIQUE and /SHARED refinements are cumulative in effect:

[ a: 1 [ ][ [ b: 10 [ sum1: func [][a + b] [ ]

== 2

== 20

[ c: 100 [ sum2: func [][a + b + c] [ ]

[ d: 1000 [ sum3: func [][a + b + c + d] [ ] so that A and C are shared, while B and D are unique

== 3

== 30

== 300

== 3000

== 1313 Finally, of course (at last!), the most subtle and critical issue with /SHARED (or default) versus /UNIQUE is this: since the cumulative unique specifications in a prototype object are re-evaluated from a clean copy whenever that prototype object is INSTANTIATE-d, 1) any UNIQUE initialization activity will be re-evaluated in the combined context of the new object and the global context, and 2) any UNIQUE-ly "embedded" sub-objects will be re-created in the new context (1), while SHARED "embedded" sub- objects will simply refer back to the sub-object in the prototype object. Enclosing-object words in an embedded sub-object will refer to the original enclosure for SHARED (or default) sub-objects but will refer to the current enclosure for UNIQUE sub-objects. Hope this helps! (And if you read this far, I owe you a virtual cookie for your patience and endurance!) -jn- -- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com