API Review: additional methods for StringExpression

[Michael Heinrichs]

Hi Sergey,

thanks for your input. I'd rather keep isNotEmpty() for the following reasons:

1) Consistency. We already have a whole range of methods, that just negate the outcome of another method, e.g. isNotNull(), notEqual(), even lessThanOrEqual() etc.
2) Readability. Consider for example the two expressions below. The first one can easily be misunderstood, especially if you are new to the binding API. The second one is clear IMO.
	isEmpty(list1).not().and(isEmpty(list2))
	isNotEmpty(list1).and(isEmpty(list2).
3) Performance. Internally the isNotEmpty() method requires only half of the objects and less method calls when invalidating/calculating the binding.

Cheers,
Michael



On 19.09.2012, at 13:22, Sergey Grinev wrote:

> Hi, Michael.
> 
> What do you think about removing isNotEmpty() methods given there is BooleanBinding#not() method?
> 
> -- Sergey
> 
> On 17-Sep-12 15:25, Michael Heinrichs wrote:
>> Hi,
>> 
>> I propose six new methods in the high level binding API, adding new functionality for ObservableStringValue's. JIRA issue: http://javafx-jira.kenai.com/browse/RT-21487
>> 
>> In StringExpression:
>> public IntegerBinding length();
>> public BooleanBinding isEmpty();
>> public BooleanBinding isNotEmpty();
>> 
>> In Bindings:
>> public static IntegerBinding length(ObservableStringValue);
>> public static BooleanBinding isEmpty(ObservableStringValue);
>> public static BooleanBinding isNotEmpty(ObservableStringValue);
>> 
>> As usual in the binding API, null is treated similar to an empty String, i.e. length() will return 0, isEmpty() will return true, if the value of an ObservableStringValue is null.
>> 
>> 
>> 
>> For consistency I would also like to add isNotEmpty() methods for collections in the Bindings class:
>> public static <E> BooleanBinding isNotEmpty(ObservableList<E> op);
>> public static <K, V> BooleanBinding isNotEmpty(ObservableMap<K, V> op);
>> public static <E> BooleanBinding isNotEmpty(ObservableSet<E> op);
>> 
>> Thanks,
>> Michael
>