Finally at the 2nd try :grin:

# advent-of-code

[littlelightcz]

Finally at the 2nd try 😁

Day_3__part_A.kt

[robin]

Oh, that Regex library looks sexy!

[littlelightcz]

Thank you 🙂 it's actually one of mine, you can try here: https://github.com/LittleLightCz/Rojo

[robin]

Nice! Any plans on doing a kotlin version without annotations and reflection?

[karelpeeters]

Lowkey advertising 😜

[littlelightcz]

😄 good stuff needs to be advertised 😉 😁 (I am joking). I was thinking about it, but I don't have the complete vision yet. Anyway one interesting thing could be rewriting some parts using inline functions to not lose any performance at all - that would be one of possible benefits of writing a Kotlin version.

[karelpeeters]

I don't know how useful this would be for Kotlin-only, since regex parsing can be made very terse already (take a look at my code for example).

[robin]

In your code it's terse because you're not matching too many groups, and because all of them have the same type and can simply be mapped. If you have more complex regexes it quickly becomes annoying (and regularly does for me) to add component functions for destructuring, manually parsing the groups, etc

[littlelightcz]

@karelpeeters Ah true, I haven't explored Kotlin's in-build regex enhancements in detail yet 🙂 , however for creating of POJOs specifically, Rojo still seems like a more convenient alternative to me.

[littlelightcz]

@robin also true 🙂 when one needs different types like numbers, Dates, or even completely different ones ... then it gets more difficult.

[karelpeeters]

Yeah true, I kinda lost the bigger picture there 😄

[todd.ginsberg]

Late to this but that is so cool. What a good idea.

[robin]

Alright, I'm doing it know. Going to explore how this can be done in a nice Kotliny way

[robin]

First version can extract simple string groups!
This code prints {entire=123.456, first=123, second=456}

[robin]

Next one can already do the first example on https://github.com/LittleLightCz/Rojo
Although this just finds the first match in the passed string, and doesn't allow searching for multiple matches, gonna have to work on that.

[robin]

Now also with implicit group access by order of appearance (optional, throws if you try to use an implicit group after an explicit group has been declared)

[littlelightcz]

Nice and interesting 🙂 . But let's see if you can find a way how to match multiple `FruitPicker`s and return e.g. a List of them - this part seemed quite tricky to do using delegates to me.

[robin]

Done! Companion Objects to the rescue 😄
Not too happy that I have to repeat the class name a few times, maybe that can be done a little bit more elegantly...

[robin]

Next example cracked: Nested matching!

[robin]

Okay I've put my efforts so far up on github, if anyone wants to have a look and maybe even collaborate on it: https://github.com/roschlau/kregex

[robin]

Going to bed for now, might continue tomorrow 😉

[karelpeeters]

A suggestion: add by namedGroup that finds a capturing group with the name of the property.

[littlelightcz]

Looks good so far 👍😊

[littlelightcz]

Maybe you could get rid of companions and inheritance completely by moving instantiation of RegexMatcher to a 'factory function' + take advantage of reified generic types. So it could look like kregex<FruitPicker>("some regex").findAll(input).asList()