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
>