On Thu, 10 Mar 2016, 12:29 Tony Marston, <tonymars...@hotmail.com> wrote:

> "James Titcumb"  wrote in message
> news:CAKnqCEZMh-P8XmAeQtdPnw4ZaZGb4=wmm_9qyzphtupuwax...@mail.gmail.com...
> >
> >>
> >> need to have their competence, professionalism, and intelligence
> >> questioned.
> >
> >Tony, making a statement like this is unprofessional in itself. You've
> >already been asked to put emotions aside and discuss this topic on the
> >technical merit,
>
> * rant content *


All that may be true for a language, that was designed in the first place.

PHP had a different path, one that made it grow organically and with lots
of mistakes, inconsistencies and other problems. All that means that any
effort to clean up the language and engine are going to break a lot of old
code whatever you do to the language. Heck, before PHP7 there where
limitations to the language parser that just prevented quite a few good and
sizeable rfc's from being implemented.

And as I said previously, var is actually missing functionality to be an
alias of public. They are not the same functionality wise. Var cannot
replace public in all cases.


I mean, I have 2 10-12 years old projects (no one actually knows how old
they are, just that it's 10+), that I do support. And that support includes
actually fixing a lot of problems, much more serious and impactfull than
"var". I'm running them on 5.6 in E_ALL mode, going to move to PHP 7 in
coming month or two.
You either maintain it, or you just get stuck on old PHP versions, that's
it. I did migrate them from 5.2 to 5.6 in one go - that was my first task
when I got them. And that doubled the performance too. The amount of stuff
that was dropped and changed in between these versions is huge, and still,
it was not hard at all. Mostly mondain stuff. So I perfectly do know the
hardships of legacy software in PHP - hype is overrated.

I have the opinion that the more hard the project is to support, the lazier
the developers that work on it are/were.

Reply via email to