featuritis, mutability, docs, inheritance madness

[Thomas Koch <th...@koch.ro>]

Hi,

sorry for being blunt, but just for reference and opinion seeking, I wanted to 
write down my impressions after working another full day with abdera after a 
longer break.

- featuritis: I don't think the user really appreciates if a method can be 
called with a dozen different types of arguments. I'm happy to convert every 
date to a Joda DateTime, every author to a Person object or any link to an 
IRI, if the javadocs get just a bit more concise and comprehensible.

- docs: <Empty />

- mutability: After peeking a bit in guava and functional programming I just 
can't stand any setter method anymore.

- inheritance: I've already mentioned this but it caught me again today. It's 
very hard to try understanding Abdera, because there are just so many classes 
and interfaces with similar names in a big hierarchy. It's definitely not 
KISS.

Nevertheless thank you for Abdera! I still think it'll help me a lot getting 
my thesis project done in time.

Regards,

Thomas Koch, http://www.koch.ro

Re: parse/build in the same classes

[Thomas Koch <th...@koch.ro>]

After another day with abdera, it seems to me that there might be one design 
decission of Abdera that might be worth a reconsideration.

Currently, parsing and building of feeds is handled by the same classes.
In practice, I'm either a producer or a consumer of a feed. I seldom want to 
modify a feed I've parsed or parse the feed I've just built.

Even if I'd like, there could be methods to switch, like 

AbderaElementBuilder.build() : AbderaElement
AbderaElement.Builder : AbderaElementBuilder

The first method is obviously necessary to make us of a feed I've just built.

So if'd just have the time, I'd refactor Abdera and clearly seperate both use 
cases.

Thomas Koch, http://www.koch.ro