Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 02:23
    SethTisue commented #9437
  • 02:23
    SethTisue commented #9437
  • 02:15
    SethTisue commented #11759
  • 02:13
    SethTisue commented #9441
  • 02:12
    SethTisue edited #9441
  • 02:10
    SethTisue labeled #9441
  • 01:56
    SethTisue labeled #9446
  • 01:56
    scala-jenkins milestoned #9446
  • 01:56
    SethTisue opened #9446
  • 01:44
    SethTisue labeled #9445
  • 01:44
    SethTisue edited #9445
  • 01:44
    SethTisue edited #9445
  • 01:44
    scala-jenkins milestoned #9445
  • 01:44
    SethTisue opened #9445
  • 01:26
    SethTisue labeled #9444
  • 01:26
    scala-jenkins milestoned #9444
  • 01:26
    SethTisue opened #9444
  • 01:15

    SethTisue on 2.12.x

    advance expecty (compare)

  • Jan 20 23:56
    SethTisue ready_for_review #1343
  • Jan 20 23:56
    SethTisue assigned #1343
Ichoran
@Ichoran
@DCameronMauch - I generally do not use the same inner variable name as outer. It should work with shadowing, but it's confusing.
So no val x = { val a = 7; val x = 3*a; x } type stuff.
Luis Miguel Mejía Suárez
@BalmungSan
WDYM? I find easier to get the logic wrong with the ifs. Like moving the get before the is empty.
Ichoran
@Ichoran
I would move that inside the try since you actually never want either empty.
Unless for some odd reason it's important to run the toCount stuff before checking if the fromCount worked.
But I see your point. I guess it's more robust to edits with a pattern match.
(fromCount, toCount) match { case (Some(fc), Some(tc)) => ...; case _ => logger.error... } I suppose.
Luis Miguel Mejía Suárez
@BalmungSan
Yeah
I was making an scastie but it decided to delete everything.
So whatever.
Ichoran
@Ichoran
@DCameronMauch - Anyway, sometimes all the booleans and early returns actually are the easiest way to get the logic right.
Somewhat inelegant but very straightforward.
D Cameron Mauch
@DCameronMauch
Yeah, I know
It’s just that it feels wrong
Like using vars and mutable structures
Ichoran
@Ichoran
You can use vars instead of early returns :joy:
var result = false
if (bad_thing) {
  log("Bad")
}
else if (other_bad_thing) {
  log("Even worse")
}
else result = true
result
Luis Miguel Mejía Suárez
@BalmungSan
:laughing:
@DCameronMauch you are in a point where pure FP can help.
If it is worth or not is up to you.
If you are not using things like IO yet, I would not introudce them just for this.
Rob Norris
@tpolecat
Side-effecting code doesn't compose so I think it's best to write it top-down and make the execution path crystal clear.
Luis Miguel Mejía Suárez
@BalmungSan
Although, not sure if Eval would be enough to safely use things like whenA?
Raitis Veinbahs
@siers
I want to have a default method in my trait over F[_] that would return pure in some instance, which requires Applicative, which is not possible.
Should I move the responsibility of writing default code to each extending class?
D Cameron Mauch
@DCameronMauch
I really liked the Option orElse solution
Is there any way to do that while keeping intermediate values in scope?
@Ichoran that pattern also doesn’t work for the same issue of intermediate values being in scope
Luis Miguel Mejía Suárez
@BalmungSan
@siers I would say yes, especially if you want to keep your trait clean from dependencies.
Depending on what else you have on that trait, you may add a defualt constructor on the companion object.
D Cameron Mauch
@DCameronMauch
For example, if I had to computer something in the “bad_thing” block, and refer to it in the “other_bad_thing” conditional...
Luis Miguel Mejía Suárez
@BalmungSan
@DCameronMauch I really do not understand why you want to change your code?
D Cameron Mauch
@DCameronMauch
Before, it wasn’t compiling
because of the warning about using returns
Luis Miguel Mejía Suárez
@BalmungSan
Yeah because of the realy return.
You can fix that with the pattern match.
D Cameron Mauch
@DCameronMauch
no idea what changed to let it compile now
Luis Miguel Mejía Suárez
@BalmungSan
(fromCount, toCount) match {
  case (None, None) =>
    logger.error(s"error processing $from: could not validate counts")
    false

  case (Some(from), Some(to)) if (form != to) =>
    logger.error(s"error processing $from: counts do not match: ${from}, ${to}")

  case _ =>
    logger.info(s"creating _SUCCESS file for $to")
    destination.s3.putObject(bucket, to + "_SUCCESS", "")
    true
}
(I would prefix the Option values with opt)
Raitis Veinbahs
@siers
@BalmungSan Alright! How would a default constructor look like roughly?
Luis Miguel Mejía Suárez
@BalmungSan
@siers as I said, it depends on what else the trait provides for it to make sense.
Can you create a little version of your typeclass and the default method you want to add?
Raitis Veinbahs
@siers
@BalmungSan Ah, I found what I need already. My colleagues solved this in other parts of the code with an abstract class, which can be parametrized over F with type bounds.
Luis Miguel Mejía Suárez
@BalmungSan
Ah.
I thought the problem was not wanting to require an Applicative.
Luis Miguel Mejía Suárez
@BalmungSan
@mariacris431 @FunctionalUs_twitter please post job offers in (and only in) the Scala job board.
Fabio Labella
@SystemFw
this one isn't even a scala one
Ichoran
@Ichoran
@BalmungSan - See, that's exactly why I didn't want to use a match...the logic there is wrong. If either one is None then it's an error. (The same error.)
Luis Miguel Mejía Suárez
@BalmungSan
Ah I missed the or, I saw an and.
See, that is why I do not like ifs :stuck_out_tongue:
Also, my bad for trying to mimic the original code.
I would probably start with the good case and then start adding each error.
Seth Tisue
@SethTisue
@FunctionalUs_twitter use the scala/job-board for job ads, they aren't allowed in this room