An example where this shows:
There is an optimization in 2.12. to compute the hash table index only once. If the table size changes during the defaultValue call, the index could/should be recomputed. The code could be changed from this: You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Java 9 has actually outlawed mutation of the map in an analagous method, computeIfAbsent, as their HashMap implementation in 8 has the same bug:
Regards, Jason You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Thanks. If it were clear how it should
behave when the mutation during the defaultValue call adds the
value for the same key, and if it was possible to still implement
it efficiently, I think it would be good to allow it. However, out
of my 10 usages of this method I needed the mutation in 1 case, so
I have no problem with outlawing it at all.
Regards, Jan On 02/13/2017 11:36 PM, Jason Zaugg wrote:
You received this message because you are subscribed to the Google Groups "scala-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Free forum by Nabble | Edit this page |