XMLEncoder does have state already - encoding strategy:
mappingDescriptor or no mappingDescriptor (also it stores temporary
encoding state that makes it thread-unsafe, but this is less
important). So I am joining Rod Johnson in saying that statics and
singletons are evil - there is more than one way you may encode your
objects.
Andrus
On Dec 5, 2005, at 2:28 AM, Cris Daniluk wrote:
> Personally, I think it makes more sense to have it as a static method,
> as the XMLEncoder is not a state-bearing object.. I think having to
> construct an object implies something about its lifecycle - which in
> this case would be misleading.
>
> Using a static does make it a little more difficult to swap out the
> encoder implementation, though... maybe we could use a singleton
> pattern for the encoder? Split XMLEncoder into an interface and
> implementation.. something like this could be used to override the
> pattern:
>
> Configuration.setAlternateXMLEncoder(new MyXMLEncoder());
>
> Then...
>
> XMLEncoder.getXMLEncoder().encodeList(), etc...
>
> Of course, once you start talking about providing alternate
> implementations, you start to wonder why the word "XML" is in there :)
> So, maybe there's an Encoder interface with an XMLEncoder
> implementation. Either way, it would be a fairly quick patch and
> balances the concerns nicely I think.
>
> Cris
>
> On 12/3/05, Kevin Menard <kmenar..ervprise.com> wrote:
>> On Mon, 28 Nov 2005 06:30:26 -0500, Andrus Adamchik
>> <andru..bjectstyle.org> wrote:
>>
>>>
>>> On Nov 26, 2005, at 1:02 AM, Cris Daniluk wrote:
>>>
>>>> Is XMLEncoder.encodeList() correctly marked as deprecated? If
>>>> so, what
>>>> should be used in its place?
>>>
>>> Yes, this static method is redundant. You can use this instead:
>>>
>>> new XMLEncoder().encode(rootXmlTag, objects);
>>
>> Sorry, I've been extremely busy trying to get thesis work done.
>> Anyway,
>> time for me to chime in.
>>
>> The original static method was indeed "redundant", but it was
>> provided
>> because it was intuitively named and represented a very common
>> action.
>> John and I had worked through the API a bit and decided it really
>> was a
>> nice thing to have.
>>
>> I really would like to see it undeprecated. There are some other API
>> changes that I'm not sure really make sense either (e.g., having a
>> public
>> nodeToString() method). Or rather, they may make sense at some
>> level, but
>> I don't really find them to user-friendly. It may just be that I'm
>> attached to the original API, having come up with it, so any
>> rationale for
>> the changes would be greatly appreciated.
>>
>> --
>> Kevin
>>
>>
>
This archive was generated by hypermail 2.0.0 : Mon Dec 05 2005 - 02:11:22 EST