"Andrey Andreev" wrote in message
news:caphkizzytddn2b_e84ygk3xhiudgh-m0jtqdlo85cy3pc8c...@mail.gmail.com...
On Mon, Jan 19, 2015 at 6:42 PM, Tony Marston <tonymars...@hotmail.com>
wrote:
<<snip>>
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.
It is not up to the language developers to dictate what style of coding
individual developers should or should not use. It is up to you to provide a
library of features, and it is up to the individual developer to decide how
to structure those functions into a coherent program. There is no such thing
as a single "proper" style which is universally accepted and can be
universally enforced.
TFM clearly favors __construct(), and it does it for a reason.
The fact that the manual prefers the new kind of constructor does not mean
that I am forced to use it. PHP 5.6.4 still supports the use of the old
constructors without issuing any deprecated notices so that means that they
are fully supported.
I still use PHP 4 constructors for the simple reason that I developed my
open source framework using PHP 4, and when PHP 5 came out I had to support
both versions at the same time for many years until PHP 4 actually died. I
had no real "need" to change the constructors, so I did not see any need to
spend time in fixing what was not broken.
No matter the cause, if the feature causes issues for the majority of
PHP developers,
A vociferous group of developers, yes, but how can you prove that this is
the majority? And the issues are not due to bugs in the language itself but
their failure to fully understand how the language actually works.
you can't just give them the finger because you don't
want to spend a few hours renaming Foo::foo() to Foo::__construct().
I should not have to spend any time at all in fixing what shouldn't have
been broken in the first place.
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.
Excuse me? How can others' lack of knowledge be down to ignorance on my
part?
It is their lack of knowledge which caused them to make newbie mistakes.
Developers with more experience would not make such fundamental mistakes.
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.
It is your job to pander to the wishes of all your customers, both old and
new. Alienating your loyal and long-standing customer base just to pander to
the whims of a bunch of ignorant newbies who can't be bothered to RTFM is
not the way to achieve this. You need to maintain a balance, and this means
not letting the pendulum swing too far in favour of one over the other.
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,
I may be in a minority among the people who have joined in this particular
discussion, but what figures do you have regarding the number of websites of
the 240 million out there that will be affected by this proposed change and
who would voice their complaint if they knew about it? The only way they can
currently register their disapproval of your constant stream of BC breaks is
by not updating to the new version as soon as it is released. This is why
20% of PHP sites are still stuck on version 5.2 and 45% on version 5.3. That
shows exactly how popular your releases with BC breaks really are if 65% of
websites can't upgrade because of BC breaks.
so you probably don't want to go there - being born earlier
doesn't give you the advantage.
It gives me the advantage of experience.
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.
How? I'm quoting exactly what you wrote in the way that you wrote it. I am
not mixing and matching words from different sentences to produce a sentence
that you did not actually write.
(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.
But that's the whole point. I have been using PHP 4 constructors with PHP 5
for over 10 years without any problems whatsoever. The only problems that
these other newbies are having is with their faulty coding. The fault is
with their education, not the language.
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.
Their ignorance of how the language works does not justify removing those
features and upsetting the more mature and experienced developers who *DO*
know how the language works.
Nobody in the past decade has been taught to use the PHP4-style
constructors.
Irrelevant. When PHP 5 was released it still supported PHP 4 constructors,
and still supports to them this very day. They have never been marked as
deprecated, so saying that I shouldn't use them is premature. The fact that
you don't LIKE me using them
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.
Then they should try to RTFM like everyone is supposed to do.
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.
Why should I have to keep spending time in refactoring *MY* code because you
keep breaking *YOUR* code? To me application maintenance means fixing bugs
and responding to changes in user requirements. Refactoring code just to
make it look pretty, or to conform to some newbies idea of how code should
be written, is not something that can be justified in the commercial world.
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.
But is is still being used. It is still mentioned in the documentation. It
has never been marked as deprecated, nor has a "new" alternative been made
available.
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.
I'm not putting words in your mouth, I'm just bringing up counter-arguments
to all those arguments which you and your kind keep throwing at me.
In fact, you're contradicting yourself here - you don't want to admit
any benefit of the feature's removal in PHP7,
Because there is no real benefit from the removal of this feature except in
the minds of those people who don't use it and don't want other people to
use it. It does not cause a problem to those developers who know what
they're doing, but it will cause major problems when applications which have
been running under PHP 5 for a decade will no longer work under PHP 7.
which should mean that you do intend to upgrade,
I have already stated that I always try out every new PHP release as soon as
it becomes available as I want to keep up to date with all the bug fixes and
security enhancements. If a feature has been removed because of a serious
problem then I have no problem dealing with it. When I first started coding
with PHP I used register_globals because that was in the tutorials, but when
I realised there was a major security issue I immediately changed my code.
The issue is that the removal of PHP 4 constructors is nowhere near as big
an issue as register_globals, so it does not justify the same solution as
register_globals.
yet you're backing your claims with
dependancy on PEAR code by assuming that it won't get updated ever.
PEAR has not been updated YET. I have never assumed that it will never be
updated. What I have *NOT* seen is any indication that it has been
deprecated in favour of something else.
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?
Because I want to take advantage of the bug fixes and improvements in each
new release. But by "improvement" I do not mean something which pleases the
core developers but displease a significant portion of the user community.
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
There are two sides to this debate - one to take this feature out of the
language and the other to leave it in - and both sides think they have valid
arguments to support their view. It is not just the number of arguments that
should be taken into consideration but the total weight of those arguments.
By "weight" I mean the impact of each of each individual argument as a
number between 1 (low impact) and 10 (high impact). The side with the
highest total weight should therefore win.
As an example, the argument in favour of the removal of this feature based
on the problems it would solve I would rate as a 1 (it is nowhere near as
serious as register_globals), but the problems it would generate in the user
community due to broken applications I would rate as a 10 because nothing is
more serious than an application that stops running. On this basis the
argument for keeping the feature *IN* would be much stronger.
and stop ignoring other people's opinions.
All the while *MY* arguments are being dismissed as irrelevant and the
ravings of an ignorant old fart who's unwilling to change, who can't code
properly, et cetera, et cetera, I will treat *YOUR* arguments in exactly the
same way.
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.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
