On Tue, Aug 14, 2012 at 8:12 AM, Juan Vuletich (mail lists) < juanlists@jvuletich.org> wrote:
WRT #'_value' precedence, it answers 2 if allowUnderscoreSelectors is
false.
The question is actually meaningless in this case, as #'_value' is not a valid selector... If you set the preference to true, it correctly answers
1.
The preference controls the behaviour of the scanner. That is, it controls whether 'a_b' in scanned as 1 token or 3 tokens. It should have no effect on precedence. Consider the case where you set #allowUnderscoreSelectors to true, load a package that contains them, then set the preference to false again. That's probably the common case; cf ConfigurationOfXtreams. Now you've got selectors containing underscores in the image, but the preference is set to false. Are those selectors invalid now? Is it meaningless to ask their precedence?
No, those messags continue to work fine, and reflective code may well encounter selectors with underscores in them. Consider the following code:
Smalltalk allSentMessages select: [:ea | ea isSymbol and: [ea precedence = 2]]
Cuis will include #'_value' in the answer. Or how about this:
doesNotUnderstand: aMessage aMessage selector precedence = 2 ifTrue: [Transcript show: 'Got an infix message!']
That kind of code may not be common, but it should work.
Thanks for pointing me to Cuis' implementation. Digging into the details exposed a bug in my inelegant implementation as well—I had thought that binary selectors could contain underscores, but that's not the case. That implies that a single underscore is a unary message, not binary. Off to fix my test cases.
Colin