> > You can't search invocations of a particular "class>>method".
So if I understand there's no direct way to do it, and I need to traverse the AST and do a static analysis. Unfortunately adding logging will work only if I know that all the senders will actually send the message, which is definitely not guaranteed here. (Btw "Transcript crShow:" should be better written as"self crLog:") What I do in that case is that I select the text "WriteStream on:" and > "method source with it". But of course, a class side search would be nice. Nice! I didn't know about this, I always used finder instead. Thanks, Peter On Sun, Aug 9, 2015 at 3:39 AM, Mariano Martinez Peck <marianop...@gmail.com > wrote: > What I do in that case is that I select the text "WriteStream on:" and > "method source with it". But of course, a class side search would be nice. > > On Sat, Aug 8, 2015 at 10:07 PM, Ben Coman <b...@openinworld.com> wrote: > >> On Sun, Aug 9, 2015 at 3:25 AM, Peter Uhnák <i.uh...@gmail.com> wrote: >> > So there's method CompiledMethod>>senders, >> > but the problem is that it just looks for the message symbol and not >> class. >> > >> > so for example: >> > ~~~~~~~~~~~~~~~~~~~~~ >> > (WriteStream>>on:) senders >> > ~~~~~~~~~~~~~~~~~~~~~ >> > will also include Object>>asBrick >> > >> > Object>>asBrick >> > ^ GLMMorphBrick on: self asMorph >> > >> > because it sends #on: even though it's on completely different object. >> > >> > Now I understand that this is a dynamic system, so I will never have all >> > senders, but this should be resolvable even through static analysis? >> > >> > So now my question is: Is there an easy way to retrieve the object to >> which >> > the selector is sent? >> > I can use "CompiledMethod>>messages", but that just returns "a >> Set(#asMorph >> > #on:)" which is useless here. >> > >> > So do I need to traverse the AST and find it there? >> >> You can't search invocations of a particular "class>>method". You can >> only search invocations of a "message" unbound from any class. You >> can constrain your senders to search to particular packages, but that >> requires pre-knowledge and may not suit all cases. In some cases I >> find adding the following useful... >> >> WriteStream>>on: >> Transcript crShow: thisContext senders senders printString , >> '-->' , thisContext senders printString , >> thisContext printString. >> .... >> >> cheers -ben >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >
