[jdom-interest] suggested JDOM2 improvements
mike at saxonica.com
Fri Jan 20 06:57:02 PST 2012
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.
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
> 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
> 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
> , or reuses one of the 'common' filters accessible in the 'Filters' class
> 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.
> 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
More information about the jdom-interest