Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Odd Möller
    @odd
    @julienrf Thanks. Wouldn't that buffer the entire iterable-once during the iteration though?
    reduceLeft((_, e) => e) is an alternative I guess.
    Julien Richard-Foy
    @julienrf
    BufferedIterator has a buffer of size 1 only
    True, reduce and fold also work
    Odd Möller
    @odd
    @julienrf I see. Perhaps BufferedIterator could be extended to support specifying a longer buffer length and then it could implement the right-oriented operations by using that buffer (would only work for terminating ones and only up to the buffer length naturally)?
    Julien Richard-Foy
    @julienrf
    You can submit the idea… My opinion is that the current behavior of BufferedIterator is fine.
    Odd Möller
    @odd
    appending to todo-list (which took a while since it is quite long, should have used a todo-queue instead...)
    Ichoran
    @Ichoran
    I also think BufferedIterator is fine as-is.
    Harrison Houghton
    @hrhino
    So why are there both concat and appendedAll?
    In List for instance, Seq wants concat to mean appendedAll, but there's a StrictOptimizedIterableOps#concat that gets mixed in later..
    Julien Richard-Foy
    @julienrf
    concat comes from Iterable, whose elements have no order, whereas appendedAll comes from Seq and ensures that the elements are concatenated at the end of the lhs collection.
    Harrison Houghton
    @hrhino
    Hmm. So I'll check again, but I think List's concat isn't its appendedAll after all (it gets it from StrictOptimizedIterableOps).
    (also, I think I'd assume that "concatenate" implies an order, but the paint's dry on that shed, I'm sure)
    Odd Möller
    @odd
    @hrhino see scala/bug#11128 and scala/scala#7166
    The PR (scala/scala#7166) does not pass yet though. Will have time to look into why during the weekend hopefully.
    Odd Möller
    @odd
    @hrhino Also, an additional reason to have appendedAll on Seq in addition to concat is for symmetry with prependedAll (like we have for appended/prepended).
    nafg
    @nafg
    Wouldn't unordered combine be union?
    Ichoran
    @Ichoran
    It's only union on sets.
    nafg
    @nafg
    So there are three names then
    Ichoran
    @Ichoran
    Don't forget ++ and |
    nafg
    @nafg
    Concat is redundant with one operation on Seq and another on Set
    Ichoran
    @Ichoran
    Yes
    nafg
    @nafg
    True but having operators and alphanumeric methods is a common convention
    There was even a proposal to make it explicit
    Oh well. So inelegant. :) I assume the docs cross reference?
    Oron Port
    @soronpo
    Trying to migrate to 2.13... What happened to SortedSetLike? I see no mention of it in https://github.com/scala/collection-strawman/wiki/FAQ#how-do-i-cross-build-my-project-against-scala-212-and-scala-213
    Josh
    @joshlemer
    SortedSetOps maybe?
    Sorry on mobile
    Oron Port
    @soronpo
    Yes, you are right. It turns out the documentation does mention this, but in a general fashion for these Like traits, so when I searched for it I could not find it.
    Thanks
    Nth/April
    @NthPortal
    I noticed that maps do not have a method to derive a new value from an old one - I encountered this at work today, and I think it's a major shortcoming that I needed to go to Java to get that functionality. A method like that is particularly crucial for concurrent maps, where you can't rely on the result of a previous call to get
    Ichoran
    @Ichoran
    @NthPortal - You mean something like updateWith[U >: V](key: K, f: V => U): Map[K, U]?
    Or just updateInPlaceWith(key: K, f: V => V): this.type?
    Nth/April
    @NthPortal
    the latter is the one I care more about, but both seem like a decent idea
    however, you either need f: Option[V] => V or ifPresent: V => V, ifAbsent: => V
    Java handles it (in compute) by using null if it's absent, but that seems like not a great idea in Scala (arguably not a great idea in Java either)
    Josh
    @joshlemer
    @NthPortal seems pretty useful, open a ticket!
    megri
    @megri
    Hey
    I'm curious if the new collections can handle folds with terminations. Currently a fold is always terminal, without early exit clause.
    I can't seem to express myself today. What I mean is, currently something like List(1,2,3,4,5).toIterator.foldLeft(0)(_ + _).takeWhile(_ < 4) ends up with foldLeft working over all elements rather than only the first three.
    Julien Richard-Foy
    @julienrf
    We have such a thing in scala-collection-contrib: https://github.com/scala/scala-collection-contrib/blob/master/src/main/scala/scala/collection/decorators/IterableDecorator.scala#L7-L18
    megri
    @megri
    @julienrf Thanks, it's not exactly what I was looking for but it will work for most cases.
    Nth/April
    @NthPortal
    you can also do .scanLeft(0)(_ + _).takeWhile(_ < 4).last
    Nth/April
    @NthPortal
    do the new collections have a zipMap operation? (equivalent to .map(x => x -> f(x)))
    Seth Tisue
    @SethTisue
    I don't think so. but also, perhaps it's time to shut down this room and consolidate on scala/contributors?
    Nth/April
    @NthPortal
    probably
    Seth Tisue
    @SethTisue

    THIS ROOM IS NOW CLOSED

    see you in scala/contributors 👋