Re: [Hibernate-devel] Design question

[Daniel B. <db...@bi...>]

>
>
>I think its worth deprecating Persistent. What I initially took to be a ....
>
>The original reason for its existence was that it actually declared two ...
>If we ditch it we are going to have a codebase with an awful lot of methods
> that take Object.
>
Hmmmm why does that make me feel uncomfortable. Was that you in 
theserverside.com not long ago telling someone how easy it is to 
implement serializable?

>
> On the negative side, it is an extra unnecessary intrusion upon the model
> so all things considered it was probably a bad idea. A couple of people
> already commented negatively about it.
>
It doesn't force you to actually implement anything AND thanks to being 
able to implement multiple interfaces, it doesn't get in the road of any 
business model.

>>I've just migrated a utility to help produce the mapping spec (that I
>>originally wrote for a different open source OR tool ;). It takes info
>>
>>from JavaDoc tags embedded in the source, and spits out a fair attempt
>
>>at a mapping spec. I've written it as a Doclet, and it runs under JavaDoc.
>>If anyone else might find this useful I'd be happy to plonk it somewhere
>>public.
>>
Sounds great Paul! I've always wanted to play with Doclets and I've 
never actually seen anything useful done with them. I was thinking this 
was a good way to keep information about the classes together, but then 
I am thinking that this seperation is part of what Hibernate is about. 
Seperating your clean/pure OO business model from the OO dirty 
relational model ;)

Either way. Great thing to be able to add to a feature list. Allowing 
ppl to configure via handed coded XML, plain GUI, IDE plugins AND from 
source parsing. Can anyone complain?

Daniel