On Wed, 25 Apr 2012 16:17:10 +0200, Rasmus Schultz <ras...@mindplay.dk>
wrote:
On Tue, Apr 24, 2012 at 10:10 PM, Anthony Ferrara <ircmax...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
