« Return to Thread: [scala] Collections performance
Re: [scala] Collections performance
by Sean McDirmid
::
Rate this Message:
On Wed, Jul 30, 2008 at 5:56 PM, David MacIver <david.maciver@...> wrote:
Possibly.
Just put it out under the same license. If RMS wants to sue us, we can burn that bridge when we get to it. We aren't selling Scala or being commercial in anyway, so I don't see any liability there. We just make sure our stuff is as open as the stuff we are copying.
Of course, mutable collection libraries is where all the payoff is, while immutable collection libraries are often seen as novelties. We are very weak on mutable libraries right now in Scala, so the bias should benefit us more at first. Regardless I think they are fairly orthogonal and shouldn't share so many APIs; e.g., I don't see much use for having both mutable and immutable hash maps (mutable works well en
Definitely is. Because Seq[+A], contains in Seq has the signature contains(x : Any) : Boolean (thankfully, Set and Map are not covariant). This then propagates to ArrayList because it extends Seq, hence we have weakly typed contains methods for mutable seq's directly as a consequence of sharing APIs between mutable and immutable collections (otherwise, contains would be strongly typed).
Great. But that doesn't fill the short term need that we just need more of the basics. I'm all for the special stuff, but we have to consider the basic collections also (a mutable tree map would be a nice start).
Sean
It's certainly the cause of some umm... interesting effects on the
immutable collections. I'm not sure why it would be a slow down for
the mutable ones, except possibly overly abstracted code.
Possibly.
I'm not sure about the licensing implications of that. The source code
for the Java collections is GPLed, and that would definitely count as
a derivative work.
Just put it out under the same license. If RMS wants to sue us, we can burn that bridge when we get to it. We aren't selling Scala or being commercial in anyway, so I don't see any liability there. We just make sure our stuff is as open as the stuff we are copying.
Sure. I'm just saying: The availability is hugely biased in the
direction of mutable ones.
Of course, mutable collection libraries is where all the payoff is, while immutable collection libraries are often seen as novelties. We are very weak on mutable libraries right now in Scala, so the bias should benefit us more at first. Regardless I think they are fairly orthogonal and shouldn't share so many APIs; e.g., I don't see much use for having both mutable and immutable hash maps (mutable works well en
I'm not clear on how that's a function of immutability vs immutability.
Definitely is. Because Seq[+A], contains in Seq has the signature contains(x : Any) : Boolean (thankfully, Set and Map are not covariant). This then propagates to ArrayList because it extends Seq, hence we have weakly typed contains methods for mutable seq's directly as a consequence of sharing APIs between mutable and immutable collections (otherwise, contains would be strongly typed).
Well, I wasn't thinking of data structures along the lines of "Yet
another hash map". There's quite a rich selection of special purpose
and interesting data structures out there: Bloom filters, tries,
finger trees, a variety of heaps (including interestingly different
ones like the soft heap), plus a rich variety of purely functional
data structures a la Okasaki's book and future papers. It would be
really nice to have a "batteries included" usable collections library
containing more exotic data structures. The objective here is not to
match the Java collections library in usability, but to beat it.
Great. But that doesn't fill the short term need that we just need more of the basics. I'm all for the special stuff, but we have to consider the basic collections also (a mutable tree map would be a nice start).
Sean
« Return to Thread: [scala] Collections performance
| Free embeddable forum powered by Nabble | Forum Help |
