[squeak-dev] The Inbox: Tests-cwp.158.mcz

Levente Uzonyi leves at elte.hu
Fri Aug 17 15:04:34 UTC 2012


On Fri, 17 Aug 2012, Frank Shearar wrote:

> On 17 August 2012 15:02, Levente Uzonyi <leves at elte.hu> wrote:
>> 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)?
>
> We're bordering on being meaninglessly academic, so feel free to shut
> the conversation down :) We're not talking about $+ though, which is
> definitely in the binary selector set of characters. Oh, I think I see
> what you mean: you're saying $_ should only be in the binary selector
> set of chars or the other set, but NOT both (because of potential
> ambiguities...?).

Right. :)

>
> But then _ ought to be a valid identifier, given that at the moment
> unary selectors and identifiers share the same definition. I'd be

It is a valid identifier. Just disable underscore as assignment and enable 
underscores in selectors to be able to use it.


Levente

> _very happy_ with this, but it's probably not a compatible change. Uh,
> no, that leads back to the 3--4 problem. a_+b could be a _+ b or a_ +
> b. Ah well.
>
> frank
>
>> Levente
>>
>>
>>>
>>> frank
>>>
>>>> Levente
>>>>
>>>>>
>>>>> frank
>>>>>
>>>>>> frank
>>>>>>
>>>>>>> Colin
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


More information about the Squeak-dev mailing list