Some named matches fixes #130
Conversation
README.md
Outdated
| @@ -125,6 +125,8 @@ and the same test will produce logs: | |||
| step User is logged in as a registered user | |||
| ``` | |||
|
|
|||
| In step implementation you will access matched values using the name of the group, i.e. `match["aRegisteredUser"]`. You can access all matched values (including matched by unnamed groups) by their index, starting from 1, i.e. `match["1"]` (note that key is still a string). So you can have more than one named group and you can mix them with unnamed groups. | |||
There was a problem hiding this comment.
Would it be nice (in a later pull request) for this to not be a dictionary, but by a custom type which allowed strings as named matches, and integers to get unnamed ones?
There was a problem hiding this comment.
I can do it with this PR, I already played with this idea, but didn't finish it. I'll also remove then variants of steps with dictionaries as they create unnecessary variations of API
Pod/Core/Step.swift
Outdated
| @@ -8,24 +8,41 @@ | |||
|
|
|||
| import Foundation | |||
|
|
|||
| protocol StepFunctionParameters {} | |||
| public struct StepMatches<T: MatchedStringRepresentable> { | |||
| public let allMatches: [T] | |||
There was a problem hiding this comment.
Should these be public if we are controlling access via the subscript methods (imho they shouldn't be, I'd make them private :)
There was a problem hiding this comment.
Yes, we can expose one or another but IMO there is no point in private subscripts, so I'll make properties private and leave subscripts public, they are also nices from user point of view
There was a problem hiding this comment.
Sorry, I didn't explain myself clearly - that's exactly what I thought, private properties and public subscripts :)
|
Hey - really like |
I noticed few issues with named matches, i.e. it was not possible to have multiple groups or mix then with unnamed. Now it's fixed and README has more details and is more accurate.