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

Juan Vuletich (mail lists) juanlists at jvuletich.org
Tue Aug 14 20:11:29 UTC 2012



You're right Colin. Thanks for pointing this out. I just made an update for Cuis to address this. 

Cheers, 

Juan Vuletich

Quoting Colin Putney <colin at wiresong.com>: 

> 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. 
>
>
> Colin

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120814/1d109bb7/attachment.htm


More information about the Squeak-dev mailing list