Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 17 20:15
    scala-steward closed #140
  • Sep 17 20:15
    scala-steward commented #140
  • Sep 17 20:15
    scala-steward opened #143
  • 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)

rubenpieters
@rubenpieters
ill play around a bit and try to understand it better
Nicolas Rinaudo
@nrinaudo
(I'm in Europe, so we might not be in the same time zones)
rubenpieters
@rubenpieters
im in europe too :)
Nicolas Rinaudo
@nrinaudo
I tried to explain everything in the documentation
if it's not clear enough, that's good feedback
by documentation, I mean the site, not the scaladoc, which is dodgy at best
right, and the second aspect of your issue: you currently need a GroupDecoder for both A and B in order to derive a MatchDecoder[(A, B)]. Since CC4 cannot have a GroupDecoder, you cannot get a MatchDecoder[(CC4, B)] for any B
I can't decide whether this makes sense or is a limitation. I'll need to think about it with a fresh brain.
rubenpieters
@rubenpieters

yep that part I get

but conceptually speaking there is not much difference in my eyes between something like ((A, B), (C, D)) and (A, B, C, D).

so that's why I would think that .evalRegex[((A, B), (C, D)) could work just as .evalRegex[(A, B, C, D)] works

but you don't have to answer this immediately

for now I can work around this and I really appreciate your library :+1:
Nicolas Rinaudo
@nrinaudo
you're absolutely right, but I don't think that's what your example shows
oh, hang on
you're absolutely right, this is what your example shows :)
rubenpieters
@rubenpieters
haha I'm glad it was clear
Nicolas Rinaudo
@nrinaudo
so yeah, I see your point. Not quite sure how to address it, but in an ideal world, what you want to do should work
well. I'm going to crash now, I'm useless in that state. Thanks for the positive feedback and interesting issues! :)
rubenpieters
@rubenpieters
no problem, thanks for the awesome and fast responses :)
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?