More interestingly, you can write:
def lengthyAsyncOp1(): Future[Int] = ...
def lengthyAsyncOp2(): Future[Int] = ...
*//this returns instantly*
val futureSum = for {
int1 <- lengthyAsyncOp1()
int2 <- lengthyAsyncOp2()
} yield {
int1 + int2
}
... keep doing other stuff ...
*//this next line blocks the thread*
val answer = Await.result(futureSum)
println("the answer was: " + answer)
That's not something that you can do with an iterator, because map and
flatMap represent a much more general concept than just some cursor over a
collection.
On 31 July 2012 17:49, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> Scala could add .map, .flatMap etc., to, say, java.util.Enumeration, via
> implicit conversions, so then you could write:
>
> for (element <- enumeration) stuff using element
>
> In Java you'll need an explicit wrapper object, i.e., noise.
>
> On Tue, Jul 31, 2012 at 1:44 PM, Dale Wijnand <dale.wijn...@gmail.com>wrote:
>
>> I fail to see how that is any different to Java's for-each depending on
>> Iterable. You've replaced depending on a type with adhering to a
>> implied method signature, or am I missing something?
>>
>> Dale
>>
>>
>> On 31 July 2012 18:39, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
>>
>>> You can implement FilterMonadic if you want, but the compiler doesn't
>>> demand that you do.
>>>
>>> It's more useful as a marker trait, and to be sure that you've
>>> implemented all the methods that you intended to implement.
>>>
>>> comprehensions are transformed to map/flatMap/etc. very early on in the
>>> compiler, and certainly don't rely on any type information.
>>>
>>>
>>>
>>> On 31 July 2012 14:45, Dale Wijnand <dale.wijn...@gmail.com> wrote:
>>>
>>>> Doesn't that mean it must
>>>> implement scala.collection.generic.FilterMonadic?
>>>> (or is it scala.collection.GenTraversableOnce..)
>>>>
>>>> Dale
>>>>
>>>> On 31 July 2012 14:46, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
>>>>
>>>>> Without lambdas, you're a bit limited here. But with them, I've found
>>>>> scala's approach to work well.
>>>>>
>>>>> for(x <- xs) { println(x) }
>>>>>
>>>>> is just syntactic sugar for
>>>>>
>>>>> xs foreach { x => println(x) }
>>>>>
>>>>>
>>>>>
>>>>> and
>>>>>
>>>>> for(x <- xs) yield { x.toUpperCase }
>>>>>
>>>>> is
>>>>>
>>>>> xs map { x => x.toUpperCase }
>>>>>
>>>>>
>>>>> *anything* with the appropriate map/flatMap/filter/foreach method(s)
>>>>> on can be used in a for-comprehension.
>>>>> (which is why scala doesn't call it a "for loop", because it really
>>>>> isn't)
>>>>>
>>>>>
>>>>> On 31 July 2012 13:31, Dale Wijnand <dale.wijn...@gmail.com> wrote:
>>>>>
>>>>>> I would say you could create delegating iterables/iterators for those
>>>>>> types. What would be an alternative would you have preferred?
>>>>>>
>>>>>> Dale
>>>>>>
>>>>>> On 31 July 2012 14:17, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
>>>>>>
>>>>>>> Yes/No. You're still forced to only use it with things that can be
>>>>>>> Iterables, yet there's a whole category of stuff where foreach makes
>>>>>>> sense,
>>>>>>> but can't be represented in this manner.
>>>>>>>
>>>>>>> One of the more obvious examples here is something like a stream of
>>>>>>> lines coming over a network socket, in which you want the body of the
>>>>>>> foreach expression to be executed asynchronously for each incoming line
>>>>>>> (perhaps by dispatching to a thread pool), and for the expression as a
>>>>>>> whole to be non-blocking.
>>>>>>>
>>>>>>>
>>>>>>> On 31 July 2012 08:15, Roland Tepp <luol...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Sorry, couldn't resist, but let your class implement Iterable and
>>>>>>>> voila - the foreach is extended!
>>>>>>>>
>>>>>>>> esmaspäev, 30. juuli 2012 15:55.30 UTC+3 kirjutas Ricky Clarkson:
>>>>>>>>
>>>>>>>>> 6. foreach is not open for extension, i.e., it only works with
>>>>>>>>> Iterables and arrays.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
