commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [LANG] Suggestions For New Features
Date Tue, 11 Aug 2009 06:09:59 GMT
On Sun, Aug 9, 2009 at 1:37 PM, Michael Wooten<mwooten.dev@gmail.com> wrote:
> These are several additions that I feel might be useful to the Commons Lang
> Project. Please feel free to provide feedback, and if there is enough
> interest in any of them I will create JIRA entries, code them, and provide
> patches.
>
> Expand Validate to include more specific, human readable validation for
> commonly validated paramter values (so isTrue() isn't needed as often).
> Include new Validate methods:
>
>   - isFile(File file)

All the File ones are better placed in Commons IO.

>   - matchesPattern(String string, String pattern)
>      - throws an IllegalArgumentException stating ("The string " + string +
>      " does not match the pattern "  + pattern) when the provided
> string does not
>      match the regular expression pattern.
>      - matchesPattern(String string, String pattern, String message)
>      - throws an IllegalArgumentException stating (message + string) when
>      the provided string does not match the regular expression pattern.
>   - matchesPattern(String string, Pattern pattern)
>      - throws an IllegalArgumentException stating ("The string " + string +
>      " does not match the pattern "  + pattern) when the provided
> string does not
>      match the regular expression pattern.
>   - matchesPattern(String string, Pattern pattern, String message)
>      - throws an IllegalArgumentException stating (message + string) when
>      the provided string does not match the regular expression pattern.

+1

>   - inRange(Comparable<T> start, Comparable<T> end, Comparable<T>
value)
>      - throws an IllegalArgumentException stating ("The value " + value + "
>      is not in the specified range of " + start + " to " + end) when
> the provided
>      value does not fall between the two comparable values.
>      - inRange(Comparable<T> start, Comparable<T> end, Comparable<T>
value,
>   String message)
>      - throws an IllegalArgumentException stating (message + value) when
>      the provided value does not fall between the two comparable values.
>   - sizeInRange(int minSize, int maxSize, T[] array, String message)
>      - throws an IllegalArgumentException stating (message + value) when
>      the length of the provided array does not fall between the minimum and
>      maximum size values (inclusive).
>   - sizeInRange(int minSize, int maxSize, Collection<?> collection, String
>   message)
>      - throws an IllegalArgumentException stating (message + value) when
>      the length of the provided collection does not fall between the
> minimum and
>      maximum size values (inclusive).
>   - sizeInRange(int minSize, int maxSize, Map<?, ?> map, String message)
>      - throws an IllegalArgumentException stating (message + value) when
>      the length of the provided map does not fall between the minimum
> and maximum
>      size values (inclusive).
>   - sizeInRange(int minSize, int maxSize, String string, String message)
>      - throws an IllegalArgumentException stating (message + value) when
>      the length of the provided string does not fall between the minimum and
>      maximum size values (inclusive).

I like 'between' more than 'inRange'.

I think a simpler API would be (ignoring the String message overloads):

between(Comparable<T> start, Comparable<T> end, Comparable<T> value)
between(int minSize, int maxSize, int value)

ie) leave the determination of the int to the developer.

> I would also like to propose some support be added to Lang for basic event
> handling. This would be based on the way that PropertyChangeSupport can be
> used to add and remove listeners and post events.
>
> Add interface EventSupport<L extends EventListener>
>
>   - addListener(L listener)
>   - The signature for the method that can add a listener of some subtype of
>      EventListener
>      - removeListener(L listener)
>   - The signature for the method that can remove a listener of some subtype
>      of EventListener
>
>
> Add class AbstractEventSupport implements EventSupport<L>, Iterable<L>
>
>   - AbstractEventSupport(Object eventSource)
>   - Constructs a new AbstractEventSupport object and associates it with the
>      object that will be used as the source of all events (much like
>      PropertyChangeSupport).
>      - addListener(L)
>   - An implementation that adds a listener to an internal collection.
>      - removeListener(L)
>   - An implementation that removes a listener from an internal collection.
>      - iterator()
>   - Returns an iterator over the attached listeners.
>      - getSource()
>   - Returns a reference to the source object of all events.
>
>
> The best way to describe this would be to demonstrate an example of how it
> can be used.
>
> public class ButtonPressedEventSupport extends
> AbstractEventSupport<ButtonPressedListener> {
>
>    public ButtonPressedEventSupport(Object source) { super(source); }
>
>    public void fireButtonPressed(Button button) {
>        ButtonPressedEvent bpe = new ButtonPressedEvent(getSource(),
> button);
>        for (ButtonPressedListener listener : this)
>        {
>            listener.buttonPressed(bpe);
>        }
>    }
> }
>
> public class MyWindow implements EventSupport<ButtonPressedListener> {
>     private final ButtonPressedEventSupport buttonPressedEventSupport;
>
>     public MyWindow { buttonPressedEventSupport = new
> ButtonPressedEventSupport(this); }
>
>     public void addListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.addListener(listener); }
>
>     public void removeListener(ButtonPressedListener listener) {
> buttonPressedEventSupport.removeListener(listener); }
>
>     ...
>
>    private void onDetectButtonPressed(Button button) {
>        buttonPressedEventSupport.fireButtonPressed(button);
>    }
> }
>
> I haven't compiled the above code. It's just an example of how these classes
> could be used so that you're not constantly rewriting the code and
> interfaces for adding and removing listeners, and it provides a fairly easy
> method of creating methods to fire events.

Worth a JIRA to solicit more feedback :) Seems good, in the 'this
doesn't exist?' way :)

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message