Andreas, I think the advantage of form B comes when you end up nesting the build instructions: spec for: #common do: [ spec blessing: #baseline. spec description: 'Descriptive comment'. spec project: 'UI Support' with: [ spec className: 'UIConfig'; loads: #('UI-Core' ); repository: 'http://www.example.com/r' ]. spec package: 'Example-AddOn' with: [ spec requires: #('Example-Core' ); includes: #('Example-UI' ); repositories: [ spec repository: 'http://www.example.com/yar'; repository: 'http://www.example.com/yas']]]. You can't construct the above as a cascade, so you end up having to create temp variables, etc. Like the following for form A: | common pkg | common := (spec for: #common) blessing: #baseline; description: 'Descriptive comment'. (common project: 'UI Support') className: 'UIConfig'; loads: #('UI-Core' ); repository: 'http://www.example.com/r'. pkg := common package: 'Example-AddOn'. pkg requires: #('Example-Core' ); includes: #('Example-UI' ). pkg repositories repository: 'http://www.example.com/yar'; repository: 'http://www.example.com/yas'. When I scan form B (with nested blocks) it is very clear that the repositories are associated with the package 'Example-AddOn'. If form A, it's not as obvious. Dale ----- "Andreas Raab" <andreas.raab@gmx.de> wrote: | Hi - | | Over the weekend I realized an interesting difference in the | utilization | of the builder pattern. It is related with how to create and interact | | with new entities created by the builder, and goes like this: | | Form a: In this form (which is utilized by ToolBuilder) a request for | a | new item creates an instance of the item which is then populated with | | the desired set of attributes, for example | | ^(builder pluggableListSpec new) | model: tool; | list: listSymbol; | getIndex: selectionSymbol; | setIndex: selectionSymbol asMutator; | frame: currentFrame; | yourself | | The expression "builder pluggableListSpec new" (or some variant like | "builder newObject") creates an instance of the item, returns it, and | | then we set various properties on it. | | Form b: In this form (which is utilized for example by Metacello or by | | Pharo's Settings package) the builder generally returns *self* (it may | | return some other builder object but from what I've seen it never | returns the actual entity created) from the request to create a new | entity, and effectively "proxies" the follow-on requests, for | example: | | (aBuilder pickOne: #displayDepth) | label: 'Display depth' translated; | parent: #appearance; | target: #Display; | getSelector: #depth; | setSelector: #newDepth:; | domainValues: self depthChoices; | notInStyle. | | The expression "aBuilder pickOne: #displayDepth" returns another | builder | which then assembles the various attributes. The more canonical use of | | this form seems to be utilized via an implicit block scope in the | construction request, like here: | | spec project: 'OB-Standard' with: [ | spec | className: 'ConfigurationOfOmniBrowser'; | loads: #('OB-Standard' ); | file: 'ConfigurationOfOmniBrowser'; | repository: 'http://www.squeaksource.com/MetacelloRepository' ]. | | In this form the 'project' is created by the 'spec' (constructor) | internally and then populated via the follow-on messages (#className:, | | #loads:, #file:, #repository) sent to the 'spec' and from there | forwarded internally to the project under construction. | | [Btw, it's not entirely clear to me whether these two forms really | represent the same idea or if we need to split them into "form b" | using | nested builders and cascades and "form c" operating on scoped blocks. | In | any case...] | | What I'm curious about is this: Which advantage does "form b" have | over | "form a"? Why would one choose it? Is it merely for convenience or are | | there other (practical or style) advantages? | | Cheers, | - Andreas | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project