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