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
yup
Tim Nieradzik
@tindzk
Right. That's why it fails.
Darren Gibson
@zarthross
it would have worked for everything but case class, but we can't have that either.
Tim Nieradzik
@tindzk
Any idea how we can exclude case classes?
Darren Gibson
@zarthross
unforunately, what we really want is a super class for Tuple1, Tuple2 etc that we can use for FillN instead of Product.
but thats not an option.
Tim Nieradzik
@tindzk
The reason why I don't want to go back to ProductArgs is that it doesn't have IDE support. I'd rather have the users write fillN than having IntelliJ show errors everywhere.
Darren Gibson
@zarthross
intellij still suffering from macros i guess...
Tim Nieradzik
@tindzk
It's because they are using selectDynamic inside
Darren Gibson
@zarthross
def fill[T >: Product1[_]](arg: T) ?
seems case classes are not subclasses of Product1 but Tuple1 is.
sorry, i don't have my compiler in front of me otherwise i'd test.
I'll think on it, but we may end up doing FillOne, though i really don't like it. and it should only compile if the Route has more than one Arg[_] to begin with.
*should NOT compile fillONe if there are more than one Arg[_]
Tim Nieradzik
@tindzk
>: won't work because we actually need to restrict fill[L <: HList, TP <: Product]
I was thinking about tp: TP =:!= Product1[_]
Darren Gibson
@zarthross
might work.
Tim Nieradzik
@tindzk
But that still matches on case classes
Darren Gibson
@zarthross
right...
Tim Nieradzik
@tindzk
A case class can have more than one argument
Darren Gibson
@zarthross
case class parents are Product and Serializeable
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.