3 ms·

> getting a value out of a map automatically creates another new object Do you have a code sample for this?

kasey_junk 13y ago
From MapLike.scala def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value } From HashMap.scala def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }
- azth 13y ago
  Out of curiosity, how would you rather have them be implemented? You either return an Option, or you will have to deal with null pointers.
  - kasey_junk 13y ago
    Not sure how familiar you are with the Scala syntax, but that code actually has null pointer problems. The apply function turns Options into null pointers. They've given me the worst of both worlds, not only do I get null pointers, I get to have extra garbage created to accomplish it.
    - azth 13y ago
      Yep I get that point. However, how would you avoid extra allocations and maintain safety (no nulls)?
      - kasey_junk 13y ago
        I actually have no problem with the extra allocations if they maintain safety (that's not quite true, I actually need to break safety occasionally). The problem is that the incoherent design of the collections library means that it is not clear to the programmers of the default mutable hash map lookup what they are striving for. If they were striving for performance they would use a model that allowed for NPE against safety, that had allocation semantics that were sensible. Conversely, if safety was the overriding concern they wouldn't allow for the NPE. Instead, in one of the most central data structures of the language we get unreasonable behavior. This is clearly a sign of bad design, thus reputing the original assertion that the Scala collections library were a good example of type programming. PS: To trivially answer your question, they should have inverted the implementation here. A NPE throwing method for lookup wrapped with option sugar would make way more sense than the inverse.
        azth 13y ago
        Makes sense, thanks for your answer :)

From MapLike.scala def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value } From HashMap.scala def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }

azth 13y ago
Out of curiosity, how would you rather have them be implemented? You either return an Option, or you will have to deal with null pointers.
- kasey_junk 13y ago
  Not sure how familiar you are with the Scala syntax, but that code actually has null pointer problems. The apply function turns Options into null pointers. They've given me the worst of both worlds, not only do I get null pointers, I get to have extra garbage created to accomplish it.
  - azth 13y ago
    Yep I get that point. However, how would you avoid extra allocations and maintain safety (no nulls)?
    - kasey_junk 13y ago
      I actually have no problem with the extra allocations if they maintain safety (that's not quite true, I actually need to break safety occasionally). The problem is that the incoherent design of the collections library means that it is not clear to the programmers of the default mutable hash map lookup what they are striving for. If they were striving for performance they would use a model that allowed for NPE against safety, that had allocation semantics that were sensible. Conversely, if safety was the overriding concern they wouldn't allow for the NPE. Instead, in one of the most central data structures of the language we get unreasonable behavior. This is clearly a sign of bad design, thus reputing the original assertion that the Scala collections library were a good example of type programming. PS: To trivially answer your question, they should have inverted the implementation here. A NPE throwing method for lookup wrapped with option sugar would make way more sense than the inverse.
      - azth 13y ago
        Makes sense, thanks for your answer :)