[squeak-dev] The Trunk: ToolBuilder-Morphic-tpr.196.mcz
Chris Muller
asqueaker at gmail.com
Fri Oct 6 03:00:27 UTC 2017
> 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
More information about the Squeak-dev
mailing list
|