[ 
https://issues.apache.org/jira/browse/GROOVY-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318551#comment-17318551
 ] 

Eric Milles commented on GROOVY-10026:
--------------------------------------

All I can think of is shortening the ".stream()" call to possibly something 
like "$(employees)".  Without that first explicit step, we would need an 
extension method for each stream operation like for example 
"employees.filtered{ ... }" where "filtered" is short for ".stream().filter{ 
... }".

You can try this kind of thing out by creating a class with static methods (or 
using @Category) paired with a "use" block:
{code:groovy}
class StreamExtensions {
  static <T> Stream<T> filtered(Iterable<T> self, Predicate<? super T> 
predicate) {
    self.stream().filter(predicate)
  }
}
...
use (StreamExtensions) {
  def employeeStream = employees.filtered { ... }
}
{code}

This would let you experiment with potential extension method additions.  When 
you have settled on something, we can consider importing into the GDK so you 
can use it without "use" -- or you could take the next step for yourself by 
creating an extension module so you would get the same effect.

In terms of embedding the lazy evaluation into the existing extension methods 
like "collect" and "findAll", I don't see a path forward there.  The behavior 
of those methods is leveraged in a lot of existing Groovy code.

> Update the GDK to better support java streams and Publish/Subscribe API
> -----------------------------------------------------------------------
>
>                 Key: GROOVY-10026
>                 URL: https://issues.apache.org/jira/browse/GROOVY-10026
>             Project: Groovy
>          Issue Type: Improvement
>    Affects Versions: 4.0.0-alpha-2
>            Reporter: Dario Arena
>            Priority: Minor
>              Labels: collections, evaluation, gdk, lazy, publish, stream, 
> subscribe
>
> Groovy is one of the first JVM languages to introduce "internal iteration" 
> and in general collections operations like collect(), find(), collate().
> Maybe now that java has streams and a publish/subscribe API some of this 
> operations could be reworked and implemented using some of this features.
> The first thing to improve could be a lazy evaluation of chained collections 
> method calls, but without introducing in groovy the need to insert a 
> "terminal operation" at the end of the chain.
> Just as an example if i write something like
> {quote}def employeeSorted = employee.findAll \{ it.qualification == 'intern' 
> }.sort\{ daysBetween(it.hired, now) }
> if (monitorTop5Interns) \{
>     print employeeSorted.take(5)
> }{quote}
> When monitorTop5Interns is false there is no need to scan all the employee 
> list to find all the interns because, at least at this point in time, 
> "employeeSorted" is not evaluated. Even if it is true, because of the 
> "take(5)" as the last operation once top 5 elements are found there is no 
> need to scan the rest of the list.
> Is it possible to implement some "intermediate decorator objects" that maybe 
> extends they're correspective type (List, Set, Iterable, Collection...) that 
> are automatically coerced to an actual concrete type (a java.util.ArrayList, 
> a java.util.String...) only when they are actually evaluated (e.g. a 
> "subscription" in the publish/subscribe semantics)?.
> I know that for every collection one could call .stream() or wrap the 
> collection in a "Producer" like in RxJava but wouldn't it be groovy-er if 
> this is transparent for the users?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to