Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 13 23:59
    scala-steward closed #141
  • Jul 13 23:59
    scala-steward commented #141
  • Jul 13 23:59
    scala-steward opened #142
  • Jul 11 23:30
    scala-steward opened #141
  • Jul 11 23:30
    scala-steward opened #140
  • Mar 20 19:10
    scala-steward closed #131
  • Mar 20 19:10
    scala-steward commented #131
  • Mar 20 19:10
    scala-steward opened #139
  • Feb 16 12:05

    nrinaudo on master

    Update sbt to 1.6.2 Merge pull request #138 from nr… (compare)

  • Feb 16 12:05
    nrinaudo closed #138
  • Feb 16 11:46
    nrinaudo opened #138
  • Feb 16 11:45

    nrinaudo on update-sbt-1.6.2

    Update sbt to 1.6.2 (compare)

  • Feb 16 11:10

    nrinaudo on update-kantan.sbt-2.8.2

    (compare)

  • Feb 16 11:10

    nrinaudo on master

    Update to kantan.sbt 2.8.2 Merge pull request #137 from nr… (compare)

  • Feb 16 11:10
    nrinaudo closed #137
  • Feb 16 11:01
    nrinaudo opened #137
  • Feb 16 11:01

    nrinaudo on update-kantan.sbt-2.8.2

    Update to kantan.sbt 2.8.2 (compare)

  • Jan 13 17:58
    scala-steward closed #132
  • Jan 13 17:58
    scala-steward commented #132
  • Jan 13 17:58
    scala-steward opened #136
Nicolas Rinaudo
@nrinaudo
I'm just excited to meet someone that actually uses my work :)
rubenpieters
@rubenpieters

I played around with this a bit and here is one idea that works quite cleanly in the current model:
https://gist.github.com/rubenpieters/05cbc4d3884bcdf3aaf9ad8bd9920483

(I also had another idea where matchdecoders could be represented as a list of groupdecoders but that would require a lot of breaking stuff in the current implementation)

but for the progressed match gist: if there is a way to know how much of the matches a decoder will take from the matcher then the implicit could be generalized to more arbitrary shapes.

Nicolas Rinaudo
@nrinaudo
Yeah, that's pretty much the same direction I was going. It'll still need to break a lot things, so I honestly doubt I'll start before the next release.
Which should hopefully be soon, the only large outstanding issue is adding support for java 8 time.
Nicolas Rinaudo
@nrinaudo
by the way, may I ask how you stumbled on kantan.regex? I've not exaclty gone out of my way to advertise it
rubenpieters
@rubenpieters
I was googling something with scala and regex, i dont remember what exactly
it was not simply scala regex, but something more specific
Nicolas Rinaudo
@nrinaudo
"amazing scala regex library"
probably.
rubenpieters
@rubenpieters
haha
Nicolas Rinaudo
@nrinaudo
right, so, about your suggested improvement. Having some sort of state aware match implementation sounds like a good way to do it
rubenpieters
@rubenpieters
ah it was "github scala regex gr library" I was actually looking for a gist or a repo I remember seeing somewhere but then one of the top matches is your repo if you google that
Nicolas Rinaudo
@nrinaudo
what bothers me about it a bit is that it'd strictly be for the shapeless module, and is actually less powerful than what exists now
what's gr stand for?
rubenpieters
@rubenpieters
i dont know I just thought that in the title of the thing I was looking for that was used, I think its simply an abbreviation for groups or something
Nicolas Rinaudo
@nrinaudo
when I say less powerful, I mean that if you write your own MatchDecoder, you can grab groups for anywhere in the match to build your values. With a state aware match, you must work with the assumption that they're ordered
rubenpieters
@rubenpieters
hmm yes good point
Nicolas Rinaudo
@nrinaudo
which can be problematic with recursive types - how would you deal with a Tree[A], where a node might contain a node that might contain a node?
I don't think that's reason enough to drop the idea - at worst, it's a good default behaviour
but I want to give it more thoughts, because the modifications would spill into the rest of the library and make it backward-incompatible
rubenpieters
@rubenpieters
I'm not sure if shapeless sort of has an ordering for its nested hlists representation for case classes, I think it might
Nicolas Rinaudo
@nrinaudo
I really don't know. At least it'd need to decide whether it wants to do a depth- or breadth- first traversal
rubenpieters
@rubenpieters
breadth first seems kinda counterintuitive to me, but maybe thats just me
Nicolas Rinaudo
@nrinaudo
that's the entire point: I don't know, it probably depends on the user, and whatever choice we make will be wrong sometimes :)
so my point is: your idea is sound but will require me to give it more thoughts. Do you want me to show you how to deal with your specific (CC1, CC4) issue if that's a blocker?
rubenpieters
@rubenpieters
no the current workaround I have is fine for me
Nicolas Rinaudo
@nrinaudo
because your issue is not that you can't write a MatchDecoder[(CC1, CC4)] instance, but that you can't derive one automatically
which is absolutely true
rubenpieters
@rubenpieters
yep I know
Nicolas Rinaudo
@nrinaudo
ok, cool
automatic derivation is always going to be limited anyway - what happens if your case class fields are not declared in exactly the same order as your regex groups?
it makes a lot of assumptions about types and results, and those are clearly not always the correct ones
that's why kantan.regex also provides non-generic helpers for case class decoder creation - I don't know if you've seen those?
rubenpieters
@rubenpieters
hmm I don't think so
I'm not sure what you're referring to exactly
Nicolas Rinaudo
@nrinaudo
MatchDecoder.decoder and MatchDecoder.ordered
MatchDecoder.decoder(1, 3, 5) { (i: Int, d: Date, l: Long) => new MyType(i, d, l) }
rubenpieters
@rubenpieters
ah ok cool, is that one on the website somewhere? I saw the ordered, but I didn't see that one
Nicolas Rinaudo
@nrinaudo
it's more hinted at than properly explained, I probably need to address that
ah hang on, no, it is
(and so we're clear: all the documentation's code is actually compiled and executed, so if it's in the doc, you know it's correct. I'm really proud of that)
ok, so I just re-read that example, and it was a mistake on my part to use ordered in the documentation. I should have used decoder. I'll create an issue
rubenpieters
@rubenpieters
thats pretty cool
Nicolas Rinaudo
@nrinaudo
is it clear what MatchDecoder.decoder does, and that it supports any arity from 1 to 22, or do you need some help?
rubenpieters
@rubenpieters
yes that is clear, but since it takes implicit groupdecoders it wont work when I will put multiple case class in it, is that right?
Nicolas Rinaudo
@nrinaudo
(just got pulled in on a meeting)
rubenpieters
@rubenpieters
ok nevermind the previous comment, I understand a bit better what it does now, the .decoder thing is a nice solution for the user to specify the order of things he wants to do
Nicolas Rinaudo
@nrinaudo
or build nested case class structures
rubenpieters
@rubenpieters
yep