The Inbox: Tests-cwp.158.mcz
Locked
 
|
A new version of Tests was added to project The Inbox:
http://source.squeak.org/inbox/Tests-cwp.158.mcz ==================== Summary ==================== Name: Tests-cwp.158 Author: cwp Time: 13 August 2012, 11:27:52.385 pm UUID: 815626bc-7a56-4869-961d-f81880b4a668 Ancestors: Tests-cwp.157 Renamed the existing tokenish tests, and added tests for selector precedence in the presence of underscores. =============== Diff against Tests-cwp.157 =============== Item was added: + ----- Method: UnderscoreSelectorsTest>>assertSelector:hasPrecedence: (in category 'support') ----- + assertSelector: aSymbol hasPrecedence: expected + | actual | + actual := aSymbol precedence. + self assert: actual = expected! Item was changed: + ----- Method: UnderscoreSelectorsTest>>pref:during: (in category 'support') ----- - ----- Method: UnderscoreSelectorsTest>>pref:during: (in category 'as yet unclassified') ----- pref: aBoolean during: aBlock | tmp | tmp := Scanner prefAllowUnderscoreSelectors. [Scanner prefAllowUnderscoreSelectors: aBoolean. aBlock value] ensure: [Scanner prefAllowUnderscoreSelectors: tmp].! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP1InternalUnderscore (in category 'tests') ----- + testP1InternalUnderscore + + self + assertSelector: #'is_symbol' + hasPrecedence: 1. + ! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP1LeadingUnderscore (in category 'tests') ----- + testP1LeadingUnderscore + self + assertSelector: #'_isSymbol' + hasPrecedence: 1. + ! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP1Traditional (in category 'tests') ----- + testP1Traditional + self + assertSelector: #isSymbol + hasPrecedence: 1! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP1TrailingUnderscore (in category 'tests') ----- + testP1TrailingUnderscore + self + assertSelector: #'isSymbol_' + hasPrecedence: 1! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP2InternalUnderscore (in category 'tests') ----- + testP2InternalUnderscore + self + assertSelector: #'+_+' + hasPrecedence: 2! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP2LeadingUnderscore (in category 'tests') ----- + testP2LeadingUnderscore + self + assertSelector: #'_+' + hasPrecedence: 2! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP2SingleUnderscore (in category 'tests') ----- + testP2SingleUnderscore + self + assertSelector: #'_' + hasPrecedence: 2! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP2Traditional (in category 'tests') ----- + testP2Traditional + self + assertSelector: #+ + hasPrecedence: 2! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP2TrailingUnderscore (in category 'tests') ----- + testP2TrailingUnderscore + self + assertSelector: #'+_' + hasPrecedence: 2! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP3InternalUnderscore (in category 'tests') ----- + testP3InternalUnderscore + self + assertSelector: #'with_value:' + hasPrecedence: 3! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP3LeadingUnderscore (in category 'tests') ----- + testP3LeadingUnderscore + self + assertSelector: #'_value:' + hasPrecedence: 3! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP3Traditional (in category 'tests') ----- + testP3Traditional + self + assertSelector: #value: + hasPrecedence: 3! Item was added: + ----- Method: UnderscoreSelectorsTest>>testP3TrailingUnderscore (in category 'tests') ----- + testP3TrailingUnderscore + self + assertSelector: #'value_:' + hasPrecedence: 3! Item was removed: - ----- Method: UnderscoreSelectorsTest>>testPrefFalse (in category 'as yet unclassified') ----- - testPrefFalse - self pref: false during: [self deny: $_ tokenish].! Item was removed: - ----- Method: UnderscoreSelectorsTest>>testPrefTrue (in category 'as yet unclassified') ----- - testPrefTrue - self pref: true during: [self assert: $_ tokenish].! Item was added: + ----- Method: UnderscoreSelectorsTest>>testTokenishFalse (in category 'tests') ----- + testTokenishFalse + self pref: false during: [self deny: $_ tokenish].! Item was added: + ----- Method: UnderscoreSelectorsTest>>testTokenishTrue (in category 'tests') ----- + testTokenishTrue + self pref: true during: [self assert: $_ tokenish].! |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On 14 August 2012 07:27, <[hidden email]> wrote:
> A new version of Tests was added to project The Inbox: > http://source.squeak.org/inbox/Tests-cwp.158.mcz > > ==================== Summary ==================== > > Name: Tests-cwp.158 > Author: cwp > Time: 13 August 2012, 11:27:52.385 pm > UUID: 815626bc-7a56-4869-961d-f81880b4a668 > Ancestors: Tests-cwp.157 > > Renamed the existing tokenish tests, and added tests for selector precedence in the presence of underscores. > > =============== Diff against Tests-cwp.157 =============== > Item was removed: > - ----- Method: UnderscoreSelectorsTest>>testPrefFalse (in category 'as yet unclassified') ----- > - testPrefFalse > - self pref: false during: [self deny: $_ tokenish].! > > Item was removed: > - ----- Method: UnderscoreSelectorsTest>>testPrefTrue (in category 'as yet unclassified') ----- > - testPrefTrue > - self pref: true during: [self assert: $_ tokenish].! > > Item was added: > + ----- Method: UnderscoreSelectorsTest>>testTokenishFalse (in category 'tests') ----- > + testTokenishFalse > + self pref: false during: [self deny: $_ tokenish].! > > Item was added: > + ----- Method: UnderscoreSelectorsTest>>testTokenishTrue (in category 'tests') ----- > + testTokenishTrue > + self pref: true during: [self assert: $_ tokenish].! 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. frank |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar <[hidden email]> 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. 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! Colin |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote:
> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar <[hidden email]> 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. frank > Colin > |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On 14 August 2012 15:38, Frank Shearar <[hidden email]> wrote:
> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar <[hidden email]> 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.) frank > frank > >> Colin >> |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On Fri, 17 Aug 2012, Frank Shearar wrote:
> On 14 August 2012 15:38, Frank Shearar <[hidden email]> wrote: >> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar <[hidden email]> 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. Levente > > frank > >> frank >> >>> Colin >>> > > |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On 17 August 2012 13:07, Levente Uzonyi <[hidden email]> wrote:
> On Fri, 17 Aug 2012, Frank Shearar wrote: > >> On 14 August 2012 15:38, Frank Shearar <[hidden email]> wrote: >>> >>> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >>>> >>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar <[hidden email]> >>>> 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.) frank > Levente > >> >> frank >> >>> frank >>> >>>> Colin >>>> >> >> > |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On Fri, 17 Aug 2012, Frank Shearar wrote:
> On 17 August 2012 13:07, Levente Uzonyi <[hidden email]> wrote: >> On Fri, 17 Aug 2012, Frank Shearar wrote: >> >>> On 14 August 2012 15:38, Frank Shearar <[hidden email]> wrote: >>>> >>>> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >>>>> >>>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar <[hidden email]> >>>>> 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 >>>>> >>> >>> >> > > |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On 17 August 2012 15:02, Levente Uzonyi <[hidden email]> wrote:
> On Fri, 17 Aug 2012, Frank Shearar wrote: > >> On 17 August 2012 13:07, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>> >>>> On 14 August 2012 15:38, Frank Shearar <[hidden email]> wrote: >>>>> >>>>> >>>>> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >>>>>> >>>>>> >>>>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar >>>>>> <[hidden email]> >>>>>> 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...?). But then _ ought to be a valid identifier, given that at the moment unary selectors and identifiers share the same definition. I'd be _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 >>>>>> >>>> >>>> >>> >> >> > |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On Fri, 17 Aug 2012, Frank Shearar wrote:
> On 17 August 2012 15:02, Levente Uzonyi <[hidden email]> wrote: >> On Fri, 17 Aug 2012, Frank Shearar wrote: >> >>> On 17 August 2012 13:07, Levente Uzonyi <[hidden email]> wrote: >>>> >>>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>>> >>>>> On 14 August 2012 15:38, Frank Shearar <[hidden email]> wrote: >>>>>> >>>>>> >>>>>> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar >>>>>>> <[hidden email]> >>>>>>> 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 >>>>>>> >>>>> >>>>> >>>> >>> >>> >> > > |
Re: The Inbox: Tests-cwp.158.mcz
|
|
On 17 August 2012 16:04, Levente Uzonyi <[hidden email]> wrote:
> On Fri, 17 Aug 2012, Frank Shearar wrote: > >> On 17 August 2012 15:02, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>> >>>> On 17 August 2012 13:07, Levente Uzonyi <[hidden email]> wrote: >>>>> >>>>> >>>>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>>>> >>>>>> On 14 August 2012 15:38, Frank Shearar <[hidden email]> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar >>>>>>>> <[hidden email]> >>>>>>>> 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. Oh! I had no idea! | _ | _ := 1. _. "=> 1" Haha! Also, _1 and so on are valid identifiers. frank > 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 >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > |
Re: The Inbox: Tests-cwp.158.mcz
|
|
Yes, not uncommon in other languages
see for example http://underscorejs.org/ Any fixes which allows to have preferences to switch on underscore in identifiers and have a compatibility mode for underscore as assignment operator is fine. It seems that these preferences exclude each other. --Hannes On 8/17/12, Frank Shearar <[hidden email]> wrote: > On 17 August 2012 16:04, Levente Uzonyi <[hidden email]> wrote: >> On Fri, 17 Aug 2012, Frank Shearar wrote: >> >>> On 17 August 2012 15:02, Levente Uzonyi <[hidden email]> wrote: >>>> >>>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>>> >>>>> On 17 August 2012 13:07, Levente Uzonyi <[hidden email]> wrote: >>>>>> >>>>>> >>>>>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>>>>> >>>>>>> On 14 August 2012 15:38, Frank Shearar <[hidden email]> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar >>>>>>>>> <[hidden email]> >>>>>>>>> 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. > > Oh! I had no idea! > > | _ | > _ := 1. > _. "=> 1" > > Haha! Also, _1 and so on are valid identifiers. > > frank > >> 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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > |
Re: The Inbox: Tests-cwp.158.mcz
|
|
In reply to this post by Frank Shearar-3
On 2012-08-17, at 2:39 AM, Frank Shearar <[hidden email]> wrote:
> 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.) Right. I did update the tests; the new version should be in trunk. (I can't verify ATM.) Note in particular the test that asserts #_ has precedence 1. It's not only a valid variable name, it's also valid as a unary message! Colin |
Re: The Inbox: Tests-cwp.158.mcz
|
|
In reply to this post by Hannes Hirzel
On Fri, 17 Aug 2012, H. Hirzel wrote:
> Yes, not uncommon in other languages > > see for example http://underscorejs.org/ > > Any fixes which allows to have preferences to switch on underscore in > identifiers and have a compatibility mode for underscore as assignment > operator is fine. It seems that these preferences exclude each other. No, they don't, but there are some limitations when both preferences are enabled: you can't name your variables and methods as a single underscore and you have to add whitespaces around all underscore assignments. Levente > > --Hannes > > On 8/17/12, Frank Shearar <[hidden email]> wrote: >> On 17 August 2012 16:04, Levente Uzonyi <[hidden email]> wrote: >>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>> >>>> On 17 August 2012 15:02, Levente Uzonyi <[hidden email]> wrote: >>>>> >>>>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>>>> >>>>>> On 17 August 2012 13:07, Levente Uzonyi <[hidden email]> wrote: >>>>>>> >>>>>>> >>>>>>> On Fri, 17 Aug 2012, Frank Shearar wrote: >>>>>>> >>>>>>>> On 14 August 2012 15:38, Frank Shearar <[hidden email]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 14 August 2012 15:36, Colin Putney <[hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Aug 14, 2012 at 5:09 AM, Frank Shearar >>>>>>>>>> <[hidden email]> >>>>>>>>>> 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. >> >> Oh! I had no idea! >> >> | _ | >> _ := 1. >> _. "=> 1" >> >> Haha! Also, _1 and so on are valid identifiers. >> >> frank >> >>> 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 >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |