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 at 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 at lists.gforge.inria.fr
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project