object relational database versus "inteligent" serialization
in [Java Programming]
|
From: Lew on 8 Feb 2010 12:11 Pitch wrote: > In article <hkpc4a$oe1$2(a)news.albasani.net>, noone(a)lewscanon.com says... >> Pitch wrote: >>> In article <hkmrjo$9lg$1(a)news.albasani.net>, lew(a)lewscanon.com says... >>>> Your "item entity" example has a >>>> constructor that calls 'super()' although the type descends directly >>>> from 'Object' and 'super()' is called regardless. >>> There's nothing wrong with that. In future someone could change the >>> extended class and need not worry about the constructors. >> As they could without explicitly calling 'super()'. What's your point? > > They may forget to call super() And that does no harm whatsoever. I ask again, what's your point? -- Lew
From: Pitch on 8 Feb 2010 12:26 In article <hkpgj9$hs$1(a)news.albasani.net>, noone(a)lewscanon.com says... > > Pitch wrote: > > In article <hkpc4a$oe1$2(a)news.albasani.net>, noone(a)lewscanon.com says... > >> Pitch wrote: > >>> In article <hkmrjo$9lg$1(a)news.albasani.net>, lew(a)lewscanon.com says... > >>>> Your "item entity" example has a > >>>> constructor that calls 'super()' although the type descends directly > >>>> from 'Object' and 'super()' is called regardless. > >>> There's nothing wrong with that. In future someone could change the > >>> extended class and need not worry about the constructors. > >> As they could without explicitly calling 'super()'. What's your point? > > > > They may forget to call super() > > And that does no harm whatsoever. I ask again, what's your point? What if the new parent-class has a non-empty constructor that needs to be called with super()? -- stirr your cofee properly
From: Lew on 8 Feb 2010 12:46 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
From: Tom Anderson on 8 Feb 2010 12:58 On Mon, 8 Feb 2010, Pitch wrote: > In article <hkmrjo$9lg$1(a)news.albasani.net>, lew(a)lewscanon.com says... > >> Your "item entity" example has a constructor that calls 'super()' >> although the type descends directly from 'Object' and 'super()' is >> called regardless. > > There's nothing wrong with that. In future someone could change the > extended class and need not worry about the constructors. That's also the case without the explicit constructor call. Just to be completely clear, this code: class Foo { public Foo() { } } And this: class Foo { public Foo() { super(); } } Do *exactly* the same thing, and compile to *exactly* the same bytecode. Adding the explicit super() adds nothing. tom -- secular utopianism is based on a belief in an unstoppable human ability to make a better world -- Rt Rev Tom Wright
From: Tom Anderson on 8 Feb 2010 13:54
On Mon, 8 Feb 2010, Pitch wrote: > In article <hkpgj9$hs$1(a)news.albasani.net>, noone(a)lewscanon.com says... >> >> Pitch wrote: >>> In article <hkpc4a$oe1$2(a)news.albasani.net>, noone(a)lewscanon.com says... >>>> Pitch wrote: >>>>> In article <hkmrjo$9lg$1(a)news.albasani.net>, lew(a)lewscanon.com says... >>>>>> Your "item entity" example has a >>>>>> constructor that calls 'super()' although the type descends directly >>>>>> from 'Object' and 'super()' is called regardless. >>>>> There's nothing wrong with that. In future someone could change the >>>>> extended class and need not worry about the constructors. >>>> As they could without explicitly calling 'super()'. What's your point? >>> >>> They may forget to call super() >> >> And that does no harm whatsoever. I ask again, what's your point? > > What if the new parent-class has a non-empty constructor that needs to > be called with super()? You've misunderstood. Go back and read what the JLS has to say about superclass constructor invocation. tom -- everything is temporary |