Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Matthew de Detrich
    @mdedetrich
    @Ichoran I thought that was the general purpose of the collections redesign though, make everything lazy and overwrite for strict collections
    i.e. make the default correct but slow
    Ichoran
    @Ichoran
    Yeah, more or less. LazyList just sits in a weird place in the hierarchy, surrounded by eager collections.
    Matthew de Detrich
    @mdedetrich
    Lazy people never make good friends with strict people….
    Ichoran
    @Ichoran
    Anyway, that wasn't one of the primary goals, but it was a secondary goal.
    Matthew de Detrich
    @mdedetrich
    I think there were a lot of primary goals, and this is one of them
    Ichoran
    @Ichoran
    That's not what I remember; I think that having fully-functional views was a primary goal, though, and it's pretty hard to have that if the hierarchy is strict at the top.
    Princess | April
    @NthPortal
    someone brought up on the lengthCompare ticket that besides having nicer syntax for that, it would be nice to have a method to compare Seq lengths, something like def lengthCompare(that: Seq[_]): Int
    is it too late in the release cycle to add that?
    Ichoran
    @Ichoran
    I would call that compareSize and put it on Iterable.
    Princess | April
    @NthPortal
    :+1:
    Ichoran
    @Ichoran
    There's nothing Seq-specific about that method.
    Princess | April
    @NthPortal
    to be fair, there's nothing Seq specific about lengthCompare(Int):Int either
    Ichoran
    @Ichoran
    Except that "length" is a Seq thing (the distinction being that size is not meant to imply a consistent ordering, whereas length is).
    Princess | April
    @NthPortal
    fair
    but it could just as well be sizeCompare
    Ichoran
    @Ichoran
    Yup.
    Princess | April
    @NthPortal
    arguably, it would be better to have it for Iterable
    Ichoran
    @Ichoran
    I'm happy with it either way. Usually for lengthCompare I'd be thinking about taking the same amount of stuff again.
    Whereas compareSize(xs) I'd likely use in other ways.
    But I can see it going either way. @julienrf and/or @szeiger -- what do you think?
    Princess | April
    @NthPortal
    do you have a preference for compareSize(Iterable) over sizeCompare(Iterable), btw? just thinking about consistency
    Ichoran
    @Ichoran
    I think sizeCompare is grammatically awkward in English. compareSize is better, but doesn't tell me anything about whether the argument is a size or a thing that has a size. Maybe compareSizeTo?
    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.