> Part of the generic aspect of the problem is a tendency to use very generic message names that end up giving far too little information to the reader unless they’re fresh off writing the code. For example
>   ‘builder build: aSpec’
> has a clear simple meaning in some sense, at least when you first think about creating the code. But does the genericity imply that this builder can build something other than a spec? I’d suggest that for later readers it might have been better if it were
>   ‘builder buildFromSpec: aSpec’
> since that really makes it clear.

I think methods that are the most central, key abstracton of a class
or framework are fine candidates for a beautifully terse name and
comment.

> Specifically on theMorph>buildWith: thing I’d actually prefer to go with at least opening a notification, in the hope we might end up feeling comfortable that it never happens. My guess is that the type test was simply a response to a bug that never got properly cleaned up. Similarly, take a look at SUnitToolBuilder>>#buildPluggableWindow: - now how did we ever end up with it needing a test for ‘children isSymbol’ ? That seems nuts.

It's not nuts.  It expands the usage of this or any framework to allow
specification of selector names, instead of only objects, and imparts
a late-bound, leveraged, power-of-expression to the user.

Symbol is a base type!  Maybe consider relaxing your aversion to
type-checking for the base types at least.  If you ever use #isNil or
#ifTrue:, then you must already agree these type checks are sometimes
necessary.  Numbers, Strings, Arrays and, most certainly, Symbols are
also okay to type-check in rare, key places where it provides a lot of
leverage.

>From there, #isMorph does not seem like a huge leap.  Just sayin' because,
you know, there are a lot more of them.    ;)

 - Chris