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
it was type A from CanFillRoute
which was infered from FlatMapper.Aux[ConvertArgs.type, D, A]
Tim Nieradzik
@tindzk
Exactly, and A was determined for fill()'s arguments
But as matches only takes a string, it A is just HList
Am I mistaken?
I had to inline CanFillRoute because IntelliJ didn't find those methods
Darren Gibson
@zarthross
The type A parameter is just the T part of the Args[T] in the ROUTE hlist. I'm pull out the T's to make A
so its more than just an HList, its a specific type known at compile time.
sadly, true taht Intellij didn't like it, but if you inline it you break some of the shapeless checks.
or so i thought
i'll have to check it all later, i'll then take a look at fillN.
Tim Nieradzik
@tindzk
You're right, thanks. I'll try to add the parameters to matches.
Darren Gibson
@zarthross
Trust me, i wouldn't have made teh CanFillRoute extensions if i could have gotten fill and matches to work otherwise...
if you can figure out how to make it work inlined into Route, that would be awesome and i'm curous how to do it.
Tim Nieradzik
@tindzk
My idea was to use Sized.
There is the problem that the wrong fill() function is chosen when only one argument is provided.
With Sized it may be possible to check whether the Product argument is unary.
Darren Gibson
@zarthross
does it not work if you just remove the single argument fill and only use fill() and fill(TP) ?
Tim Nieradzik
@tindzk
I tried that already.
Darren Gibson
@zarthross
so, i'm not really sure how the fillN works in the first place since the function only has one argument but your passing in a list of arguments
Tim Nieradzik
@tindzk
Are there unary tuples?
fillN receives a tuple and creates an HList from it
Darren Gibson
@zarthross
Tuple1 does exist.
Tim Nieradzik
@tindzk
This works because of: fillN((1, 2, 3)) == fillN(1, 2, 3)
Darren Gibson
@zarthross
auto tupled?
Tim Nieradzik
@tindzk
Yes, it's a Scala feature
Darren Gibson
@zarthross
honestly hadn't seen that before... i must have missed it.
just checked it.. kinda surprised, but i like that better.
'The compiler won't automatically wrap a single value in a Tuple1, however—you just get a compiler error.'
That's why I had to override it.
It works fine for some test cases actually, but not for all
Darren Gibson
@zarthross
glad i wrote lots of tests :P
Tim Nieradzik
@tindzk

Yep, it's this one which fails:

        val r = Root / Arg[FooBar]("asdf")
        val i = r.fill(FooBar("dasd"))

Explicitly writing Tuple1(FooBar("...")) fixes it.

Darren Gibson
@zarthross
set T on def fill[T](arg: T) to an upper type bound on product?
def fill[T >: Product](arg: T) maybe?
probably still break foobar since its a Product huh?
leave it to a FooBar to break stuff..
can't go back to using ProductArgs ?
Tim Nieradzik
@tindzk
It doesn't work either because def fill[L <: HList, TP <: Product](args: TP) gets selected even though FooBar("...") is not a Product.
Darren Gibson
@zarthross
aren't all case classes Products?
Tim Nieradzik
@tindzk
scala> case class FooBar(foo: String)
defined class FooBar

scala> FooBar("test").isInstanceOf[Product]
res0: Boolean = true
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