On 2 Jun 2004, at 22:27, Inger, Matthew wrote:
PS: This is not that big of a deal to me, as i'm using betwixt in conjunction with XMLUnit to do regression testing. The basic thrust of what i'm doing:
1. Write control object to XML file using betwixt 2. Write test object to XML using betwixt 3. Compare the control and test object XML using XMLUnit, allowing exclusions of differences based on XPath expressions
cool
So, as long as the map writing is consistent, it doesn't affect
what i'm doing, but fir betwixt, as a product, I think that issue (and the
issue
of subclasses in general) has to be addressed at some point. By subclasses
I mean:
1. properties which have an abstract type, or return a different actual class than the declared type.
+1
(for reasons i don't quite remember) this one is know as the derived beans problem.
2. Secondly, the inheritance issue, which you and i have been discussing.
Perhaps it would be possible that if any object has a different actual type
than what the property is declared a (Object is assumed for things like
Map.Entry), then a "class" attribute is added:
<HashMap> <entry> <key class="java.lang.String">6</key> <entry class="com.someone.MyBean">...</entry> </entry> </HashMap>
a relatively clean approach IMHO. If these are not addressed, i don't see
the read functionality being of much use for complex beans.
the derived bean problem is one of the reasons why the older read design (which HEAD has) needed to be replaced. (it doesn't cope very well with changes of type at runtime.)
added support for derived beans to the refactoring branch should be pretty easy (i can give good instructions) and it was one of things i would have implemented by now (were it not for the fact that other components need urgent attention). if you'd like to volunteer to give this one a shot, i'd be very grateful :)
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
