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
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
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