Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1D.BB.64889.6043DB45@pb1.pair.com>
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>
	<54BCE8F5.5080407@gmail.com>
	<97.D7.64889.15C1DB45@pb1.pair.com>
	<CAPhkiZz=gYDbHngV+gHhTgW415_KxoCU-31OiW=dxPkPg=tqHQ@mail.gmail.com>
	<1D.BB.64889.6043DB45@pb1.pair.com>
Date: Mon, 19 Jan 2015 20:18:32 +0200
Message-ID: <CAPhkiZzYTddn2B_E84ygk3xHiUDGH-m0jtQDLO85CY3pc8CgUA@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: narf@devilix.net (Andrey Andreev)

On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston <TonyMarston@hotmail.com> wrote:
>>>>
>>>> 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.
>>>
>>> There is a big difference if a BC break which causes a minor benefit to
>>> the
>>> core developers also causes a major headache to the millions of
>>> developers
>>> who are the customers, the people who use the language to develop
>>> applications. The aim should be to eliminate customer grievances as much
>>> as
>>> possible and not to simply ignore them.
>>>
>>
>> You continue doing exactly what you were asked not to.
>
>
> If I wish to complain I don't need to ask your permission. I also have the
> right to respond to every post which argues against my opinion.

Somebody asked you simply to not dismiss their arguments, and you did
exactly the opposite while quoting them. That's just rude and
ignorant, and it will get you nowhere.

If you want others to listen to your POV, you should start doing the
same. This list is not a customer complaints book, it's a place for
discussions.

>> It's not just a "minor benefit to the core developers". It's an
>> extremely unpopular feature
>
>
> "Unpopular" means that people want to see it removed just because they don't
> like it.
>

I don't appreciate you splitting my sentences into small pieces just
to pick on them individually. I don't think I should explain you how
combining words to form a meaning works.

>> that often leads to debugging nightmares even for users with enough
>> experience to take on senior development roles.
>
>
> Ignorance about how PHP works is no excuse. I believe that "RTFM" is the
> standard response in such situations.
>

Talk about ignorance ... you've ignored the new style of coding for a
decade and don't want to be bothered to adapt to it for another one.
TFM clearly favors __construct(), and it does it for a reason.

No matter the cause, if the feature causes issues for the majority of
PHP developers, you can't just give them the finger because you don't
want to spend a few hours renaming Foo::foo() to Foo::__construct().
Arguing about BC breaks is one thing, but don't excuse your own
ignorance with others' lack of knowledge, when they've clearly been
driven into that.

>> PHP 4 style coding is just unknown to the majority of users today and
>
>
> But not for those users who started developing with PHP before version 5
> became mainstream. Your attitude seems to be "Let's ignore those boring old
> farts who made the language what it is today and instead start pandering to
> a bunch of ignorant newbies".
>

Oh, right ... cause pandering to the ignorant old farts is better than
pandering to the ignorant newbies.

Neither is better, of course. However, it's not me who suggested
anything about pandering to a certain group, and you're in the
minority, so you probably don't want to go there - being born earlier
doesn't give you the advantage.

>> most people assume that it is no longer supported
>
>
> Then most people assumed wrongly. Why should one section of the PHP
> community be made to suffer because of a wrong assumption made by another
> part of the community?
>

Again, you're putting this out of context.

>> (or rather, that it
>> was never supported, because they don't even know it existed).
>
>
> Just because a bunch of newbies didn't realise that a feature existed is no
> reason to remove that feature. There are functions in the language that I
> don't use and have no desire to use, but do you see me advocating for their
> removal?
>

You would be, if they were causing you problems.

It's 2015 and we're not talking about just a bunch of newbies. There
are framework developers, evangelists, even core developers who would
guess that this feature no longer exists.

Nobody in the past decade has been taught to use the PHP4-style
constructors. And that means that virtually all of the people who got
into PHP programming during that period (and are aware of the feature)
have learned it through spending hours of debugging because they wrote
a Foo::foo() function.

>> You're
>> obviously an exception to that, and you might argue that somebody's
>> lack of knowledge isn't an excuse to break all of your code, but
>> please stop arguing that a handful of core PHP developers decided to
>> drop a feature for their own benefit alone. That is simply not true.
>
>
> What benefit will there be to the PHP community outside of the core
> developers? Applications which don't use PHP 4 constructors will not notice
> a difference, but those which do will break. Where is the benefit in that?
>

You're talking about complete, already running applications and
completely ignoring the development process itself. It's kind of
ironic that you're doing that because you don't want to spend time for
development.

>> Also, I haven't seen PHP4 style constructors used in years and you're
>> making it sound like every PHP application on the internet uses them -
>> very far from it.
>
>
> Just because you haven't seen any does not mean that they don't exist. It
> has already been pointed out that there are a large number of PEAR libraries
> which were written with PHP 4 constructors and have never been updated.
>

PEAR is not the PHP ecosystem's backbone anymore.

My point was that just because it exists, it doesn't mean that it's
everywhere like you were implying. And you're stubborn, but don't
stupid, so you're perfectly well aware of what I meant. Don't put
words in my mouth.

In fact, you're contradicting yourself here - you don't want to admit
any benefit of the feature's removal in PHP7, which should mean that
you do intend to upgrade, yet you're backing your claims with
dependancy on PEAR code by assuming that it won't get updated ever.
I don't get it ... do you really care about using up-to-date code or
not? If you want to rely on PEAR forever and assume that nothing in it
gets updated, then you don't care about that. So why are you arguing
and not just stay on PHP 5?

>> That being said, it is still a major BC issue and unfortunately we're
>> not going to have PHP 5.7 where it could've been deprecated, so I
>> guess being stuck with this feature (but deprecated) in PHP7 might be
>> the wiser choice.
>>
>> Cheers,
>> Andrey.
>
>
> --
> Tony Marston

Which brings us back to the ignorance ... you didn't focus on
suggesting that deprecation would be better, where you would've
received some support, but instead opted to argue that yours is the
one and only valid opinion.

All you were (kindly, compared to your attitude) asked to do was to
admit that there are two sides on a coin and stop ignoring other
people's opinions. When you're unwise enough not to do that, well ...
have fun arguing with yourself, cause nobody's going to listen to you
either.

I'm out of this deadlock.

Cheers,
Andrey.