filtering projections about reboot HOT 6 CLOSED

👍

You would have the same problem with an Either in a for-comprehension (see this question on SO)

What you would need is return a Promise[Either[X,B]] to make it possible to use and in case the predicate is not respected, return a Left(??). However, in the general case you have no clue how to build the Left element.

This was made possible in scala 2.10 with scala.util.Try because we know how to build the failure case (see here).

It would be really useful for one of my projects to be able to filter on the result :-)

from reboot.

As long as dispatch supports versions prior to 2.10, we probably won't be rolling in language features specific to 2.10 but I may be wrong ( @n8han ?) I think there was some work being done to work in scala 2.10 futures/promises or at least to an attempt to make dispatches language for the 2 in-line with the ones scala recently introduced. Note on that, @n8han's work on reboot predated those. Scala's either projects define a filter so I started a branch to do the same in dispatch. This is where I left off. I haven't had time to follow up on it but I'll have a look at your link above.

from reboot.

The futures API was backported for 2.9.3 so i believe it would include Try.

from reboot.

@n8han That's right, Try exists in 2.9.3

@softprops I know filter method exists for Either projections, and my link is about it. It does not work in for-comprehensions either and cannot work this way. You would have to use the trick of going to an option and then calling toRight on it (in the answers on my SO link).

from reboot.

My impression from reading this issue is that this isn't something that's still a problem given that we dropped support for older Scala versions, but I could be wrong about that. I'll leave it unlabeled for now as a signal to myself to investigate further. If someone could validate my understanding I could just close this issue.

from reboot.

Just confirmed this is still an issue as written, but that seems to be because of the conflation of Future and Either, which I'm not sure should be supported in any event. FWIW, Scala 2.12 introduced toTry on Either that allows something like this:

@ for { result <- Http(req > as.lift.Json).either } yield {
    for ( JObject(fs) <- result.toTry ) yield fs
  }
res8: Future[scala.util.Try[List[JField]]] = Future(<not completed>)
@ res8.value
res9: Option[scala.util.Try[scala.util.Try[List[JField]]]] = Some(
  Success(
    Success(
      List(
        JField("details", JString("API requests must be key-signed, oauth-signed, or accompanied by a key: https://www.meetup.com/meetup_api/docs/#authentication")),
        JField("code", JString("not_authorized")),
        JField("problem", JString("You are not authorized to make that request"))
      )
    )
  )
)

To that end, since we no longer support < 2.11, we should probably expose a helper to provide a Try instead of an Either if that's what folks want in their code.

I'm going to close this issue and open a new ticket for Try support from the execution system. Let me know if there are any concerns with this resolution.

from reboot.