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)

Tim Nieradzik
@tindzk
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
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