On Fri, 17 Aug 2012, Frank Shearar wrote:

> On 17 August 2012 13:07, Levente Uzonyi <leves at elte.hu> wrote:
>> On Fri, 17 Aug 2012, Frank Shearar wrote:
>>
>>> On 14 August 2012 15:38, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>
>>>> On 14 August 2012 15:36, Colin Putney <colin at wiresong.com> wrote:
>>>>>
>>>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar <frank.shearar at gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> Why both testPrefFalse and testTokenishFalse (and both testPrefTrue
>>>>>> and testTokenishTrue) if they both do the same thing?
>>>>>> (testPref(True|False) are in the image now, so unless there's good
>>>>>> reason, I don't see why we can't just remove testTokenish(True|False)
>>>>>> from the above.
>>>>>>
>>>>>> Nit: I'd like testPref(True|False) categorised.
>>>>>>
>>>>>> Otherwise, +1 from me.
>>>>>
>>>>>
>>>>> I renamed them.
>>>>
>>>>
>>>> *cough*. Frank, the '-' lines are lines that are removed, and the '+'
>>>> lines are lines that are added. Right. Moving swiftly along...
>>>>
>>>>> The new tests are related to selector precedence, so I
>>>>> wanted the tokenish tests to have that word in their selectors. The
>>>>> new versions are categorized too!
>>>>
>>>>
>>>> Now that my eyes have seen the light, consider this an unqualified +1
>>>> then.
>>>
>>>
>>> Does this need updating? testP2LeadingUnderscore and
>>> testP2SingleUnderscore fail because #_+ and #'_' have precedence 1
>>> instead of the expected 2. (This relates to your conversation with
>>> Juan, IIRC, on whether or not $_ can form part of a binary selector.)
>>
>>
>> #'_+' is not a valid selector, since + can only be part of a binary
>> selector, while _ can't be part of such selector. So it doesn't matter what
>> #precedence returns and #testP2LeadingUnderscore should be removed.
>
> Well, I've now twice seen "$'_+' is not a valid selector" but I've not
> seen any _reason_ why not. _ used to be a poor man's left arrow, so _
> couldn't be in _any_ selector, so arbitrarily limiting _s to only
> non-binary selectors seems artificial. Unless it's _purely_ a
> compatibility with those Smalltalks who have always had _s in their
> selectors? (So "that's what ANSI says" would be a valid reason.)

Nothing artifical here. Characters which are allowed in binary and 
non-binary selectors are in two disjunct sets already. I'm pretty sure the 
reason for this is to keep the grammar free of ambiguities. For example:
If + would be allowed in non-binary selectors too, then you could write a 
method with the name yourself+b. So "a yourself+b" would have two 
different meanings.
With _+ the same can be done. What is "a_+b"?
Is it "a _ + b" (where #'_' is a unary selector) or "a _+ b" (where #'_+' 
is a binary selector)?


Levente

>
> frank
>
>> Levente
>>
>>>
>>> frank
>>>
>>>> frank
>>>>
>>>>> Colin
>>>>>
>>>
>>>
>>
>
>