On Tue, 20 Nov 2001, Ceki Gulcu wrote: > My question was actually about the opportunity of calling readFields. >More like, "how do you know you can call readFields at that point?"
Ahhhh, I'm guessing there are several questions here, so let me take a stab at a few of them (as much so that I can further understand my motivation as to explain it): Q: Why didn't I put the entire contents of customReadObject inside readObject (which would guarantee that ois had not already been tampered with before the call to readFields())? A: I wanted to keep readObject as much intact as possible, so that the changes that I had made would be as obvious as possible. When/if the change is accepted, I would actually be inclined to move the contents of customReadObject into readObject and eliminate customReadObject. Q: Assuming you were going to keep customReadObject, Why doesn't it explain in the doc comment that it requires a "fresh" ObjectInputStream? A: Because I haven't written the commentary yet (or rather, haven't written the production grade commentary). In fact, I might not have thought to document this requirement if you hadn't pointed it out, but that's why I support code audits / peer review (particularly in infrastructure code like a logging mechanism). Q: Why do you prefer fine grained methods, even when it introduces the risk of being passed an object which is in an unusable state? A: Because assuming that the method in question is both private and clearly documented (commentary is coming :), in my experience more bugs grow in long methods than in unsafe internal method calls. When I see a method that's over 50 lines I start to sweat. If it's so long that I can't see it all on screen at once, I occasionally run screaming from the room :) So the answer is a pragmatic one. Like most programmers, I would rather be coding than debugging. One technique that I believe reduces bugs is fine grained methods, even when they're not perfectly safe. There are some other issues that should be addressed, such as "What if a subclass overrides an internal method without knowing it?" Declaring the method final would solve this problem, and using a more "namespace friendly" name might make that a more reasonable solution (EG: prefixing such methods with "le_" to signify that they are Logging Event internal). Hmmm, I rather like that last bit. Think I'll raise that as a discussion topic on my programmers mailing list.... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
