Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ichoran
    @Ichoran
    I like the xs.lengthIs < 0 thing because the name suggests the usage without having to consult an API.
    Princess | April
    @NthPortal
    I haven't figured out a way to extend that usage to other collections, sadly
    should StringOps define lengthCompare?
    Ichoran
    @Ichoran
    Meh. I don't know. I am very uneasy about the whole situation with ArrayOps and StringOps. I guess the canonical answer is "yes, it should implement everything that collections with IndexedSeqOps do"?
    Matthew de Detrich
    @mdedetrich

    @Ichoran

    (the distinction being that size is not meant to imply a consistent ordering, whereas length is).

    I didn’t know this distinction exists, I also don’t know how consistant this is. All I can say from my perspective, from a language PoV length vs size mean basically the same thing in this context and they say nothing about whether the collection is ordered or not

    I wish that this distinction would be removed since its confusing and you can tell whether or not a collection is ordered by its type (which is themore idiomatic Scala way of doing things anyways)
    nafg
    @nafg
    Is it true that the new collections design failed to significantly reduce the size of scala.js programs?
    Sébastien Doeraene
    @sjrd
    It reduced the size a bit. Not significantly. In fact, we're barely back to 2.10 size (2.11 and 2.12 had progressively increased the size).
    Princess | April
    @NthPortal
    @mdedetrich I think it's more that a Set or Map doesn't have a length; it would be weird to ask "how long is that Set?"
    Gábor Bakos
    @aborg0
    Hi,
    Was AutoCloseable considered to be extended in one/some of the collection classes? (java.util.stream.Stream extends it; IEnumerator<T> extends IDisposable.)
    Matthew de Detrich
    @mdedetrich
    @nafg Isn’t this a combination of both how less the Scala.js DCE works and also how much bytecode the new scala collection outputs?
    nafg
    @nafg
    @mdedetrich my understanding is that it's about how much code gets pulled in when you use the collections a bit, i.e
    how well things are decoupled
    My question was partially about to how much effort was put in to try to make it more decoupled
    Because it seems like a really unfortunate missed opportunity
    Ichoran
    @Ichoran
    The problem with greater decoupling is that you have lesser code reuse.
    Princess | April
    @NthPortal
    did Spandex ever make it in? and if so, what did it end up being named?
    Odd Möller
    @odd
    Hi @NthPortal, Spandex didn't make it, but its new name ArraySeq did, but it was ImmutableArray that got that name instead however. I described the current status of Spandex in the original PR #52.
    Matthew de Detrich
    @mdedetrich
    Why is this collection called a Spandex, isn’t this what women wore in the 90’s when going to the gym?
    Odd Möller
    @odd
    @mdedetrich the name Spandex was chosen to signal the expansive nature of the data structure (as opposed to the static nature of the immutable array it was developed as an alternative to), but it does not google well and with the relation to “expand” being less than obvious, the name was later changed to ArraySeq (which was then used as the name of the immutable array in 2.13).
    Princess | April
    @NthPortal
    with the new LazyList suggested by Sébastien, there's significantly less shared structure between Stream and LazyList, and I'm wondering if it makes sense for them to share an Ops trait anymore
    Harrison Houghton
    @hrhino
    It doesn't really IMO
    I ran into that while poking at that issue.
    I almost think Stream should just be a copy-paste of the 2.12 one, with whatever changes are needed to fit it into the new design.
    Princess | April
    @NthPortal
    I'm honestly thinking that as well
    Matthew de Detrich
    @mdedetrich
    Agreed, Stream is going to be deprecated anyways so too much effort shouldn’t be spent on it
    Harrison Houghton
    @hrhino
    git log shows that at one point it (LazyList) was indeed implemented as sjrd suggests, and it was changed to its current implementation later on, apparently to unify it with Stream. So there's that.
    Princess | April
    @NthPortal
    do you happen to have the commit hash for that? because that could potentially save us a LOT of work
    Harrison Houghton
    @hrhino
    pretty sure it's scala/scala@c4ef58c
    Julien Richard-Foy
    @julienrf
    IIRC we had some issues with this design, that’s why we changed it afterwards. But maybe the issue was just that the signature of the force method was not correct, it should return this.type instead of a LazyList.Evaluated[A].
    Seth Tisue
    @SethTisue

    I almost think Stream should just be a copy-paste of the 2.12 one, with whatever changes are needed to fit it into the new design.

    me three, that it’s always made me nervous that Stream was reimplemented rather than just carried over

    Princess | April
    @NthPortal
    I will look into copying over 2.12's Stream, and simplifying LazyList then (unless you want to @hrhino)
    nafg
    @nafg
    @SethTisue weren't most things reimplemented?
    Princess | April
    @NthPortal
    @nafg not really. core types like List, Vector, etc. have pretty much the same underlying implementations
    nafg
    @nafg
    meaning the way data is modeled? So what was changed with Stream?
    Princess | April
    @NthPortal
    it and LazyList share an implementation via LazyListOps
    Harrison Houghton
    @hrhino
    @NthPortal I wanted to but I'm in a bit of an OSS slouch right now and you've got far more knowledge of the 2.13 collections than I; so if you want to pick it up, feel free (please!)
    Stefan Zeiger
    @szeiger
    Stream was reimplemented from scratch. We only had the new LazyList at first and because Stream is such a special case in the old collections due to the laziness it appeared easier to modify LazyList than to port the old code. I don't remember any particular difficulties doing that, it was indeed quite easy. If you want to replace LazyList with a completely new impementation I'd factor the shared parts in LazyListOps back into Stream and use that for 2.13.
    Princess | April
    @NthPortal
    my LazyList PR is getting close (though still has a few things to iron out). For those invested in the new LazyList design, I would love some initial feedback, so I can incorporate any needed changes as soon as possible, and we can get the lazier design in quickly
    Martijn Hoekstra
    @martijnhoekstra
    If I have a scala method that has a varargs parameter, and I want to pass through java varargs from a java method, what's a way to do that that's compatible with 2.12 and 2.13?
    IOW, how do I write a java varargs forwarder to a scala varargs methods that works for 2.12 and 2.13
    Harrison Houghton
    @hrhino
    does @varargs not work for you?
    Stefan Zeiger
    @szeiger
    Not sure I understand. Are you writing the forwarder in Java? If it's in Scala then how do you end up creating a Java-varargs method without an auto-generated forwarder? If you're implementing a Java interface in Scala you use Scala varargs and the compiler generates a bridge method.
    Martijn Hoekstra
    @martijnhoekstra
    I'm attempting to write a java wrapper class that I want to wrap (among other things) a scala method with varargs
    Matthew Rooney
    @javax-swing
    @martijnhoekstra IIRC scala var args compile into scala.collection.Seq. so you can use one of the methods on scala.collection.JavaConverters to convert your java varargs into a seq
    Sébastien Doeraene
    @sjrd
    @nafg I'm on vacation until August 12. I will have a look at the LazyList PR after that.
    nafg
    @nafg
    @sjrd was that intended for someone else?
    Julien Richard-Foy
    @julienrf
    @NthPortal I guess?
    Princess | April
    @NthPortal
    I would love the feedback. unfortunately, the deadline is August 10