Bug in Behavior>>specialSelectorIndexFor:

[Prophet1024]

.

[Eric Clayberg]

This method should always return an integer, not the selector.

No. That is a private method whose result is only used as an argument to the CompiledMethod>>#sendsSpecialSelector: method which expects a method selector (a Symbol).

At some point in the distant past, the CompiledMethod>>#sendsSpecialSelector: method lilely expected an integer to be passed in, but was then changed to expect a selector. The implementation of its precursor method, Behavior>>specialSelectorIndexFor:, was then changed to reflect those new requirements without changing its name. At this point, it can't be changed as its current implementation has been in place and expected for more than ten years.

In any case, it is a private method that should not be used for anything other than its intended (and very narrow) purpose.

[Prophet1024]

.

[Eric Clayberg]

We must be looking at two different things because I only see two senders of Behavior>>specialSelectorIndexFor: and they're both in Behavior (not CompiledMethod>>#sendsSpecialSelector:).

Look at both senders, and you will see calls to CompiledMethod>>#sendsSpecialSelector: as I indicated.

[wembley]

OK, so you are both correct (in a way). The 2 senders of Behavior>>specialSelectorIndexFor: use a returned value of 0 to indicate that the selector is not a special selector. But they both call CompiledMethod>>#sendsSpecialSelector: passing the returned value if the returned value is not 0.

I agree with Eric that at some distant time in pre-history (before 6/6/1996) the method in question probably did always return an integer rather than a selector. Whoever made this change in behavior neglected to change both the method signature (to maintain its intent-revealing nature) and the comments in several methods.

I could open a defect for this problem, but it would simply join the huge pile of similar "untidyness" defects that I brought with me from IBM -- they just never make it even close to the top of the list to work on.

Now you might say that this would only take 5 minutes to fix, so why not just do it? The answer is that in addition to the 5 minutes, there is the time to do the record keeping on the defect, create the testcase to ensure we didn't break anything in the course of making the change, and running the testcase on all platforms. It just isn't the best use of our time (in my opinion) even though I really hate it when I, like you, trip over these untidy things. I hope this helps you understand why it is very unlikely that we will correct this problem.

[Eric Clayberg]

How about we change the method comment to reflect reality?

[wembley]

Defect 28026 opened -- I've changed the comments in several methods associated with this item for V7.5.1.