The Inbox: Collections-ct.885.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Collections-ct.885.mcz

commits-2
Christoph Thiede uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-ct.885.mcz

==================== Summary ====================

Name: Collections-ct.885
Author: ct
Time: 9 April 2020, 2:35:32.800949 pm
UUID: ddccd842-af02-a448-91f7-7556c8c7bf43
Ancestors: Collections-dtl.884

Proposal for discussion: Add String >> #matches: for polymorphy with RxMatcher.

This allows you to pass patterns strings whereever a RxMatcher is expected. Furthermore, IMHO the name #matches: gives you a better intuition for a test selector than #match: does.

| password patterns |
patterns := { '.{8,}' asRegex. '*password*'. '.*\d.*' asRegex }.
password := Project uiManager requestPassword: 'Enter a fake password'.
self assert: (patterns allSatisfy: [:pattern | pattern matches: password]) description: 'Your password is not safe enough'.

=============== Diff against Collections-dtl.884 ===============

Item was added:
+ ----- Method: String>>matches: (in category 'comparing') -----
+ matches: text
+ "For polymorphy with RxMatcher."
+
+ ^ self match: text!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ct.885.mcz

Christoph Thiede

See also SUnit-ct.127 (#assert:matches:) or Tests-ct.429 (#assertText:) in the Inbox which could benefit from this extension.


I would also welcome to completely rename #match: into #matches: for the reasons described below, how would you think about this?

Or should String >> #matches: rather be an extension method from the Regex-Core package?


Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
Gesendet: Donnerstag, 9. April 2020 14:35:36
An: [hidden email]
Betreff: [squeak-dev] The Inbox: Collections-ct.885.mcz
 
Christoph Thiede uploaded a new version of Collections to project The Inbox:
http://source.squeak.org/inbox/Collections-ct.885.mcz

==================== Summary ====================

Name: Collections-ct.885
Author: ct
Time: 9 April 2020, 2:35:32.800949 pm
UUID: ddccd842-af02-a448-91f7-7556c8c7bf43
Ancestors: Collections-dtl.884

Proposal for discussion: Add String >> #matches: for polymorphy with RxMatcher.

This allows you to pass patterns strings whereever a RxMatcher is expected. Furthermore, IMHO the name #matches: gives you a better intuition for a test selector than #match: does.

| password patterns |
patterns := { '.{8,}' asRegex. '*password*'. '.*\d.*' asRegex }.
password := Project uiManager requestPassword: 'Enter a fake password'.
self assert: (patterns allSatisfy: [:pattern | pattern matches: password]) description: 'Your password is not safe enough'.

=============== Diff against Collections-dtl.884 ===============

Item was added:
+ ----- Method: String>>matches: (in category 'comparing') -----
+ matches: text
+        "For polymorphy with RxMatcher."
+
+        ^ self match: text!




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ct.885.mcz

Jakob Reschke-2
The patterns matched by match: are not regular expressions. Could this
intermixing of vocabulary lead to confusion or even bugs (when someone
is missing a test for their matching use case and forgot the asRegex)?

Am Do., 9. Apr. 2020 um 14:39 Uhr schrieb Thiede, Christoph
<[hidden email]>:

>
> See also SUnit-ct.127 (#assert:matches:) or Tests-ct.429 (#assertText:) in the Inbox which could benefit from this extension.
>
>
> I would also welcome to completely rename #match: into #matches: for the reasons described below, how would you think about this?
>
> Or should String >> #matches: rather be an extension method from the Regex-Core package?
>
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
> Gesendet: Donnerstag, 9. April 2020 14:35:36
> An: [hidden email]
> Betreff: [squeak-dev] The Inbox: Collections-ct.885.mcz
>
> Christoph Thiede uploaded a new version of Collections to project The Inbox:
> http://source.squeak.org/inbox/Collections-ct.885.mcz
>
> ==================== Summary ====================
>
> Name: Collections-ct.885
> Author: ct
> Time: 9 April 2020, 2:35:32.800949 pm
> UUID: ddccd842-af02-a448-91f7-7556c8c7bf43
> Ancestors: Collections-dtl.884
>
> Proposal for discussion: Add String >> #matches: for polymorphy with RxMatcher.
>
> This allows you to pass patterns strings whereever a RxMatcher is expected. Furthermore, IMHO the name #matches: gives you a better intuition for a test selector than #match: does.
>
> | password patterns |
> patterns := { '.{8,}' asRegex. '*password*'. '.*\d.*' asRegex }.
> password := Project uiManager requestPassword: 'Enter a fake password'.
> self assert: (patterns allSatisfy: [:pattern | pattern matches: password]) description: 'Your password is not safe enough'.
>
> =============== Diff against Collections-dtl.884 ===============
>
> Item was added:
> + ----- Method: String>>matches: (in category 'comparing') -----
> + matches: text
> +        "For polymorphy with RxMatcher."
> +
> +        ^ self match: text!
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ct.885.mcz

Christoph Thiede

Good question which I cannot answer :-)


The idea is that you could use whitespace patterns ('Squeak *alpha') interchangeably with more powerful regular expressions ('Squeak \d+\.\d+alpha' asRegex) without needing to define separate messages wherever patterns are used. For example, we would need implement both #assert:matches: *and* #assert:matchesRegex: (TestCase), both #classesIn: *and* #classesInRegex: (provided that we wanted this feature) etc., each pair with exactly the same implementations that only deviate in terms of sending #match: vs. #matches:.
(For a practical example, you could take a look at all these methods from SqueakByExample that contain 'match' in their name and which all use #matches:. This project also includes a String >> #matches: extension so it is much easier to feed these morph query methods either with regexs or with simple patterns where regexs are unnecessary complicated.)

I agree that it might be confusing if you forget the #asRegex. However, I think this is a common problem in a language with duck typing and very-late binding. On the contrary, one could also argue that it might be confusing that in some situations you need to send #match:, but in other situations #matches: instead, as they basically do the same.

---

Hm, this discussion reminds me a bit of the recent debate about Symbol >> #numArgs/#value:value:. There we found that instead of handling symbols like blocks, we could also write an explicit converter (#asBlock). How would you think about a similar converter in this case? :-)
Something like: 'Squeak *alpha' patternAsRegex
'ab*' asRegex matches: 'a'. "true"
'ab*' asRegex matches: 'abb'. "true"
'ab*' patternAsRegex matches: 'a'. "false"
'ab*' patternAsRegex matches: 'abc'. "true"

Pro: Actually a matcher - you don't have a string that partially behaves like a matcher and follows the same protocol, but an actual matcher. So you could also say 'ab*' patternAsRegex matchesIn:collect: ...
Contra: Actually a matcher - this can be a significant drawback in terms of performance. For a simple '*xyz*' match, the regex equivalent was more than 100x slower than the whitespace version.
A third variant would be an extra WhitespaceMatcher. But do we really need such a class?

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Freitag, 10. April 2020 11:36:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Collections-ct.885.mcz
 
The patterns matched by match: are not regular expressions. Could this
intermixing of vocabulary lead to confusion or even bugs (when someone
is missing a test for their matching use case and forgot the asRegex)?

Am Do., 9. Apr. 2020 um 14:39 Uhr schrieb Thiede, Christoph
<[hidden email]>:
>
> See also SUnit-ct.127 (#assert:matches:) or Tests-ct.429 (#assertText:) in the Inbox which could benefit from this extension.
>
>
> I would also welcome to completely rename #match: into #matches: for the reasons described below, how would you think about this?
>
> Or should String >> #matches: rather be an extension method from the Regex-Core package?
>
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
> Gesendet: Donnerstag, 9. April 2020 14:35:36
> An: [hidden email]
> Betreff: [squeak-dev] The Inbox: Collections-ct.885.mcz
>
> Christoph Thiede uploaded a new version of Collections to project The Inbox:
> http://source.squeak.org/inbox/Collections-ct.885.mcz
>
> ==================== Summary ====================
>
> Name: Collections-ct.885
> Author: ct
> Time: 9 April 2020, 2:35:32.800949 pm
> UUID: ddccd842-af02-a448-91f7-7556c8c7bf43
> Ancestors: Collections-dtl.884
>
> Proposal for discussion: Add String >> #matches: for polymorphy with RxMatcher.
>
> This allows you to pass patterns strings whereever a RxMatcher is expected. Furthermore, IMHO the name #matches: gives you a better intuition for a test selector than #match: does.
>
> | password patterns |
> patterns := { '.{8,}' asRegex. '*password*'. '.*\d.*' asRegex }.
> password := Project uiManager requestPassword: 'Enter a fake password'.
> self assert: (patterns allSatisfy: [:pattern | pattern matches: password]) description: 'Your password is not safe enough'.
>
> =============== Diff against Collections-dtl.884 ===============
>
> Item was added:
> + ----- Method: String>>matches: (in category 'comparing') -----
> + matches: text
> +        "For polymorphy with RxMatcher."
> +
> +        ^ self match: text!
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ct.885.mcz

marcel.taeumel
Hmm... I always get confused whether the receiver of #match: is the pattern or the thing that should match the pattern. I suppose that the #asRegex variant makes it explicit and is thus quite readable in this regard.

Best,
Marcel

Am 11.04.2020 15:12:01 schrieb Thiede, Christoph <[hidden email]>:

Good question which I cannot answer :-)


The idea is that you could use whitespace patterns ('Squeak *alpha') interchangeably with more powerful regular expressions ('Squeak \d+\.\d+alpha' asRegex) without needing to define separate messages wherever patterns are used. For example, we would need implement both #assert:matches: *and* #assert:matchesRegex: (TestCase), both #classesIn: *and* #classesInRegex: (provided that we wanted this feature) etc., each pair with exactly the same implementations that only deviate in terms of sending #match: vs. #matches:.
(For a practical example, you could take a look at all these methods from SqueakByExample that contain 'match' in their name and which all use #matches:. This project also includes a String >> #matches: extension so it is much easier to feed these morph query methods either with regexs or with simple patterns where regexs are unnecessary complicated.)

I agree that it might be confusing if you forget the #asRegex. However, I think this is a common problem in a language with duck typing and very-late binding. On the contrary, one could also argue that it might be confusing that in some situations you need to send #match:, but in other situations #matches: instead, as they basically do the same.

---

Hm, this discussion reminds me a bit of the recent debate about Symbol >> #numArgs/#value:value:. There we found that instead of handling symbols like blocks, we could also write an explicit converter (#asBlock). How would you think about a similar converter in this case? :-)
Something like: 'Squeak *alpha' patternAsRegex
'ab*' asRegex matches: 'a'. "true"
'ab*' asRegex matches: 'abb'. "true"
'ab*' patternAsRegex matches: 'a'. "false"
'ab*' patternAsRegex matches: 'abc'. "true"

Pro: Actually a matcher - you don't have a string that partially behaves like a matcher and follows the same protocol, but an actual matcher. So you could also say 'ab*' patternAsRegex matchesIn:collect: ...
Contra: Actually a matcher - this can be a significant drawback in terms of performance. For a simple '*xyz*' match, the regex equivalent was more than 100x slower than the whitespace version.
A third variant would be an extra WhitespaceMatcher. But do we really need such a class?

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Freitag, 10. April 2020 11:36:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Collections-ct.885.mcz
 
The patterns matched by match: are not regular expressions. Could this
intermixing of vocabulary lead to confusion or even bugs (when someone
is missing a test for their matching use case and forgot the asRegex)?

Am Do., 9. Apr. 2020 um 14:39 Uhr schrieb Thiede, Christoph
<[hidden email]>:
>
> See also SUnit-ct.127 (#assert:matches:) or Tests-ct.429 (#assertText:) in the Inbox which could benefit from this extension.
>
>
> I would also welcome to completely rename #match: into #matches: for the reasons described below, how would you think about this?
>
> Or should String >> #matches: rather be an extension method from the Regex-Core package?
>
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
> Gesendet: Donnerstag, 9. April 2020 14:35:36
> An: [hidden email]
> Betreff: [squeak-dev] The Inbox: Collections-ct.885.mcz
>
> Christoph Thiede uploaded a new version of Collections to project The Inbox:
> http://source.squeak.org/inbox/Collections-ct.885.mcz
>
> ==================== Summary ====================
>
> Name: Collections-ct.885
> Author: ct
> Time: 9 April 2020, 2:35:32.800949 pm
> UUID: ddccd842-af02-a448-91f7-7556c8c7bf43
> Ancestors: Collections-dtl.884
>
> Proposal for discussion: Add String >> #matches: for polymorphy with RxMatcher.
>
> This allows you to pass patterns strings whereever a RxMatcher is expected. Furthermore, IMHO the name #matches: gives you a better intuition for a test selector than #match: does.
>
> | password patterns |
> patterns := { '.{8,}' asRegex. '*password*'. '.*\d.*' asRegex }.
> password := Project uiManager requestPassword: 'Enter a fake password'.
> self assert: (patterns allSatisfy: [:pattern | pattern matches: password]) description: 'Your password is not safe enough'.
>
> =============== Diff against Collections-dtl.884 ===============
>
> Item was added:
> + ----- Method: String>>matches: (in category 'comparing') -----
> + matches: text
> +        "For polymorphy with RxMatcher."
> +
> +        ^ self match: text!
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ct.885.mcz

Jakob Reschke-2
Isn't this more of a problem when you attempt to *write* the code?
(Assuming acceptable variable names.) Then asRegex will not help you
because you have not written it yet. :-)

Am Mo., 20. Apr. 2020 um 18:19 Uhr schrieb Marcel Taeumel
<[hidden email]>:

>
> Hmm... I always get confused whether the receiver of #match: is the pattern or the thing that should match the pattern. I suppose that the #asRegex variant makes it explicit and is thus quite readable in this regard.
>
> Best,
> Marcel
>
> Am 11.04.2020 15:12:01 schrieb Thiede, Christoph <[hidden email]>:
>
> Good question which I cannot answer :-)
>
>
> The idea is that you could use whitespace patterns ('Squeak *alpha') interchangeably with more powerful regular expressions ('Squeak \d+\.\d+alpha' asRegex) without needing to define separate messages wherever patterns are used. For example, we would need implement both #assert:matches: *and* #assert:matchesRegex: (TestCase), both #classesIn: *and* #classesInRegex: (provided that we wanted this feature) etc., each pair with exactly the same implementations that only deviate in terms of sending #match: vs. #matches:.
> (For a practical example, you could take a look at all these methods from SqueakByExample that contain 'match' in their name and which all use #matches:. This project also includes a String >> #matches: extension so it is much easier to feed these morph query methods either with regexs or with simple patterns where regexs are unnecessary complicated.)
>
> I agree that it might be confusing if you forget the #asRegex. However, I think this is a common problem in a language with duck typing and very-late binding. On the contrary, one could also argue that it might be confusing that in some situations you need to send #match:, but in other situations #matches: instead, as they basically do the same.
>
> ---
>
> Hm, this discussion reminds me a bit of the recent debate about Symbol >> #numArgs/#value:value:. There we found that instead of handling symbols like blocks, we could also write an explicit converter (#asBlock). How would you think about a similar converter in this case? :-)
> Something like: 'Squeak *alpha' patternAsRegex
> 'ab*' asRegex matches: 'a'. "true"
> 'ab*' asRegex matches: 'abb'. "true"
> 'ab*' patternAsRegex matches: 'a'. "false"
> 'ab*' patternAsRegex matches: 'abc'. "true"
>
> Pro: Actually a matcher - you don't have a string that partially behaves like a matcher and follows the same protocol, but an actual matcher. So you could also say 'ab*' patternAsRegex matchesIn:collect: ...
> Contra: Actually a matcher - this can be a significant drawback in terms of performance. For a simple '*xyz*' match, the regex equivalent was more than 100x slower than the whitespace version.
> A third variant would be an extra WhitespaceMatcher. But do we really need such a class?
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
> Gesendet: Freitag, 10. April 2020 11:36:37
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] The Inbox: Collections-ct.885.mcz
>
> The patterns matched by match: are not regular expressions. Could this
> intermixing of vocabulary lead to confusion or even bugs (when someone
> is missing a test for their matching use case and forgot the asRegex)?
>
> Am Do., 9. Apr. 2020 um 14:39 Uhr schrieb Thiede, Christoph
> <[hidden email]>:
> >
> > See also SUnit-ct.127 (#assert:matches:) or Tests-ct.429 (#assertText:) in the Inbox which could benefit from this extension.
> >
> >
> > I would also welcome to completely rename #match: into #matches: for the reasons described below, how would you think about this?
> >
> > Or should String >> #matches: rather be an extension method from the Regex-Core package?
> >
> >
> > Best,
> > Christoph
> > ________________________________
> > Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
> > Gesendet: Donnerstag, 9. April 2020 14:35:36
> > An: [hidden email]
> > Betreff: [squeak-dev] The Inbox: Collections-ct.885.mcz
> >
> > Christoph Thiede uploaded a new version of Collections to project The Inbox:
> > http://source.squeak.org/inbox/Collections-ct.885.mcz
> >
> > ==================== Summary ====================
> >
> > Name: Collections-ct.885
> > Author: ct
> > Time: 9 April 2020, 2:35:32.800949 pm
> > UUID: ddccd842-af02-a448-91f7-7556c8c7bf43
> > Ancestors: Collections-dtl.884
> >
> > Proposal for discussion: Add String >> #matches: for polymorphy with RxMatcher.
> >
> > This allows you to pass patterns strings whereever a RxMatcher is expected. Furthermore, IMHO the name #matches: gives you a better intuition for a test selector than #match: does.
> >
> > | password patterns |
> > patterns := { '.{8,}' asRegex. '*password*'. '.*\d.*' asRegex }.
> > password := Project uiManager requestPassword: 'Enter a fake password'.
> > self assert: (patterns allSatisfy: [:pattern | pattern matches: password]) description: 'Your password is not safe enough'.
> >
> > =============== Diff against Collections-dtl.884 ===============
> >
> > Item was added:
> > + ----- Method: String>>matches: (in category 'comparing') -----
> > + matches: text
> > +        "For polymorphy with RxMatcher."
> > +
> > +        ^ self match: text!
> >
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ct.885.mcz

Christoph Thiede

Nice argument, Jakob! Or asked the other way around:

How would you explain to a new Squeaker that "match:" means a whitespace matching test and "matches:" means a regex matching test? This just feels random to me. :-)

#match: is not a nice name at all, IMHO, because it does not make clear that this is a test selector.

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Montag, 20. April 2020 20:07:18
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Collections-ct.885.mcz
 
Isn't this more of a problem when you attempt to *write* the code?
(Assuming acceptable variable names.) Then asRegex will not help you
because you have not written it yet. :-)

Am Mo., 20. Apr. 2020 um 18:19 Uhr schrieb Marcel Taeumel
<[hidden email]>:
>
> Hmm... I always get confused whether the receiver of #match: is the pattern or the thing that should match the pattern. I suppose that the #asRegex variant makes it explicit and is thus quite readable in this regard.
>
> Best,
> Marcel
>
> Am 11.04.2020 15:12:01 schrieb Thiede, Christoph <[hidden email]>:
>
> Good question which I cannot answer :-)
>
>
> The idea is that you could use whitespace patterns ('Squeak *alpha') interchangeably with more powerful regular expressions ('Squeak \d+\.\d+alpha' asRegex) without needing to define separate messages wherever patterns are used. For example, we would need implement both #assert:matches: *and* #assert:matchesRegex: (TestCase), both #classesIn: *and* #classesInRegex: (provided that we wanted this feature) etc., each pair with exactly the same implementations that only deviate in terms of sending #match: vs. #matches:.
> (For a practical example, you could take a look at all these methods from SqueakByExample that contain 'match' in their name and which all use #matches:. This project also includes a String >> #matches: extension so it is much easier to feed these morph query methods either with regexs or with simple patterns where regexs are unnecessary complicated.)
>
> I agree that it might be confusing if you forget the #asRegex. However, I think this is a common problem in a language with duck typing and very-late binding. On the contrary, one could also argue that it might be confusing that in some situations you need to send #match:, but in other situations #matches: instead, as they basically do the same.
>
> ---
>
> Hm, this discussion reminds me a bit of the recent debate about Symbol >> #numArgs/#value:value:. There we found that instead of handling symbols like blocks, we could also write an explicit converter (#asBlock). How would you think about a similar converter in this case? :-)
> Something like: 'Squeak *alpha' patternAsRegex
> 'ab*' asRegex matches: 'a'. "true"
> 'ab*' asRegex matches: 'abb'. "true"
> 'ab*' patternAsRegex matches: 'a'. "false"
> 'ab*' patternAsRegex matches: 'abc'. "true"
>
> Pro: Actually a matcher - you don't have a string that partially behaves like a matcher and follows the same protocol, but an actual matcher. So you could also say 'ab*' patternAsRegex matchesIn:collect: ...
> Contra: Actually a matcher - this can be a significant drawback in terms of performance. For a simple '*xyz*' match, the regex equivalent was more than 100x slower than the whitespace version.
> A third variant would be an extra WhitespaceMatcher. But do we really need such a class?
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
> Gesendet: Freitag, 10. April 2020 11:36:37
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] The Inbox: Collections-ct.885.mcz
>
> The patterns matched by match: are not regular expressions. Could this
> intermixing of vocabulary lead to confusion or even bugs (when someone
> is missing a test for their matching use case and forgot the asRegex)?
>
> Am Do., 9. Apr. 2020 um 14:39 Uhr schrieb Thiede, Christoph
> <[hidden email]>:
> >
> > See also SUnit-ct.127 (#assert:matches:) or Tests-ct.429 (#assertText:) in the Inbox which could benefit from this extension.
> >
> >
> > I would also welcome to completely rename #match: into #matches: for the reasons described below, how would you think about this?
> >
> > Or should String >> #matches: rather be an extension method from the Regex-Core package?
> >
> >
> > Best,
> > Christoph
> > ________________________________
> > Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
> > Gesendet: Donnerstag, 9. April 2020 14:35:36
> > An: [hidden email]
> > Betreff: [squeak-dev] The Inbox: Collections-ct.885.mcz
> >
> > Christoph Thiede uploaded a new version of Collections to project The Inbox:
> > http://source.squeak.org/inbox/Collections-ct.885.mcz
> >
> > ==================== Summary ====================
> >
> > Name: Collections-ct.885
> > Author: ct
> > Time: 9 April 2020, 2:35:32.800949 pm
> > UUID: ddccd842-af02-a448-91f7-7556c8c7bf43
> > Ancestors: Collections-dtl.884
> >
> > Proposal for discussion: Add String >> #matches: for polymorphy with RxMatcher.
> >
> > This allows you to pass patterns strings whereever a RxMatcher is expected. Furthermore, IMHO the name #matches: gives you a better intuition for a test selector than #match: does.
> >
> > | password patterns |
> > patterns := { '.{8,}' asRegex. '*password*'. '.*\d.*' asRegex }.
> > password := Project uiManager requestPassword: 'Enter a fake password'.
> > self assert: (patterns allSatisfy: [:pattern | pattern matches: password]) description: 'Your password is not safe enough'.
> >
> > =============== Diff against Collections-dtl.884 ===============
> >
> > Item was added:
> > + ----- Method: String>>matches: (in category 'comparing') -----
> > + matches: text
> > +        "For polymorphy with RxMatcher."
> > +
> > +        ^ self match: text!
> >
> >
> >
>
>