Re: [Pharo-project] A question on the builder pattern

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" <[hidden email]> 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
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project