[squeak-dev] The Inbox: Collections-cwp.486.mcz

Frank Shearar frank.shearar at gmail.com
Tue Aug 14 18:27:10 UTC 2012


On 14 August 2012 18:18, Colin Putney <colin at wiresong.com> wrote:
>
>
> On Tue, Aug 14, 2012 at 8:12 AM, Juan Vuletich (mail lists)
> <juanlists at 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.

I'd noticed +_+. The only argument I can see _against_ such a thing is
that +a+ is currently not a valid binary selector.

frank

> Colin
>
>
>
>
>
>


More information about the Squeak-dev mailing list