[jdom-interest] API Inertia

[James Duncan Davidson]

On Tuesday, May 1, 2001, at 08:48 PM, James Duncan Davidson wrote:

>>   I also want to preface this with saying that it's absolutely true 
>> that
>> Jason has more or less taken over coding JDOM the last 6 months or so. 
>> I've
>> been swamped with work, and he's done the lion's share with help from 
>> folks
>> like Elliotte, Alex, Philip, et. al. However, I'm seeing some alarming
>> things.
>
> Problem with not hacking away at a project -- it sometimes grows in 
> different directions while you weren't looking. :) It's questionable 
> how worthwhile it is to come back later and say your piece as I found 
> out on the Ant mailing lists. Luckily, I don't see anybody wanting to 
> burn you at the stake here. :)
>
>> The idea that there is a
>> group of users outside this community that we can project wants and 
>> needs
>> for is, IMO, false. It's certainly true that early on we had to do 
>> that,
>> because the community was so small. But now, we've got a decent 
>> sampling.
>
> OTOH, part of writing a JSR is just that -- trying to anticipate where 
> things will be taken in the future. With all my expert groups, I had 
> adequate sampling even if the orders of magnitudes were off. However, 
> there are always going to be issue interpolating from any size of 
> community to how people will use the API. And just having more people 
> doesn't necessarily make us wiser.
>
>> Additionally, with SOAP and things like that, I
>> really am annoyed in having to get an "Object" back over the wire. I 
>> can't
>> count on it being something that I can feed to, say, XMLOutputter. How 
>> nice
>> would it be to pass a Node, or Item, or whatever, to the print() 
>> method of
>> XMLOutputter? Pretty darn sweet. Gets rid of all that serialized form 
>> crap,
>> for one thing.
>
> All serialization methods seem to play with Objects, and for good 
> reasons. cf ObjectInputStream. The common idiom seems to be:
>
> 	TypedClass obj = (TypedClass)stream.readObject();
> 	Outputter.write(obj);
>
> And you should be able to pass in any kind of JDOM object into the 
> Outputter, it just requires more methods (ala overloading). This is 
> familiar territory when dealing with objects in and out of streams.. 
> I'm not sure it requires a rewhack or some great insight.
>
> This is one of those cases where the strong typing of Java works 
> against it. In my recent re-explorations of other languages, I've been 
> fascinated by how some of them deal with this with dynamic selectors 
> and such. But that's not a topic for this list since we're dealing with 
> Java here.
>
>>   Things like detach(). This would have never made it into the 
>> original API,
>> because we looked at it and said "Oh, here's how you remove content:
>> removeContent()." Now I know we didn't see that problem, but I just 
>> don't
>> see how detach() would have made it in anyway; esp. when 2 of the 3 
>> original
>> brains (James Davidson and I) both look at that and go "That's 
>> backwards."
>> It really feels like a band-aid, not a real fix.
>
> I didn't say it was backwards. I said that I saw the elegance in what 
> Elliotte was proposing, but that given the use case an ISE made a bit 
> more immediate sense. How's that for splitting the fence? :) Quite 
> honestly, I agree with Jas that there needs to be a way to do detach 
> (or whatever) easily, and I don't have a better proposal for it.
>
>
James Duncan Davidson
duncan at x180.net
>