Test-run-based code critics would definitely be cool. Though in this case, I think a static analysis using heuristics could get us 99% of the way there���if the receiver (heh) of the #receiver message is a variable node whose name contains "ctx" or "context", or a message send which is known to return only things other than BlockClosures (e.g. all the context-chain navigation messages like #sender), we can disregard that call site. Starting from ~400 senders of #receiver it wouldn't surprise me if that cut it down to as few as 10 or 20 that could be manually checked. Unfortunately I am not as fluent in the Code Critic as I am in the simpler interfaces in Dolphin Smalltalk, so I can't just bang something out in 5 minutes, but it's fundamentally not hard.
> On 9 Jul 2025, at 21:37, Daniel Slomovits <daniels220@gmail.com> wrote:
>
> This is very cool to see. One note���I would personally not outright deprecate #receiver, but leave a comment indicating that it is not guaranteed to be set and why. There are plenty of cases where getting nil as the receiver of a clean block is correct, or at least good enough���I wouldn't want to eventually lose the ability to officially access it entirely, which is what deprecation implies.
Yes, true��� I wonder how to provide support for people to find potential problematic use.
One thing we really need is Code Critics, but not doing static analysis but working on test run data.
We could
�� �� �� �� -> add probe in #receiver
�� �� �� �� -> run tests
�� �� �� �� -> log all send sites
�� �� �� �� -> tool shows all uses of #receiver that need to be checked
�� �� �� �� Marcus