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 Thu, Jul 10, 2025 at 4:35 AM Marcus Denker <marcus.den...@inria.fr> wrote: > > > > On 9 Jul 2025, at 21:37, Daniel Slomovits <daniels...@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
