chris webster wrote:If you simply have a list of numbers, you could use the List's sum() method directly (min() and max() methods are also available):
The same methods should work on other collection types e.g. Arrays as well. Scala's collections offer a lot of extra functionality (more than Java) so it's worth looking through the relevant APIs before you try to re-invent the wheel. Also check out Effective Scala on collections, and 10 Scala One Liners To Impress Your Friends for a quick insight into how concise and elegant Scala code can be.
Mike Simmons wrote:What's misleading about it? And why belabor the obvious? Of course there's no reason to allocate n pieces of memory for identical copies. That's why I said it was efficient.
Seetharaman Venkatasamy wrote:
Peter Hsu wrote:Just got a rejection call from a prominent company.
I usually don't like long message. rejection at one point just one point! all is well ...
Peter Hsu wrote:
Mike Simmons wrote:To be fair, the first line does create a collection of size n. It just does it very efficiently.
Technically you are right, but I found this to be a misleading statement
It does create a "collection" which's c.size()==n but it does not allocate n piece of memories and that's what makes it efficient
Mike Simmons wrote:To be fair, the first line does create a collection of size n. It just does it very efficiently.
Chris Hurst wrote:It's got some subtle nasty's ....
The assignment of data although to an immutable doesn't help the reference for data is not published, getData could in theory return null after updateData (as an example) has been called you need a write memory barrier between the assignment of updateData and a potential read from another thread of getData. updateData should have been synchronized or data volatile etc etc Synchronzing getData and updateData is by far the simplest thing so if your having difficulty just do it, I would always recommend just synchronizing all public methods in such a class or marking the class clearly as unthread safe.
I would also do as little as possible in a constructor, its generally a bad rule of thumb to publish the this pointer from a constructor anywhere another thread can get hold of it as special memory model guarantees (e.g. finals are final) apply only after you exit a ctr. In this case I can't see anything wrong as scheduling should synchronize and give you happens before ordering at that point and you have no code after the schedule and the timer task would only call back after a second anyway lol . If your not confident synchronize your public methods and keep your ctr simple, if you later get performance issues profile and address then.