Re: Accessors to children

Lukas, To clarify for you, the extra database accesses are because when the database accesses a PRDecorated node it loads the decorations in. Then seeing that PRChildren is present it generates a second access to get the contents of PRChildren only to find that it is empty. This is extra work (and time) for no net purpose. At the moment the problem is that many operations that involve children are doing so via PRStructure-#childrenDecoration whose default behaviour is to add an empty PRChildren instance to its decorations even if it is not actually needed. To be honest I love the clean design, even with empty PRChildren instances. It's just a shame when pragmatic considerations mess with our nice designs. Since I indicated that there are other ways of solving this problem I will list a few below. I constructed the children-accessing interface in order to satisfy the needs of the users of #childrenDecoration which are primarily the commands and the tests. Specifically: PRCommand-#validateName: aString of: aChildStructure in: aStructure PRCommand-#uniqueName: aString in: aStructure PRChangeEnvironmentCommand-#doExecute PRAddCommand-#doExecute PRCopyCommand-#doExecute PRMoveCommand-#doExecute PRStructure-#remove Solution Options: 1. child-accessing interface as discussed. 2. Magma before serializing any PRDecorated looks to see if there are any empty PRChildren and removes them before writing to its buffers. [ I think that this will work , though I am not 100% certain, but then we have PRChildren being created and destroyed over and over.] 3. Use an interface such as aStructure withChildren: [ :children | children add: ( aNewPage ) ] where #withChildren: cleans up afterwards. 4. Rewrite the commands above to use some form of visitor as you suggest below: fair enough. I think that you forgot the command actions #doExecute etc. see above Fair enough, I thought as much, but when I found PRStructure-#addChild: it indicated to me that you had thought of having a child-accessing interface of sorts, and so I simply completed the set to provide the functionality actually used in the image. I had a look at the third option and this is what I came up with PRDecorated>>newDecorationOfClass: aClass in: aBlock | decoration result | decoration := aClass new. result := aBlock value: decoration. decoration isEmpty ifFalse: [ self addDecoration: decoration ]. ^result PRDecorated>>decorationOfClass: aClass in: aBlock | decoration result | decoration := self decorationOfClass: aClass ifAbsent: [ ^self newDecorationOfClass: aClass in: aBlock ]. result := aBlock value: decoration. decoration isEmpty ifTrue: [ self removeDecoration: decoration ]. ^result PRStructure>>childrenIn: aBlock ^ self decorationOfClass: self childrenDecorationClass in: aBlock and so this enables things like PRCommand>>uniqueName: aString in: aStructure "Answer an unique structure name with the prefix aString within the parent aStructure." | index name | (aStructure notNil and: [ aStructure childrenIn: [ :children | children includes: aString ] ]) ifFalse: [ ^ aString ]. index := 1. [ aStructure childrenIn: [ :children | children includes: (name := aString , ' ' , (index := index + 1) asString) ] ] whileTrue. ^ name would that be better? Keith