Predicates, Functions and Closures

[Ad]

Assuming Java7 gets some kind of closure, how will they play with the
Google Collection's functional-esque api? In particular, will they
replace predicates and functions?

E.g.

instead of...

Iterables.filter( foos, new Predicate<Foo>...

we could do...

Iterables.filter( foos, #( Foo f )( f.isBar() ) )

If we have 'method pointers', then can we get something even
cleaner...

Iterables.filter( foos, Foo.isBar )

[Pat Farrell]

On Mon, Dec 21, 2009 at 3:08 PM, Ad <ada...@gmail.com> wrote:

Assuming Java7 gets some kind of closure,

Isn't that a big assumption? I know that there are folks asking for them, but given what a mess Generics were in 1.5, I'm not looking forward to them in Java. Perhaps in some new language.

To your question, Google Collections will stop with 1.0 whenever its released. Whatever work is done will be done not to Google Collections, but to whatever guava or follow-on package there is.

I don't know about you folks, but after 12 years of working with Java, I think its getting pretty long in the tooth. Rather than hacking it in an attempt to preserve backwards compatibility, I'd rather see a new language on the JVM, one that does multi-core support without requiring a PhD from Stanford or MIT to use.

[Vladimír Oraný]

Have you tried Groovy? It's quite easy to learn and provide quite same functionality as Google Collection or Guava. Besides Groovy there are a lot of other JVM languages (Scala, Jython etc. - http://en.wikipedia.org/wiki/List_of_JVM_languages). Maybe you can find there the one you desired.

2009/12/21 Pat Farrell <pat2...@gmail.com>

--
Google Collections Library - users list
http://groups.google.com/group/google-collections-dev?hl=en
 
To unsubscribe, send email to:
google-collections...@googlegroups.com

[Ad]

Yes it's a big assumption, but I'm still interested in what collection
manipulation will look like if it comes to be.

[Gary Pampara]

Closures will be added in JDK7. The announcement came in at Devoxx
this year [1][2].

As a result, JDK7 will have it's release delayed a bit. To that end, I
wouldn't split hairs about the usage of closures in place of
Predicates / Functions for the moment. I would, however, assume that
the changes required to go to closures wouldn't be a difficult thing
to do.

You can keep an eye on the "straw-man" proposal [3] in the OpenJDK
project (I'm not sure if this is the official project name yet)

[1] http://blogs.sun.com/mr/entry/closures_qa
[2] http://blogs.sun.com/mr/entry/closures
[3] http://cr.openjdk.java.net/~mr/lambda/straw-man/

Regards.

[Pat Farrell]

On Tue, Dec 22, 2009 at 12:02 AM, Gary Pampara <gpam...@gmail.com> wrote:

Closures will be added in JDK7. The announcement came in at Devoxx
this year [1][2].

From the first link:

 "The schedule was pushed out, to at least September 2010"

it then goes into detail on what happens between now and then and what "at least" means in this context.

So I still don't care, its too far into the future to worry about. YMMV

[Kevin Bourrillion]

It is possible that the closures feature will have a provision for
automatically treating a closure as a SAM (single-abstract-method)
type based on context, in which case you could pass one to any method
expecting a Predicate or Function.

I intend to raise the subject on the open JDK mailing lists of which
of our filter/transform-type methods ought to be in the JDK if the JDK
gets closures.

> --
> Google Collections Library - users list
> http://groups.google.com/group/google-collections-dev?hl=en
>
> To unsubscribe, send email to:
> google-collections...@googlegroups.com
>

--
Kevin Bourrillion @ Google
internal: http://go/javalibraries
external: guava-libraries.googlecode.com

[Pat Farrell]

I intend to raise the subject on the open JDK mailing lists of which
of our filter/transform-type methods ought to be in the JDK if the JDK
gets closures.

That would be so cool. I'd love it.