Comparator and Comparators
pbenedict at apache.org
Mon Jun 24 07:56:29 PDT 2013
Brian, can you explain the "judgement and taste" is required comment? I've
been trying to find some objective criteria why someone should use static
method in interfaces over static utility classes. I haven't found any
reason except such vague comments, which are unhelpful. I do ask in earnest
what should be the driver to use this new feature over existing designs.
What criteria do you use?
On Mon, Jun 24, 2013 at 9:48 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> For this issue, Comparators will be going away soon as a public class,
> and its members sent to various places:
> - Comparator for common comparator factories
> - BinaryOperator for Comparator-to-BinaryOperator transforms
> - Map.Entry for specialized comparators on Map.Entry
> You can see this in lambda repo if you're interested.
> In general, people who want to believe "I can put static methods in
> interfaces now, so code that used to go in class Foos now belongs in
> interface Foo" will be disappointed (if they're smart).
> The set of methods that are acceptable in a "statics dumping ground"
> class Foos are not necessarily the same set as would be appropriate in
> the Foo interface. Judgment and taste is required.
> On 6/24/2013 10:36 AM, Boaz Nahum wrote:
> > Hi
> > Now we have two places to look for factory methods:
> > Comparator
> > Comparators
> > What is the rule ?
> > Stream factories are in Stream,
> > Collection factories are in Collections (nothing we can do about it)
> > Collector are in Collectors
> > function.* are in function.*
> > I know it is not big issue.
> > Thank
> > Boaz
More information about the lambda-dev