> i completely agree with you. my point is that its been brought up, but do > you see anyone else jumping in on this conversation and voicing their > opinion? you are basically championing this thread because you are a core > dev. there are other users on this list, if they were just as concerned > about this im sure they would voice it once the thread got started.
Ok, let's get back to two other occasions: setting the response page in the constructor and setting feedback messages in the constructor. Both occasions were similar threads like these: a user reports something, I'm fighting half of the development team against the status quo, get accused of championing something that is just theoretical, etc. Why can't we just argue to just 'get it right'? To my knowledge - and that might be my sloppy memory - we never actually had a proper discussion about this. Maybe you and Johan and Matej had, but I don't remember OK-ing the fact that having a private setter would block, while having no setter would open it up again. I can't imagine I would agree with that tbh. And that's all fine, we can have that discussion now. The only thing I want to get clear from this thread is whether we all think what we have now is good. I think it isn't. For the sake of clarity, 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 not the way to go. I'm arguing for either using that private setter even though it is private (since we access the private member as well), or not allowing any private access and just tell people to use public members instead (and I still haven't heard a convincing argument against that). Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
