> 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.