Werner Guttmann wrote:
> Werner Guttmann wrote:
>> Other than opennig a Jira issue at
>> http://jira.codehaus.org/browse/CASTOR, and ask us to provide those
>> methods, no ... ;-). As I have added the one for Writer myself a
>> few eeks ago, it should not be too hard .... but as always, patches
>> would be welcome ... ;-).
>
> Thinking a bit more about this, it's not obvious to me how the
> various set methods should be implemented. A marshaller will only
> have one mapping, for instance, but what should we expect
> mymarshaller.marshall(myobj) to do if both a Writer and a Node have
> been set?
> Werner --> One could for, for example, derive rules for this, by e.g.
> assuming that any call to such a setter would replace the existing
> sink, etc,.
Yes, that's the obvious scheme. There's still room for confusing
behaviour, though: having the instance methods pass the sink as an
argument is much more elegant and natural (IMO).
> To me, it seems the most natural solution would be to have instance
> methods which mirror the current static methods. In other words, the
> sink isn't a property of the marshaller, it's just provided when the
> mymarshaller.marshal(obj, sink) method is called.
I've tried this and you can't have static and instance methods with the
same name - there has to be a name difference if this approach is taken.
> Werner --> Yes, I agree. But before doing this, let's have a look
> whether it is possible to use the existing static methods on an
> Marshaller instance (in theory).
My understanding is that this won't be possible - the static method
blocks use of a non-static method with the same signature at compile
time. And since the static method can't refer to instance properties
(such as the mapping), it can't be used to do one thing when called as
an instance method and another as a class method.
At least, that's how I understand it - maybe there's something very
high-tech that can get round this restriction, but it would seem very
over the top for what's basically a design problem :-)
>> PS Re: static marshal() methods .. I think they have been added for
>> convenience reasons ... and somehow I wish that didn't happen
>> myself .. ;-).
>
> Yes, I can understand that! And so hard to remove once they're
> there... Werner --> And even harder so when the code generatd by the
> XM code generator makes use of those methods, too .. :-(.
Hmm, yes, that is bad. It might not be so hard to change that, though: I
find 136 explicit calls to Marshaller.marshal(...) in the core Castor code:
[EMAIL PROTECTED]:~/.../hep/castor$ find . -name "*.java" | xargs grep
"Marshaller\.marshal(" | wc -l
136
but they're distributed between only 68 files, most of which are tests.
I don't think that it's hard to rename these methods to something less
obtrusive, such as Marshaller.defaultMarshal(). Depends on whether
that's a viable option, I think: if not, then maybe a variety of
"setSink()" instance methods will suffice.
Sorry for the delay, and looking forward to opinions!
Andy
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
