New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FluentPredicate #334
Comments
Original comment posted by kevinb@google.com on 2010-02-27 at 12:48 AM We have great "fluent" versions of Predicate, Function and Iterable, and I hope we can Right now the best I have come up with is FluentPredicate, FluentFunction and |
Original comment posted by blank101 on 2010-02-27 at 05:41 AM Fluid_, perhaps - one character shorter, aye? Or perhaps Flow_. Maybe even Flo*, if |
Original comment posted by david.henderson on 2010-03-09 at 10:31 PM The term "Chainable" is used in some contexts. |
Original comment posted by blank101 on 2010-03-09 at 11:27 PM I know IDEs, auto-completion, blah-blah-blah...but "Chainable" is really long. The "Fluent" moniker seems to have some traction, and the original metaphor for that |
Original comment posted by cgdecker on 2010-03-09 at 11:55 PM "Flow" is a noun or a verb, not an adjective which can describe something. |
Original comment posted by blank101 on 2010-03-10 at 01:22 AM You mean, something more like: Function -> Composite ? I still think I consistent prefix would be preferable. The basic behavior of all these |
Original comment posted by daniel.yokomizo on 2010-03-10 at 07:58 AM This fluency support could be extended to more than predicates/functions/iterables. interface Filterable<E> { class Fluency { |
Original comment posted by blank101 on 2010-03-10 at 01:27 PM That is very similar to what I do; I do put the additional interface requirement for Also my base interfaces (the Filterable, Composable, Transformable equivalents) I What are the specifics of your Fluent map? It's not as obvious to me what's being |
Original comment posted by daniel.yokomizo on 2010-03-10 at 10:09 PM As you said I also put the additional constraints of FluentIterable returning a |
Original comment posted by finnw1 on 2010-04-23 at 01:46 PM So will you also be renaming "Ordering" to "FluentComparator"? |
Original comment posted by kevinb@google.com on 2010-04-23 at 02:52 PM That horse is out of the gate. |
Original comment posted by blank101 on 2010-04-23 at 04:35 PM Indeed; any news on when the other fluent horses will be released? |
Original comment posted by fry@google.com on 2011-01-26 at 10:46 PM (No comment entered for this change.) Status: |
Original comment posted by kevinb@google.com on 2011-07-13 at 06:18 PM (No comment entered for this change.) Status: |
Original comment posted by fry@google.com on 2011-12-10 at 03:45 PM (No comment entered for this change.) Labels: |
Original comment posted by wasserman.louis on 2012-02-16 at 06:48 PM (No comment entered for this change.) |
Original comment posted by fry@google.com on 2012-02-16 at 07:17 PM (No comment entered for this change.) Status: |
Original comment posted by em...@soldal.org on 2012-05-08 at 01:19 PM These are the slowest horses ever! |
Original comment posted by kevinb@google.com on 2012-05-30 at 07:43 PM (No comment entered for this change.) Labels: - |
Original comment posted by kevinb@google.com on 2012-06-22 at 06:16 PM (No comment entered for this change.) Status: |
Any Progress on FluentPredicates and FluentFunctions? |
I think this issue is now resolved with the introduction of the For example, com.google.common.base.Predicates.in(collection).negate().and(Objects::nonNull); Therefore I believe that this issue can and should be closed now. :) |
Original issue created by blank101 on 2010-02-26 at 11:00 PM
I find the following very annoying:
Predicates.and(Predicates.not(Predicates.in(someCollection)),Predicates.not
Null())
...etc.
I wrote a (very bare) wrapper implementation of Predicate (attached), which
provides for all the methods in Predicates in a functional style (ala the
similar proposal for Iterables), which allows some thing like:
ComposablePredicate.in(someCollection).not().and(Predicates.notNull())
which I think is more clear than the example above. I don't see this in the
dead ideas or otherwise closed issues, so I thought I'd suggest it.
The one implementation decision I'm not sure about is an immutable vs
mutable delegate, but I'm pretty happy with the immutable version.
N.B.: this composition problem also applies to functions: e.g.,
Functions.blah(Functions.blah(Functions.blah( ... ) becomes rapidly
unreadable for any substantive number of functions.
The text was updated successfully, but these errors were encountered: