object relational database versus "inteligent" serialization
in [Java Programming]
|
From: Eric Sosman on 9 Feb 2010 18:20 On 2/9/2010 3:13 PM, Pitch wrote: > In article<hks15c$7lg$1(a)news.albasani.net>, noone(a)lewscanon.com says... >> >> Pitch wrote: >>> I didn't know parent default contructor is automatically called in >>> child's constructor (if no other parent contructor is called). >> >> It would have to be - you cannot construct an object unless all its superclass >> aspects are constructed, in Java's case before subclass aspects. >> >>> So you cannot override parent's default contructor - which sucks. >> >> Why does it suck? >> >> You cannot override any constructor, not default, not explicit no-arg, not >> with args. >> >>> Also, you cannot place any code before super(...) which I already new, >>> and it also sucks. :) >> >> Again, why does that suck? >> >>> Anyone knows why is that so? >> >> You do, if you give it two minutes' thought. You call a method or do whatever >> in a constructor after the object has reached a certain level of construction. >> In order to reach that level, the superclass aspects have to be constructed >> first, even to reach the subclass's constructor aspect. If you want something >> other than default superclass construction, you have to do it first. > > > So you all say it's a safety thing, right? It forces a design where > initialization of an object gurantees that all inherited initializations > will execute first. > > Nice. ;) > > But many other languages allow you to override constructors! Are they > old, obsolete? Appealing to "other languages" isn't of much use. Many other languages, for example, have `goto'. > Are there any other reasons besides good design? > > If we talk about errors that may occur if you could override a > constructor then we could say those same erros could occur if you > override any other protected method. Since Java cannot prevent all errors, is it your belief that it should not bother trying to prevent any at all? As to the "any other protected method" remark, note that a constructor is not a method despite many surface similarities. > Why is proper construction sequence so important? Why not just leave it > to access modifiers? Wouldn't that be more straightforward than having > silly rules like "super() must be the first line"?? 1: So a class can establish its invariants, and not worry about a subclass messing them up. (1a: So a subclass can rely on its superclass to operate as advertised, without the subclass needing to take on the responsibility for correct operation.) 2: I don't understand the suggestion. What does access have to do with sequencing? Accessibility is a static attribute, not a time-varying property. (Absent skulduggery, that is.) 3: Since I don't understand (2), I can't tell whether it would be less silly. > I mean, if it's a call, and not a syntax issue I'd like to write it > wherever I like. Let _me_ worry about proper initialization. :) No, because I don't trust you. I've written my class, and you're extending it, and I have no idea whether you know enough about my class' internals to be able to duplicate them in your code. (In fact, I've used an obfuscator on my class' byte code specifically to conceal those internals from you. If you know enough about them to replace bits and pieces at will, you must have worked hard to reverse-engineer the code in violation of your license, and my attorneys will be in touch with you.) Even without the licensing and trade secrets stuff, think of the position you're putting the superclass' author in if you allow any old subclass to muck with the internals. Some user reports that there's a bug in my class; I say "Thanks for the report" and send a fix. The fix involves adding a new private reference variable, and having the constructor initialize it to point to something useful. Other methods then use that variable to get at the useful goodies, and my fix solves the problem. ... except that you have somehow overridden my constructor (you clever devil), so my constructor's code never runs and the added reference remains null. When another method comes along, there's a NullPointerException and I get another bug report from a user who's becoming very angry at my inability to fix things. I guess from your perspective this is a Good Thing: You've made the mistake of failing to read my mind and anticipate all my fixes, but I take the heat for your failure! No, thanks, Pitch. I'm too egotistical about my own code to allow you to inject yours into the middle of it and then get me to take the blame. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Arne Vajhøj on 9 Feb 2010 19:46 On 09-02-2010 13:12, Tom Anderson wrote: > On Mon, 8 Feb 2010, Arne Vajh?j wrote: > >> On 08-02-2010 02:09, luc peuvrier wrote: >>> On 8 f?v, 04:23, Lew<no...(a)lewscanon.com> wrote: >>>> Lew wrote: >>>>> just between us, after 30 years of programming I have never handled >>>>> monetary data: surprise, right? >>>> >>>>> I am really happy to learn than float is not proper. >>>> >>>> Think about the reasons why. >>> >>> Luc: >>> float is an approximate numeric datatype, as defined by ANSI >>> standards. >>> http://stackoverflow.com/questions/285680/representing-monetary-values-in-java: >>> >>> "Martin Fowler recommends the implementation of a dedicated Money >>> class to represent currency amounts, and that also implements rules >>> for currency conversion." >> >> That is one option. >> >> java.math.BigDecimal may be good enough for many cases. > > Or int/long and establishing a convention that you're working in pence, > or thousandths of a dollar, or whatever is suitable. Yes, but why bother when BigDecimal already handle it. Arne
From: Arne Vajhøj on 9 Feb 2010 19:51 On 09-02-2010 10:30, markspace wrote: > luc peuvrier wrote: >> I had to obey to my project manager and architect. >> I understood they want to reduce stacking layer between the objets in >> memory and the bytes in the file. > > Huh, this bit is interesting. Why is main memory and disc memory > constrained? > > Are you working in a restricted environment like JME? Java ME ?? > Why is it better for your manager to pay you for several hours for work, > rather than to just go to the store and buy 2Gb of memory for $100? > (Which should be, what, worth one and a half hours of your time, minimum?) It is less these days. I would say that for servers that is how the math is. But there are low end laptops today that is sold with just 1 GB. Arne
From: Pitch on 10 Feb 2010 07:09 In article <hksqmq$85m$1(a)news.eternal-september.org>, esosman(a)ieee-dot- org.invalid says... > > On 2/9/2010 3:13 PM, Pitch wrote: > > In article<hks15c$7lg$1(a)news.albasani.net>, noone(a)lewscanon.com says... > Appealing to "other languages" isn't of much use. Many > other languages, for example, have `goto'. Which does not exclude they could have good stuff too. > > Are there any other reasons besides good design? > > > > If we talk about errors that may occur if you could override a > > constructor then we could say those same erros could occur if you > > override any other protected method. > > Since Java cannot prevent all errors, is it your belief that > it should not bother trying to prevent any at all? No, I just want to know why. > > Why is proper construction sequence so important? Why not just leave it > > to access modifiers? Wouldn't that be more straightforward than having > > silly rules like "super() must be the first line"?? > > 1: So a class can establish its invariants, and not worry > about a subclass messing them up. (1a: So a subclass can rely > on its superclass to operate as advertised, without the subclass > needing to take on the responsibility for correct operation.) If subclass messed them up it is the same thing as the caller messed them up. That's why we do input validation. > > 2: I don't understand the suggestion. What does access have > to do with sequencing? Accessibility is a static attribute, not > a time-varying property. (Absent skulduggery, that is.) Well, actually you're right. It has nothing to do with it. I was more thinking about hiding constructors and using abstract methods to force initialization but it's irrelevant. > > I mean, if it's a call, and not a syntax issue I'd like to write it > > wherever I like. Let _me_ worry about proper initialization. :) > > No, because I don't trust you. I've written my class, and > you're extending it, and I have no idea whether you know enough > about my class' internals to be able to duplicate them in your > code. (In fact, I've used an obfuscator on my class' byte code > specifically to conceal those internals from you I don't need to know your internals or duplicate anything I just want to change the arguments before calling your constructor. Your own example with prime values shows it. If I want to do that I need some tricks like separate init methods, static methods etc.. <...> > No, thanks, Pitch. I'm too egotistical about my own code > to allow you to inject yours into the middle of it and then get > me to take the blame. I suggest you check the arguments and use the InvalidArgumentException. :) -- stirr your cofee properly
From: Eric Sosman on 10 Feb 2010 09:24
On 2/10/2010 7:09 AM, Pitch wrote: > In article<hksqmq$85m$1(a)news.eternal-september.org>, esosman(a)ieee-dot- > org.invalid says... >> >> On 2/9/2010 3:13 PM, Pitch wrote: >>> [...] >>> Why is proper construction sequence so important? Why not just leave > it >>> to access modifiers? Wouldn't that be more straightforward than having >>> silly rules like "super() must be the first line"?? >> >> 1: So a class can establish its invariants, and not worry >> about a subclass messing them up. (1a: So a subclass can rely >> on its superclass to operate as advertised, without the subclass >> needing to take on the responsibility for correct operation.) > > If subclass messed them up it is the same thing as the caller messed > them up. That's why we do input validation. How can the superclass' constructor validate its inputs if the subclass has somehow substituted its own code so the superclass' constructor never even runs? >>> I mean, if it's a call, and not a syntax issue I'd like to write it >>> wherever I like. Let _me_ worry about proper initialization. :) >> >> No, because I don't trust you. I've written my class, and >> you're extending it, and I have no idea whether you know enough >> about my class' internals to be able to duplicate them in your >> code. (In fact, I've used an obfuscator on my class' byte code >> specifically to conceal those internals from you > > I don't need to know your internals or duplicate anything I just want to > change the arguments before calling your constructor. Your own example > with prime values shows it. > > If I want to do that I need some tricks like separate init methods, > static methods etc.. ... and those "tricks" are available to you. What's the problem? >> No, thanks, Pitch. I'm too egotistical about my own code >> to allow you to inject yours into the middle of it and then get >> me to take the blame. > > I suggest you check the arguments and use the InvalidArgumentException. > :) Yes, I see the smiley, but even so I don't think you Get It. Here's a toy class: class Toy { private final ToyBox box; Toy(ToyBox whereItBelongs) { box = whereItBelongs); } void takeOutAndPlayWith() { box.remove(this); } void putAwayAndSitDownForSupper() { box.insert(this); } } Suppose you extend this with an ElectronicToy class (with additional methods for replacing batteries and such), and you somehow instantiate an ElectronicToy without running Toy's constructor. Your ElectronicToy "is a" (or "is supposed to be a") Toy, so you ought to be able to takeOutAndPlayWith() it -- except that the `box' reference has never been set up, and there's a NullPointerException. Now, how do you propose that takeOutAndPlayWith() should deal with this situation? I suppose you could do void takeOutAndPlayWith() { if (box == null) throw new IllegalStateException(); box.remove(this); } .... but has changing NPE to ISE improved anything? The kid with the toys gets an exception, and a stack trace fingering my code (not yours, although it's yours that's at fault), and just between you'n me, Pitch, I find petulant children tiresome. And that's my last word on the matter, because I find petulant children tiresome. -- Eric Sosman esosman(a)ieee-dot-org.invalid |