[jdom-interest] suggested JDOM2 improvements

[Michael Kay]

Thanks for the explanation.

I wonder, though, if discarding data of the wrong type is better than 
throwing a ClassCastException? It's very easy in XPath, for example, to 
ask for a text node when you thought you were asking for a string. 
Expressions that return nothing are the hardest thing to debug as it is.

Michael Kay
Saxonica

On 20/01/2012 14:50, Rolf Lear wrote:
> No, no static type analysis.
>
> JDOM has 'always' had the 'Filter' concept. You could, for example, do:
>
> List comments = element.getContent(new
> ContentFilter(ContentFilter.COMMENT));
>
> In order to make the above 'generic' in JDOM2, the getContent() has to
> return an appropriate type for whatever the Filter returns. I 'extended'
> the Filter class to have a generic return type. Thus, it is now possible
> to:
>
> List<Comment>  comments = element.getContent(Filters.comment());
>
> The Filter implementations all follow the rules:
> 1. if the content to be filtered does not match the filter, then the
> content is discareded.
> 2. if the content matches the filter, then it is explicitly cast to the
> generic type of the filter.
>
> What this means is that you are guaranteed that the generic type of the
> Filter results is accurate, and it is impossible to 'force' Filter results
> to have badly-loaded result lists.
>
> Filter instances can do more than just type-checking on the input data,
> but can also do anything else to filter the content, like checking for
> particular names, etc.
>
> With the XPath library, I intend to apply the same Filter concept to the
> XPath results.
>
> Since the user knows the XPath expression, they will also know the
> anticipated return type. If they want to select Elements then they can
> apply an Element filter. If they want to select 'everything' then
> they can use a 'passthough' filter which 'does no filtering' (but as a
> result can only 'cast' to Object).
>
> Essentially the Filter concept is a way to coerce unknown data in to a
> user defined type while ensuring the results will never generate
> class-cast, and providing an opportunity to discard what you do not want.
> It is ideal for XPath results.
>
> The 'user' creates their own filter
> http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/filter/Filter.html
> , or reuses one of the 'common' filters accessible in the 'Filters' class
> http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/filter/Filters.html
>
> Most Filter implementations take a Class instance (matching the generic
> type of the Filter) as a constructor argument, and any values that match
> the filter are cast using the Class.cast() method.
>
> Rolf
>
>
> On Fri, 20 Jan 2012 14:31:07 +0000, Michael Kay<mike at saxonica.com>  wrote:
>>> public XPathCompiled<Object>  compile(String xpath);
>> I started introducing generics for this in Saxon 9.4 and the experience
>> wasn't wholly positive; it left a lot of cases where there were warnings
>> that needed to be ignored. That may be because I found generics to be
>> deeper and more bewildering than I expected.
>>
>> It's not at all clear to me how your types such as
>> XPathCompiled<Element>  are supposed to work. Do they rely excessively on
>> the ability of the XPath engine to do static type analysis of the
>> supplied expression?
>>
>> Michael Kay
>> Saxonica