Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80804
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
Message-ID: <54BCE8F5.5080407@gmail.com>
Date: Mon, 19 Jan 2015 11:22:29 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAFMT4NpJxuuqc-wTr1aE4K+wZBT8+04j+9-SsY+nhUMU83fDUg@mail.gmail.com><0DD30A0D-E7CA-4150-83E0-8FD46635279C@ajf.me><CAFMT4Nq1X0bONCs=TJyjB1vZ=+UEnX0L8pSex5fWfUMssh4ktQ@mail.gmail.com><alpine.DEB.2.11.1501161126340.4080@whisky.home.derickrethans.nl><CAMc0WS7MjJ85BTSQcRZtGS5MU_9_DfU95SRh6qkmDgWkS2dO4w@mail.gmail.com><8761c6280g.fsf@margaine.com><54B91D16.70901@gmail.com><CAMc0WS5LpdVqF_5P8UiWBzuQc+maX+Shmmi8pZLgGRfOJ7aEmg@mail.gmail.com><AC.11.47555.0404AB45@pb1.pair.com><CAEZPtU7zTKZY4=n_pahWeW2G7JANNnrOZWHHz4bcVb-VGFpegA@mail.gmail.com><78.22.47555.7C24AB45@pb1.pair.com><CAFMT4NrH+=6B4=kVyrmW1Oc0N-_ONNdjaWK0xZCXDVnV_pn-Nw@mail.gmail.com><1421519637.40188.1.camel@proposaltech.com><54BABA93.9070809@gmail.com><EC.EA.18613.9D5ABB45@pb1.pair.com> <CALKiJKr3os6Ta55RjLq61o1+On-S3j8xFzMhJvqfxOzLZwT+vA@mail.gmail.com> <49.CA.64889.A5EDCB45@pb1.pair.com>
In-Reply-To: <49.CA.64889.A5EDCB45@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: rowan.collins@gmail.com (Rowan Collins)

Tony Marston wrote on 19/01/2015 10:37:
> "Rowan Collins"  wrote in message 
> news:CALKiJKr3os6Ta55RjLq61o1+On-S3j8xFzMhJvqfxOzLZwT+vA@mail.gmail.com...
>>
>> On 18 January 2015 at 12:23, Tony Marston <TonyMarston@hotmail.com> 
>> wrote:
>>
>>> "Rowan Collins"  wrote in message news:54BABA93.9070809@gmail.com...
>>> 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.
>
> And adding new features does not also increase complexity?

Where did I say anything to the contrary?


>
>> You're right, it could solve this problem, at the expense of extra 
>> code, with
>> extra possibility of bugs.
>
> Adding new features also comes with the expense of extra code, extra 
> complexity, and extra possibility of bugs. I actually look at the 
> notes for each new release and I regularly see fixes to recently added 
> features.

Yes, complexity is a necessary evil. That doesn't mean we should give up 
trying to control the 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
>
> New features add to the complexity more than old features.

Maybe. Also, old features add to the complexity *of* new features, 
because every interaction between features has to be considered.

None of which changes my point, which was simply that supporting old 
features adds some complexity, and removing that complexity can be a 
good thing in itself.


>
>> to avoid the whole thing becoming an unmaintainable mess.
>
> Surely the core developers are competent enough to understand the 
> necessity for structured code? If they followed all the "best 
> practices" that exist on the web then how can they possibly produce 
> code which can be described as a mess?

Sure, and some of those "best practices" involve refactoring your code 
to have fewer edge cases where possible. Unfortunately, people may be 
relying on those edge cases, so a compromise has to be reached.


>
> <snip>>
>
>>> 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.
>
> The only "good reason" given is that developers should no longer be 
> using them.

No, that is not the only reason given. This entire sub-thread is me 
giving another reason. It may not be a good enough reason, but it is a 
completely separate reason.

Rather than simply assuming that people have no reason for something, 
why not ask what their reasons are *and listen to the answer*.


> BC breaks should only be allowed for bug fixes or security issues and 
> never to enforce a new style over an older style. There are no 
> problems with PHP 4 style constructors which could not be solved with 
> an extension to https://wiki.php.net/rfc/default_ctor. The removal of 
> PHP constructors would, however, cause problems in all those 
> applications which use them, and this in turn would slow down the 
> adoption of the new release. All you would be doing is solving a very 
> minor "problem" for yourselves but creating a huge problem for your 
> customers, all those 240 million websites which run PHP applications. 
> Such a total disregard for customer satisfaction would not be 
> tolerated in any other industry, or in many other segments of the 
> software industry, so dismissing this argument as irrelevant shows 
> that you haven't a clue about customer relations.

You've said all this before. I understand. I agree that it should be 
taken into account. I don't think it's the whole story.



> 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.
>
> You mean that it is perfectly OK to remove a feature which is no 
> longer supported? But the point is that PHP constructors *ARE* still 
> supported in PHP 5. All my classes, and I have hundreds of them, use 
> PHP 4 constructors. I am running version 5.6.4 and all my scripts run 
> as expected and do not throw out any E_DEPRECATED or E_STRICT errors.

That's not what I said at all. I said that adding a notice now might be 
sensible because in future we can simplify the engine by removing the 
support.


>> 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,
>
> Adding new features increases code complexity and the possibility of 
> new bugs.
> Bug fixes themselves can also introduce new bugs.
> Leaving in existing features do not cause bugs.

Sure, just leaving code untouched can't introduce new bugs, although it 
might harbour old ones that haven't been spotted yet. However, 
maintaining emulation of an old feature while changing the code, or 
introducing new features which interact with the old, can cause new bugs.


>> and that
>> therefore anyone wanting to remove things is some kind of selfish 
>> dictator
>> is patently false.
>
> If the only reason for removing an existing feature is "*I* don't use 
> this feature, and *I* don't want anybody else to use this feature" 
> then I would call that behaviour selfish and dictatorial.

My entire point is that it is not the only reason.


>
>> Those proposing changes should certainly justify the benefits, but those
>> opposing should not simply pretend that those benefits cannot exist.
>
> But the only benefits with the removal of old features is a smaller 
> code base for the core developers. The only "benefit" which is 
> experienced in userland is that applications which have run for over a 
> decade suddenly stop working.
>

Ah, so you admit there may be benefits? Again, I do not say that those 
benefits are definitely enough to justify the change in this case, but 
they are real, and I would like you to stop dismissing them.

Regards,
-- 
Rowan Collins
[IMSoP]