As of the latest build I've began a slight rework of how filters can be utilized. They can still be utilized the same way they always have, however I'm trying to expand them and make them easier to use in certain situations. In previous releases, Filter has been an interface. As of the next build it will be an abstract class. For the most part this won't break anything, however it will allow me to add utility methods into the class such as List<T> getAccepted(Collection<T>), T getFirstAccepted(Collection<T>), and T getRandomAccepted(Collection<T>). These utility methods will make it easier to use filters when you have to apply them to a collection, such as when a method that returns a Collection doesn't accept a filter as an argument. Example: https://gist.github.com/anonymous/e4f311903f9376b3163d So far everything I've mentioned have been no-brainer decisions. The following is where I'd like some feedback. Currently most methods in the API accept a single filter because it makes them for more manageable, and to compliment these methods I've provided a class in the API (Filters) that allows multiple filters to be merged into one. It's recently come to my attention that many of our developers haven't been using this class at all, possibly because they didn't know it existed (I'm looking at everyone who didn't have a script bot break in the last release >.>). To raise awareness of this issue, I was considering adding a Filter#and(Filter) and a Filter#or(Filter) that would be more visible to anyone using filters. In my opinion this would be the best way. The alternative is creating a "FilterGroup" class that would be an extension of the Filter class with a constructor accepting a variety of filters (but I'm not really a fan of this method). FilterGroup's could be dropped in any place that a Filter is requested, and it would be a rather seemless migration. My biggest question is this: what the hell do I have to change in the API to make you fuckers use Filter's properly xD #RaisingAwareness
I don't see anything wrong with the way it is now. If people aren't seeing the Filters class it's because they aren't looking in the jdocs when they should be.
