I am almost done with moving selectors around and migrating code. One last proposal while I am at it. In line with Cris Cunninghams observation that #isBinary is quite ambiguous on Strings/Symbols, would moving to #isUnarySelector, #isBinarySelector, and #isKeywordSelector be an option? It would improve consistency and be more descriptive. At the same time it might break compatibility with other dialects.

Bests, Patrick

P.S.: Thanks for staying with me on this topic. I just feel that making the protocols more consistent / accessible while being at it can make the whole system more accessible in the long run. :)

...

Sorry to open this up again. I have progressed well in shuffling things around. However: While moving the corresponding test cases I noticed that there is also #isBinary, #isDoIt, #isInfix, #isUnary, #isKeyword, and #isPvtSelector implemented on Symbol. Given that these all exist, I would rather keep #asSimpleSetter, #isSimpleSetter, #asSetterSelector in the Collections package.

Any other oppinions on that?

Virtually every classic description of the Smalltalk language in books and classes I can remember talks about

"three kinds of message names, unary, binary, and keyword..."

For example, here it is on the Complete Smalltalk Syntax on a Postcard:

https://medium.com/@richardeng/syntax-on-a-post-card-cb6d85fabf88

So, I think those three belong in Collections.

"Setter" relates to making a setter method. That's tooling. So the only reason I would have anything "setter" in Collections is if there are enough senders from different depending packages that Collections is the only common ancestor between them.

Best, Chris