Re: object relational database versus "inteligent" serialization
lew says...
Your "item entity" example has a
constructor that calls 'super()' although the type descends directly
from 'Object' and 'super()' is called regardless.
Pitch wrote:
There's nothing wrong with that. In future someone could change the
extended class and need not worry about the constructors.
Lew wrote:
As they could without explicitly calling 'super()'. What's your point?
Pitch wrote:
They may forget to call super()
Lew wrote:
And that does no harm whatsoever. I ask again, what's your point?
Pitch wrote:
What if the new parent-class has a non-empty constructor that needs to
be called with super()?
You mean 'super( someArg )', not 'super()'. Then it would not be the scenario
I was describing. Furthermore, having the call to 'super()' before that
refactoring is not any better. Either way, you have to add the newly-required
calls to 'super( someArg )' to the extending classes. My point about the
uselessness of a call to 'super()' remains unaffected.
However, that particular scenario you describe would be irresponsible. Once a
class is released into the wild with a public API, such as the existence of a
no-arg constructor, you remove from that API at grave peril. It is a very
rude thing to destroy existing code when you refactor. Once you've committed
to an API, and that includes methods, constructors and serialization
dependencies, you have to be responsible for that commitment.
When following best practices, the scenario you describe will not arise, and
even did it, having had calls to 'super()' provides not a jot of protection.
The explicit call to 'super()' is just useless, bureaucratic anal retention.
--
Lew