Hi! > The point of this discussion is that there is an RFC on the table > which can be implemented in such a way that it fixes this behaviour > (by introducing a default parent, or injecting an empty constructor) > or such that it carefully preserves it (by making a special case for > parent::__construct).
I was not planning to do this as part of this RFC. Of course, that doesn't mean by itself it should not be done, and if it will be done (after considering all BC consequences, etc.) then the code for this RFC will need to be changed (while the idea stays). But I do not want to mix two things - making parent methods always work in places where it makes sense (ctor, dtor, clone) and refactoring how ctors work to avoid unpleasant side effect of not evaluating params for missing ctor. These are two different things, with different consequences, and I don't see much win in mixing them. > If you are, as you seem to be, defending this as a feature, it > implies we should preserve (and, incidentally, standardise) it. If, No, not really - I don't propose to standardize it. I do propose to preserve it, for basic BC reasons, and I do say it was an intended result, not an accidental omission. Now, this result, of course, can be what we no longer want, and we can change it - but I don't want to make it a part of my RFC because I consider it an independent issue worthy of separate consideration. > This reminds me of the recent discussion over multiple defaults in a > switch. Perhaps as with that we should phrase the question as "is > there any useful purpose to having the language standardised with > this feature, and conversely is there any realistic harm in altering > it?" You make it sound as if I'm somehow calling for some change in "standardizing" this feature. On the contrary, I am just preserving the status quo, it is as "standard" or "non-standard" as it has ever been. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
