Community
Participate
Working Groups
IterateExpression currently fails if the default variable is not a Collection. It would be very useful if instead of failing it would attempt to adapt the variable to a Collection. This would allow us to iterate over selections and any number of other useful containers. Patch forthcoming.
This also applies to CountExpression.
Created attachment 60848 [details] Patch against core.expressions and core.expressions.tests Adds the adaptation feature to Iterator and Count via an embedded AdaptExpression element.
Created attachment 60850 [details] Patch against workbench Patch that adds the adapter factory to workbench as well as a test case.
This is also important to get in for M6 PW
Hi Kim, I looked at the patch and I have to say that I am not very happy with the fact that we start adapting certain types to collection in our system to make them consumable by the expression language. A clearer approach would be: - we introduce a new interface IIterable in core expression which defines the necessary interface and the expression language uses that interface to adapt to. However this is an API change and needs PMC approval. The approach would be more along the lines of Java 5. Kim, a general question. Why doesn't your code pass in a collection into the evaluation context instead of the selection. This would result in the same result.
Created attachment 61273 [details] A patch that adapts to Collection
(In reply to comment #5) > Kim, a general question. Why doesn't your code pass in a collection into the > evaluation context instead of the selection. This would result in the same > result. Our evaluation context turns "selection" into a Collection when it places it in the default variable but selection, activeMenuSelection, and activeMenuEditorInput are all ISelections in the evaluation context that are also available. The user also needs to be able to deal with the ISelection from the 3 variables, hopefully in a reusable way. PW
Created attachment 61276 [details] A patch that introduces new iterfaces to adapt to.
The interface are: /** * Objects that are adaptable to <code>IIterable</code> can be used * as the default variable in an iterate expression. * * @see IAdaptable * @see IAdapterManager * * @since 3.3 */ public interface IIterable { /** * Returns an iterator to iterate over the elements. * * @return an iterator */ public Iterator iterator(); } and /** * Objects that are adaptable to <code>ICountable</code> can be used * as the default variable in a count expression. * * @see IAdaptable * @see IAdapterManager * * @since 3.3 */ public interface ICountable { /** * Returns the number of elements. * * @return the number of elements */ public int count(); } Personally I prefer the version with the two new interfaces. Kim, Paul, John what are your thoughts about this ?
Dirk's suggestion looks good to me. Having specific interfaces for this is much clearer, and avoids having to produce an entire Collection implementation just to obtain either a count or an iterator. It's unfortunate to be duplicating the Iterable interace added in Java 5, but core expressions may not be moving to Java 5 for a long time (if ever).
I'm fine with adapting to the 2 new interfaces if we can get PMC approval to add them. PW
+1
Fixed as outlines in comment #8 and #9.
