Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 09 2020 17:00
    tindzk commented #37
  • Mar 08 2020 01:03
    raquo commented #37
  • Mar 07 2020 21:19
    raquo edited #37
  • Mar 07 2020 21:15
    raquo edited #37
  • Mar 07 2020 21:12
    raquo edited #37
  • Mar 07 2020 21:12
    raquo edited #37
  • Mar 07 2020 21:11
    raquo edited #37
  • Mar 07 2020 21:10
    raquo opened #37
  • Jul 10 2019 07:26

    tindzk on v0.2.1

    (compare)

  • Jul 10 2019 07:26

    tindzk on master

    Build: Publish v0.2.1 Build: Change version to v0.2.2… (compare)

  • Jul 09 2019 14:59

    tindzk on manual

    (compare)

  • Jul 09 2019 14:59

    tindzk on master

    Manual: Add example for encodin… Merge pull request #36 from spa… (compare)

  • Jul 09 2019 14:59
    tindzk closed #36
  • Jul 09 2019 14:59

    tindzk on scala213

    (compare)

  • Jul 09 2019 14:58

    tindzk on master

    Build: Add support for Scala 2.… Merge pull request #35 from spa… (compare)

  • Jul 09 2019 14:58
    tindzk closed #35
  • Jul 09 2019 14:57

    tindzk on parse-opt-elems

    (compare)

  • Jul 09 2019 14:57

    tindzk on master

    Route: Fix parsing of optional … Merge pull request #34 from spa… (compare)

  • Jul 09 2019 14:57
    tindzk closed #34
  • Jul 09 2019 14:57

    tindzk on redundant-amp

    (compare)

Darren Gibson
@zarthross
and Tuple* has the same parents
so, we can't say... we want a Product, but not a case class
because it is a product, and i don't think we want a fill method for every Product* type there is
Tim Nieradzik
@tindzk
Makes sense. That's a shame.
Darren Gibson
@zarthross
what if we do an implicit conversion based the number of Args ?
Tim Nieradzik
@tindzk
Can you elaborate?
Darren Gibson
@zarthross
we convert to one of two CanFill types, the first has the single arg version and the second has teh multi arg fill
we use the L type parameter to check
something like SOMET :: HNil vs SOMETS :: SOMEOTHERThatsnotHNIL
Tim Nieradzik
@tindzk
Do you mean that we should just make fill take a HList? And provide implicit conversions?
Darren Gibson
@zarthross
leave fill the way it is, but make an 2 extensions on Route based on the ROUTE type, one that takes a fill of 1 arg, the other that takes more than 1 arg.
add limites on the conversion of Route based on teh number of Arg type params
Tim Nieradzik
@tindzk
Hm. That's an interesting idea. So we just decide which fill to take based on the number of arguments in ROUTE?
Darren Gibson
@zarthross
yeah
thats the idea
Tim Nieradzik
@tindzk
Yes, that should work, but I suspect IntelliJ may still complain.
Darren Gibson
@zarthross
its not using a dynamic call
intellij handles implicits just fine
Tim Nieradzik
@tindzk
Even if the implicit itself uses some Shapeless functionality?
Darren Gibson
@zarthross
the implicit conversion is just using an implicit parameter
the idea is, only one of the 2 extension classes will find an implicit parameter depending on how many args their are.
i don't honestly know if it'll work, but its worth a try.
Tim Nieradzik
@tindzk
Ok, I will have to try it out tomorrow. Already spent all day with Shapeless :)
Darren Gibson
@zarthross
haha, yeah.. i spent just half the week figureing out how to get the that L/ARGS type parameter to infer correctly.
and then on how to get ProductArgs to work
*which is why i went with 'fill' instead of 'apply', btw, was a compromise not a design choice.
Tim Nieradzik
@tindzk
Yeah, it's a lot of fun and the code is incredibly concise. The test cases are much longer. :)
Darren Gibson
@zarthross
i used scoverage to try and get my coverage up
Tim Nieradzik
@tindzk
Can we rename fill? The first time I saw it, I didn't know what it was supposed to do.
Darren Gibson
@zarthross
definately
Tim Nieradzik
@tindzk
Can we add Scoverage as an sbt plugin?
Darren Gibson
@zarthross
sure
Tim Nieradzik
@tindzk
Last time I checked it didn't work that well with Scala.js.
Darren Gibson
@zarthross
still doesn't
i just added it to my globals
scoverage/sbt-scoverage#101
since all the tests i was doing was in shared, i just ran them on the JVM
Tim Nieradzik
@tindzk
If we had just one version of fill, we could rename it back to apply.
Darren Gibson
@zarthross
that would be better, we'll see what we can do.
i'll play with the fill/fillN issue tonight, i'll let you know by tomorrow morning my results.
Tim Nieradzik
@tindzk
Awesome, thanks.
What task should we tackle next?
I am wondering whether we should also support parsing URLs like http://a/b/c. I think your split() will misbehave.
We should also allow "a" / "b" (relative paths).
Darren Gibson
@zarthross
Been wondering those 2 things myself.
i was mostly thinking in the terms of what a javascript router would be concerned with, and thats everything after the port in the URL
so, the parse will just ignore the http://host:port/ part
Darren Gibson
@zarthross
I didn't get around to fixing the .fill issue yesterday. I'll have some more time this afternoon so i'll take another look.
Tim Nieradzik
@tindzk
@zarthross I extended the evidence chain to also check the number of route parameters as per your suggestion. As long as fill and fillN have different names, the proofs hold. But if I rename both methods to the same name, it fails with a confusing compilation error. Could you have a look at it?
Tim Nieradzik
@tindzk
Ok, I understand the error now. It selects fill with TP and then cannot prove that ParamsCount != 1, thus it fails. I expected it to fall back to the fill method with a single argument, but it doesn't.