Bug in senders/implementors tool (strings vs literals)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in senders/implementors tool (strings vs literals)

Christoph Thiede

Steps to reproduce:

Open a method in a browser, say Collection >> #detect:.

Select the whole source code.

Browse senders of it (<cmd>n).


Expected behavior:

All senders of #detect: are shown in a MessageTrace.


Actual behavior:

"There are no users of 'detect:'".


This might be related to the literal comparison, which is fine for the SystemNavigation interface but not expected when you use the refactoring tools for browsing methods. Something must go wrong when identifying the relevant literal from the selected source.


Best,

Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Bug in senders/implementors tool (strings vs literals)

marcel.taeumel
Hi Christoph.

I suppose that might a bug in either String >> #findSelector. All supported cases are documented in StringTest.

Hmmm... but I am not so sure that your "select all text" example is actually a relevant scenario. The request "Show be all senders of  'detect:detect:' " is invalid anyway.

Best,
Marcel


Am 24.04.2020 21:21:46 schrieb Thiede, Christoph <[hidden email]>:

Steps to reproduce:

Open a method in a browser, say Collection >> #detect:.

Select the whole source code.

Browse senders of it (<cmd>n).


Expected behavior:

All senders of #detect: are shown in a MessageTrace.


Actual behavior:

"There are no users of 'detect:'".


This might be related to the literal comparison, which is fine for the SystemNavigation interface but not expected when you use the refactoring tools for browsing methods. Something must go wrong when identifying the relevant literal from the selected source.


Best,

Christoph