On 18 January 2015 at 12:23, Tony Marston <tonymars...@hotmail.com> wrote:
> "Rowan Collins" wrote in message news:54baba93.9070...@gmail.com... > >> >> On 17/01/2015 18:33, Todd Ruth wrote: >> >>> As already mentioned I think as an end result we shouldn't have two >>>> >ways to define constructors. Given that PHP already prefers the >>>> >new-style constructors I've proposed that we work towards dropping the >>>> >old-style, it's just down to a matter of how. >>>> >>> I've been following these threads for about 10 years and beg that php >>> internals continues to "live and let live". >>> There have been many, many threads over the years from what I would call >>> (with obvious bias) "OO fundamentalists". They seem to be at war with >>> code that is "bad form". >>> >> >> This is an argument that comes up a lot, and it has some merit, sometimes. >> >> I don't think using __construct over named-method for constructors really >> has anything to do with "OOP fundamentalism"; it was a design change to >> make certain things simpler (like parent::__construct), >> > > This problem is partly solved in the RFC for Default Constructors (see > https://wiki.php.net/rfc/default_ctor). If this were extended to cope with > PHP 4 style constructors as well then all the problems would be solved. > Then > there would be no need to remove PHP 4 constructors at all. > > That's a good example of supporting old features adding complexity. You're right, it could solve this problem, at the expense of extra code, with extra possibility of bugs. > and more consistent (all reserved magic methods begin with __, so any >> method not beginning with that is safe to use however you like). >> >> In the global cost/benefit analysis I don't see that the >>> benefits of purifying OO outweigh the costs. >>> >> >> Not everything is a matter of code style - supporting legacy features >> comes >> at a cost in complexity, >> > > All compilers are complex beasts - that is the nature of compilers. If you > cannot handle that complexity you shouldn't be working on a compiler. Saying that something is complex in no way justifies making it more complex; arguably, quite the opposite: compilers (and runtime engines) are complex enough at the best of times, so features which add to that complexity should be carefully evaluated to avoid the whole thing becoming an unmaintainable mess. > > > and sometimes even performance. Whenever new features are added - such as >> the ability to call parent::__construct when the parent doesn't declare a >> constructor explicitly - decisions have to be made on how they interact >> with old features - such as PHP4-style constructors. And simply by having >> an accumulation of old features, the codebase is larger, harder to >> understand, harder to change, and has more surface area for bugs. >> > > Removing long-standing features for no good reason (and a change in style > is > never a good reason) does nothing more than frustrate all those 240 million > website owners who find that their existing applications will no longer > run. > This is the primary reason why there is a slow adoption rate for each new > release. If you stop breaking the language then the adoption rate will be > quicker. I'm not sure why you've replied with a well-worn argument about "no good reason" to an e-mail whose sole purpose was pointing out a good reason. You may think my reason is not valid, but that doesn't make this paragraph remotely relevant or insightful. > > > Deprecating a feature or raising an E_STRICT doesn't, of course, reduce >> this complexity by itself - indeed, it slightly increases it - but it >> paves >> the way for a future version to decide that this feature is no longer >> supported, and can be removed in order to improve the rest of the engine. >> >> So, you are quite right to highlight the costs of doing this, and they may >> well outweigh the benefits in this case. However, you are wrong to assume >> that the only benefit to be weighed is "purifying OO". >> > > Yet the reasons I have seen for removing an existing feature are rarely to > fix a problem but to make the language "cleaner" or "more consistent". What > this means in reality is "PHP would be cleaner if it didn't contain all > those features that I don't like and I don't use, and I don't want anybody > else to use them either". > Again, you have opted to ignore my point rather than respond to it. I am not saying there is definitely sufficient justification to remove this particular feature, but the idea that PHP could simply continue forever to support every feature it has ever had, with no cost to anyone, and that therefore anyone wanting to remove things is some kind of selfish dictator is patently false. Those proposing changes should certainly justify the benefits, but those opposing should not simply pretend that those benefits cannot exist. Regards, -- Rowan Collins [IMSoP]
