Hi Folks,
For this method, #tokenish and several others, please take a look at senders & implementors of #isGenerallyValidInIdentifiers and #isGenerallyValidStartOfInIdentifiers in Cuis. This style eases having a consistent behavior.
Cheers, Juan Vuletich
Quoting commits@source.squeak.org:
Item was changed: ----- Method: Symbol>>precedence (in category 'accessing') ----- precedence "Answer the receiver's precedence, assuming it is a valid Smalltalk message selector or 0 otherwise. The numbers are 1 for unary, 2 for binary and 3 for keyword selectors."
self size = 0 ifTrue: [^ 0].
- self first isLetter ifFalse: [^ 2]. self last = $: ifTrue: [^ 3].
- (self anySatisfy: [:c | c isLetter]) ifTrue: [^ 1].
- ^ 2!
- ^ 1!
Cheers, Juan Vuletich
On Tue, Aug 14, 2012 at 5:29 AM, Juan Vuletich (mail lists) juanlists@jvuletich.org wrote:
For this method, #tokenish and several others, please take a look at senders & implementors of #isGenerallyValidInIdentifiers and #isGenerallyValidStartOfInIdentifiers in Cuis. This style eases having a consistent behavior.
Can you be more specific about what you're suggesting? Are you talking about the distinction between the first character and the subsequent characters when scanning an identifier? Refactoring to reduce duplication? Self documenting code via clear selector names?
It's too late in the release cycle to adopt the Cuis' implementation wholesale—particularly since Cuis doesn't pass the all the tests I committed yesterday. (For example, #'_value' precedence answers 2.) For 4.4 I'll be happy if we can make underscore selectors work without having to patch the system before loading a package that contains them. (eg Xtreams).
Colin
Quoting Colin Putney colin@wiresong.com:
On Tue, Aug 14, 2012 at 5:29 AM, Juan Vuletich (mail lists) juanlists@jvuletich.org wrote:
For this method, #tokenish and several others, please take a look at senders & implementors of #isGenerallyValidInIdentifiers and #isGenerallyValidStartOfInIdentifiers in Cuis. This style eases having a consistent behavior.
Can you be more specific about what you're suggesting? Are you talking about the distinction between the first character and the subsequent characters when scanning an identifier? Refactoring to reduce duplication? Self documenting code via clear selector names?
Yes, all that. Stating the critera in as few places as possible, and making it as easy to understand (and change) as possible. Avoid calling the preference from many places, etc.
It's too late in the release cycle to adopt the Cuis' implementation wholesale—particularly since Cuis doesn't pass the all the tests I committed yesterday. (For example, #'_value' precedence answers 2.) For 4.4 I'll be happy if we can make underscore selectors work without having to patch the system before loading a package that contains them. (eg Xtreams).
I didn't suggest adopting the implementation in Cuis, just using a (maybe) good coding style. Adopting code from another fork requires a lot of care and testing to be sure of not breaking stuff. I know that. I do it quite often.
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.
Colin
Cheers, Juan Vuletich
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
box-admins@lists.squeakfoundation.org
-
Colin Putney -
Juan Vuletich (mail lists)