It doesn't matter if it's private or not, because that can be changed. What I don't understand is the need for an additional wrapper method.
I suppose you could make this same argument against #pin and #unpin.
If you think #pinned: is needed, then it should replace #setPinned:.
The separation here was due only to the fact that setPinned: is a lever that rests directly against the "metal" and I think its preferable to insulate user-level API's from that.
I'd recommend using #pin and #unpin if wherever possible, but there have been enough cases where various method pairs (i.e., #lock/unlock, #show/hide, #action/unaction, etc.) where it can't be known which one is needed until runtime.
I just can't imagine a real-world situation where you'd want to pin or unpin an object based on a condition.
What about #isPinned? Can you imagine a situation where you'd ever need that? Maybe should remove that one too? And why does the primitive need to answer whether it *was* pinned?
I think a robustly-designed API becomes more possible when think about possible usages beyond FFI calls.
I once thought I would never need to call "Smalltalk garbageCollect" but, eventually, in one app I ran into a scaling issue where I actually needed to do it to improve performance.
Having said all this, I have had times when I've wanted to purposely restrict an API to one specific use-case, and require code changes for it to grow beyond that use-case, so as to force proper consideration.
I went ahead and reverted my changes.