Re: Re: internals Digest 24 Apr 2012 22:20:08 -0000 Issue 2675

On Wed, 25 Apr 2012 16:17:10 +0200, Rasmus Schultz <rasmus@mindplay.dk> wrote:

On Tue, Apr 24, 2012 at 10:10 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:

Well, it's redundant for a single class. It's not redundant with inheritance. Otherwise a child class could define a writer for that property, which may be undesirable... Then again, what are the use cases for an enforced read-only (or write only for that matter)...?

I don't see how you'll have any trouble finding use cases. Any library that has a get* method but not a set* method is potentially a candidate if subclasses can't touch the underlying data. PHP, in several modules (e.g. dom), uses read-only properties.

In my opinion, that's the kind of thinking that made Java overly ceremonious. If I have a real reason to make something writable that wasn't writable in the base-class, why make that harder than it has to be?

If you have reasons to access a field in the base class, why make it harder by having these "private fields"? There are several reasons for this like encapsulation and enforcement of contracts. You're approaching the problem in the wrong way by saying that despite the read-only in the base class, you want to be able to write and such action makes sense. The premise here is that the superclass declared a property read-only when the inheritance interface should allow for it to be written; that is, read-only was used in error in the superclass. So the problem that exists in your situation was introduced in this premise; it doesn't follow from the mechanisms of read-only. -- Gustavo Lopes