FluentPredicate #334
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: