On 8/25/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > I agree with Igor here. If you are really concerned about protecting private > fields, your only option is running with a security manager. > Otherwise there will always be a way around it.
Well, yeah. I know there are ways around it, but actively facilitating it is something else imho. > Being able to access private field is > convenient and reduces code clutter. Even though it's not the "cleanest" way > around, the practical benefits IMHO outweight the drawbacks. I am personally not *that* concerned about encapsulation for my personal needs, but I *am* concerned about predictable behavior. Let's get back to the start of this thread. I think this: with "public getXXX" and "private setXXX" the property is read only with "public getXXX" and "no setXXX" the property is read only is very counter intuitive. I very much disagree with that if there is a private setter it is read only, but if there is just a private field, it is accessible. If we decide to keep supporting setting private members, we should support going through the private setter first. Otherwise it is just very inconsistent to me. Finally, I'd like to hear a good argument why we shouldn't just say: if you want to access members directly, just make them public. If you want to avoid clutter (i.e. writing getters and setters) and you don't care about breaking encapsulation, why not do it the Java-way? Saying that you don't want to expose your members for normal Java programming, but do want to expose those members when using a property model strikes me as having a double standard. My 2c, Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
