subject:"\[PHP\-DEV\] Changing fundamental language behaviors"

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Remi Collet

Le 12/09/2019 à 20:51, Peter Kokot a écrit :

> Just a dumb idea, since there clearly is a majority in favor of the
> change with these warnings and strictness and all that now... Why not
> making something like an LTS PHP 7.x where all the legacy code would
> work OK as long as practically possible and 8.x+ would be the future
> of what the developers want and not what business wants? One who won't
> upgrade due to the BC breaks also won't need the new features anyway
> very realistically.
> 
> Microsoft, Zend, and Red Hat have been showing that this is actually
> possible. How smart this is for the PHP progress is another story, but
> for the business it might be good to think about this also I guess:
> https://github.com/microsoft/php-src/releases
> 
> So, to make some sort of a milestone with some of the versions -
> either 8 or 9 or something.


This is chicken and eggs problem

"Maintained because used" or "used because maintained" ?


PHP 7 was a very good version, with good BC, and speed of adoption is
quite good.

But some users still old 5.x

>From download of my repo [1]

In January, ~35% for 5.6
In August, down to ~28%


IMHO, more BC breaks will mean more time to adapt code and more slow
adoption by users.

So Yes, we'll need a longer support time for 7.4, as we have extended
support for 5.6 by 1 year). Perhaps more will be needed for 7.4.


But yes, we are allowed to change things and dream of a perfect
language, like Perl 6...


Remi





[1] this are only numbers... from about 5k RPM download per day, and
probably artificially bigger for EOL versions, because I'm the only repo
to provide them.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Zeev Suraski

On Fri, Sep 13, 2019 at 11:59 AM Olumide Samson 
wrote:

> "We know it is bad or can be devastating

Actually, that's not at all what we're saying.
I think that doing something like @$foo++ is absolutely fine.  Many others
on this (and related) threads think so too.  I find all the 'improvements'
with littered questionmarks to be a giant step backwards.

> Why were there notices if something wasn't wrong somewhere with the
> behavior?
>

We've been through that.  You may want to take a look again at the
definition of what a notice is.

Zeev said the RFC was never meant to deprecate things and as such the
> voting would eventually not pass on to implementation even if it was
> accepted -
>
> "why then do you vote no on the RFC if it was never a valid vote to count?"
>

Which is precisely why I didn't vote on that particular part of the RFC so
far.  That said - I am considering voting a 'keep notice' on it, and I'll
briefly explain why.

The choice between moving to a warning or keeping a notice is completely
legit, and moving it to a warning may even a good idea (mainly due to error
reporting defaults, even though a notice is technically more appropriate;
main worry is that it might constitute a reason for others in the future to
say it's no longer legitimate, and therefore it's no big deal to deprecate
it).  The part of moving to an error exception is not - as it is a radical
change in functionality (and not a simple 'reclassification of errors'),
aka deprecation.

If I do choose to vote to one of the other two options - it should be taken
in the context of choosing between the two valid options, and not as any
sort of validation on the invalid one.

Zeev

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Stephen Reay




> On 13 Sep 2019, at 15:28, Mark Randall  wrote:
> 
> the notion of
> 
> declare(sloppy=1);
> 
> Has already been jokingly proposed,

Who ever  said it was a joke proposal? :-P

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Olumide Samson

I'm thinking this thread is receiving much attention than really required.

Irrespective of the left and right argument, I think everyone wants a
better language, the leftist are just arguing on a very lazy fact, not that
they don't see anything bad in their wrong argument they are all just
trying to hide behind "We know it is bad or can be devastating, let's just
leave it as it is and hope nobody ever have reasons to clean it since it is
still working" but me and those rightist are all like, this is wrong let's
save billions of codes that could still be added to this buggy behavior
than leaving it and hoping it would be one of the best dynamism people want
from PHP.

How does bug translate to dynamism?

Why were there notices if something wasn't wrong somewhere with the
behavior?

If I'm to argue as php-src(being human), I would never allow those leftist
to use me to write code again coz it is highly straining to pretend to know
what an undefined variable meant( to be an int or string, or even an
object) or even if it was a typo.

We are straining the language performance even more by making it guess what
the undefined variable would have been.

Even a string would still go up as integer the moment you add ++($i++) to
it.

Why don't you people see it is safe and would be in everyone's best
interests if we could clean this garbage behavior once and for all to live
peacefully, and possibly reduce the amount of baggage behavior lying around
in millions of codes out there, coz the counts increase every single day
because everyone thinks it is the right behavior yet their error_log keep
on getting notices?

Zeev said the RFC was never meant to deprecate things and as such the
voting would eventually not pass on to implementation even if it was
accepted -

"why then do you vote no on the RFC if it was never a valid vote to count?"

I think voting on the RFC validates the RFC for all you've voted it for
which means it's a valid way to deprecate features, else all formerly
deprecated features can be reverted since they are invalidated by the
current situation(or eye opening statement you just made).

I think we all need to see from the right spot how many people and code we
would save if this garbage were reported as Warning or error as early as
possible than waiting for never yet still giving me notice in my error_log
everytime PHP hit an undefined variable.

One thing some people are forgetting is that this is an open source
community and people(myself included) coming here to pull, push, commit,
test, manage and even join the mailing list are not getting paid by anyone
to do so(there might be an exception), and being an open source project we
all need to agree to disagree no one has any authority over anyone.

If there's been some laid out rules about some chairmen and the authorities
they posses to always swing things in their favor, I'm very sure this
project would have been dead on arrival( while there are so many projects
wanting attention), since a open source project needs help from
contributors I think we all need to think properly about rules or
guidelines that might hurt the project's contribution.

I don't pray to see PHP 9 timelines not posted by anyone(coz there's no one
around to do so) or even php-src to be one of those languages where their
contribution reduced drastically based on some people's bad influence
affecting the other contributors.

Let's argue rightly and expect other people to not agree with us, that's
the default.

Thanks,
Samson(noobshow)

On Fri, Sep 13, 2019, 9:11 AM Robert Korulczyk  wrote:

> > Upgrading the ~68,000 open source plugins available on wordpress.org <
> http://wordpress.org/>, thousands of commercial plugins, and and an
> untold number of custom-developed bespoke plugins and custom themes is
> where the concern lies.
>
> Many of these are ticking bombs - unmaintained extensions with possible
> security issues. Right now the biggest problem of WordPress ecosystem is
> quality of community extensions and themes. Cutting of all old and
> unmaintained extensions may be not that bad...
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Mike Schinkel

> Many of these are ticking bombs - unmaintained extensions with possible 
> security issues.

Totally agree.

> Right now the biggest problem of WordPress ecosystem is quality of community 
> extensions and themes.

Being intimately involved in the WordPress ecosystem, I do not know If it is 
the *biggest* problem.  

But I digress...

> Cutting of all old and unmaintained extensions may be not that bad...

It depends on who you ask if it is bad or not.  I think that many on this list 
would think it is a good thing.  OTOH, I think many people who have working 
websites that currently use one of these plugins and who do not have developers 
on staff would think it is a very bad thing. Especially if such a change could 
cost them a significant unplanned amount of money and hassle to resolve.

Which brings up an important point. There is a big difference between the 
plugins in the WordPress.org  repo that might have 
security issues  I think the WordPress Core team would be open to sunsetting 
any plugins that are objectively found to have security issues, or even major 
PHP compatibilities.

OTOH, given that WordPress is over 1/3rd of the web that means many of these 
plugins are active on working sites, sites where their web host might encourage 
them to upgrade to PHP8 when PHP 7 is no longer supported.  

It is those people who are likely to be most negatively affected, and the vast 
majority of them will never have hired a developer in their life let alone 
understand why a handful of people decided to "break their site" without them 
having any say in the matter.

#fwiw

-Mike
P.S. Again, I want to clarify I am not saying what the PHP core team should do. 
I am simply relaying what I think the ramifications are likely to be — based 
upon my experience with WordPress since 2010 and PHP since 2008 — if breaking 
changes are introduced into PHP 8.  It is up to the voting members to actually 
decide what will happen.

> On Sep 13, 2019, at 1:11 AM, Robert Korulczyk  wrote:
> 
>> Upgrading the ~68,000 open source plugins available on wordpress.org 
>> , thousands of commercial plugins, and and an untold 
>> number of custom-developed bespoke plugins and custom themes is where the 
>> concern lies. 
> 
> Many of these are ticking bombs - unmaintained extensions with possible 
> security issues. Right now the biggest problem of WordPress ecosystem is
> quality of community extensions and themes. Cutting of all old and 
> unmaintained extensions may be not that bad...
> 
> 
> Regards,
> Robert Korulczyk

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Mark Randall


On 13/09/2019 09:10, Christian Schneider wrote:
Is it really worth it? 


It's absolutely worth it. Stopping execution flow at erroneous or 
ambiguous statements is an essential part of secure, reliable programming.


A notice or warning offers no protection at all. Unless you've taken 
some very specific steps, your program will continue operating as if 
they never happened, even if that notice or warning was clearly a high 
probability of being a bug.


And if you really think so, could we make it opt-in? 


People should not have to opt in to common sense defaults. If I sell you 
a car, you shouldn't have to opt in to having the bolts on your tyres 
fastened on tight enough that the wheels don't fall off the moment you 
hit motorway speed.




Or at least globally opt-out-able?


Let's not. Never again should an option like enable_short_tags exist. If 
you want a per-file opt out, the notion of


declare(sloppy=1);

Has already been jokingly proposed, and I would personally have no 
problem with it if people want to opt-in to less reliable enforcement... 
but once again, I stress that the defaults should always be best-practices.


--
Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Brent

Hello Zeev

Would you mind sharing with us why you specifically would be able to single 
handedly decide what gets merged into PHP and what not?

Kind regards
Brent
On 13 Sep 2019, 01:56 +0200, Zeev Suraski , wrote:
>
> > On 13 Sep 2019, at 2:50, Joe Watkins  wrote:
> >
> > Zeev,
> >
> > > Without getting to the technicalities, simply put, no.
> >
> > I'm not sure what you intend to do to stop it.
>
> I sincerely hope reason will prevail and we won't have to find out (as I was 
> hoping this part of the RFC won't be put up for a vote so that we wouldn't be 
> in this mess to begin with). I am not looking forward to it - but we will not 
> be depreciating fundamental language functionality regardless of the results 
> of this or any other RFC - as RFCs have no mandate to do that. That is a 
> statement of fact.
>
> Cheers,
>
> Zeev

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Benjamin Eberlei

On Fri, Sep 13, 2019 at 10:10 AM Christian Schneider 
wrote:

> Am 13.09.2019 um 09:41 schrieb Lester Caine :
> > On 12/09/2019 23:16, Mike Schinkel wrote:
> >> Those who vote on this list will decide if breaking WordPress
> end-user's site bothers them or not.
>
> That's something too few people on this list seem to be aware of:
> Breaking other people's perfectly functional code because you believe in a
> different coding style is not something which should be done easily.
>
> > So we *DO* need an LTS version of PHP that will run perfectly functional
> websites for the next ten years while others create the next replacement
> for the likes of WordPress by moving framework functionality inside PHP ...
>
> I agree!
> Which means there will be additional burden on the PHP core developers as
> there will be another version to back port security fixes to for a long
> time. Also not a decision to be made lightly.
>

I would think that this is exactly what a company like Zend would charge
their customers for. Microsoft is doing it for free for 5.6, I imagine for
their bigger Azure customres here: https://github.com/microsoft/php-src

LTS versions should not be the responsibility of the core developers, they
are the responsibile of a legal entity with financial means that either
directly sponsors the OSS project (Ubuntu) or is downstream of the project
(RedHat).

PHP is entirely a community project of volunteers that is already hanging
by a thread given the workload.

> While I do like democracy I also agree with Zeev that it is too easy for
> people to vote yes on a breaking change even if they didn't think it
> through.
>
> So if you voted yes for any change of a notice/warning to an exception
> (which will break things) please reconsider!
> Is it really worth it? And if you really think so, could we make it
> opt-in? Or at least globally opt-out-able?
>
> - Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Robert Korulczyk

> Upgrading the ~68,000 open source plugins available on wordpress.org 
> , thousands of commercial plugins, and and an untold 
> number of custom-developed bespoke plugins and custom themes is where the 
> concern lies. 

Many of these are ticking bombs - unmaintained extensions with possible 
security issues. Right now the biggest problem of WordPress ecosystem is
quality of community extensions and themes. Cutting of all old and unmaintained 
extensions may be not that bad...


Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Christian Schneider

Am 13.09.2019 um 09:41 schrieb Lester Caine :
> On 12/09/2019 23:16, Mike Schinkel wrote:
>> Those who vote on this list will decide if breaking WordPress end-user's 
>> site bothers them or not.

That's something too few people on this list seem to be aware of:
Breaking other people's perfectly functional code because you believe in a 
different coding style is not something which should be done easily.

> So we *DO* need an LTS version of PHP that will run perfectly functional 
> websites for the next ten years while others create the next replacement for 
> the likes of WordPress by moving framework functionality inside PHP ...

I agree!
Which means there will be additional burden on the PHP core developers as there 
will be another version to back port security fixes to for a long time. Also 
not a decision to be made lightly.

While I do like democracy I also agree with Zeev that it is too easy for people 
to vote yes on a breaking change even if they didn't think it through.

So if you voted yes for any change of a notice/warning to an exception (which 
will break things) please reconsider!
Is it really worth it? And if you really think so, could we make it opt-in? Or 
at least globally opt-out-able?

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-13 Thread Lester Caine

On 12/09/2019 23:16, Mike Schinkel wrote:

How many of those are actually developers? Because the way I understand this numbers,
"powering the web", that doesn't mean 34% are also developers. It wouldn't
surprise me if a big portion of these applications could've also be a system written in
another language, deployed, plugins installed, added some themes and done, no PHP
knowledge required.

Most WordPress users are*not* programmers.

Which is why introducing breaking changes to PHP will potentially affect them so
negatively; because they have no programmers on staff nor any skill to fix the problem.
Which means they will have to hire expensive programmers — like me!!! — to fix a problem
that from their perspective they do not understand nor will even recognize a benefit when
the code is "fixed."

Again, I am just presenting this perspective on this list. Those who vote on
this list will decide if breaking WordPress end-user's site bothers them or not.

Something which does not help here is the way WordPress enforces
upgrades that may not be compatible with all elements of the themes that
the user currently has active. I AM a programmer rather than a web
designer and am having trouble keeping WordPress sites stable. To that
end I have decided simply to freeze at PHP7.2 for various reasons but
WordPress is now complaining that the version of PHP is out of date. One
just can't win ... some of the WordPress sites themes will not even work
with PHP7 (or WP5) at all. So we *DO* need an LTS version of PHP that
will run perfectly functional websites for the next ten years while
others create the next replacement for the likes of WordPress by moving
framework functionality inside PHP ... Much of the discussion on new
features cut across the ways frameworks already handle that
functionality ...

--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Olumide Samson

On Thu, Sep 12, 2019, 10:15 PM Chase Peeler  wrote:

>
>
> On Thu, Sep 12, 2019 at 4:59 PM Alexandru Pătrănescu 
> wrote:
>
>> Hi guys,
>>
>> > Many of us don't consider it bad code. I've also always initialized
>> > variables when it was required (and many times when it wasn't) even
>> though
>> > I wasn't forced to do so. A lot of other people do as well. If it's so
>> > important to you, start a program to teach people how you think they
>> should
>> > code.
>>
>> One problem that needs to be understood is that PHP is used by a lot of
>> users.
>> Because it's easy to pick up and you have fast feedback it probably have
>> a higher percentage of juniors than average.
>>
>
> I don't think "new developers might do it wrong" is a very compelling
> argument. We shouldn't handcuff the language because some people might use
> the flexibility improperly.
>
>
>> How language was 10 years ago it didn't helped them much in learning and
>> they did lot of mistakes. Some of those mistakes cost companies lots of
>> money and, in time, people got to the conclusion that PHP is bad.
>> This is a very important thing!, Yes you can write working great code in
>> PHP but it's very easy to write working bad code as well. And it's not
>> about you and me or the other persons chatting here, it's about the rest of
>> the world.
>>
>>
> And I don't think we should take away the flexibility that makes PHP great
> because some people don't use it correctly. "Billy can't code properly
> unless the the application crashes whenever he doesn't initialize a
> variable" isn't any more compelling when it's in the third person than it
> was in the first person.
>

I hate to see people taking PHP dynamic bug-friendly pattern as great
flexibility. Why would something be great and same time be bad?
Isn't that a contradiction?
PHP is great in flexibility for things like being dynamically typed, fast
to launch(major hosts always have it enabled), easier to understand but not
for allowing bugs that can cost huge money in the long run.

PHP is a very good friendly language when it comes to learning, yet the
worst language when it comes to ideology or roadmap.

Most companies only prefer PHP to make fast MVP, but as soon as that stage
passed, their HR would start searching for developers in other better
languages.

Check out stackoverflow and see how many buggy questions are asked daily.

>
>
>> PHP improved on it's bad image in the later years but this needs to
>> continue. IMO, one thing that we need to also do is to make the language
>> image better.
>> With this in mind, I believe the "undefined variable" error will be a
>> step forward.
>>
>>
> But it won't. People that won't a stricter language aren't going to start
> using PHP because it suddenly throws more errors than it used to. As I
> mentioned before, some non-PHP developers I knew find it appalling that
> such a massive BC break was even being considered. As much as they don't
> like the idea of uninitialized variables, the fact that they've been around
> for 20 years and now there is talk of them making applications crash was
> much bigger issue.
>
> The way we improve PHPs image is we show why the things that make it
> unique are actually good things, while adding NEW features to the language.
> No matter how much we try to make PHP like Java, c#, python, etc., it isn't
> going to entice those developers over to PHP when PHP doesn't offer them
> anything different than what they already have.
>
>
>
>> It's not about if you don't consider it bad code and that apparently the
>> majority consider it good.
>> It's that if language wouldn't allow you to write that code it will
>> benefit the language image and the rest of the PHP comunity.
>>
>> Also, I would also like to remind of this:
>> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
>> I think some parts might have been violated multiple time in this thread.
>>
>>
> I can take the hint. This will likely be my last post on the topic. I
> think there are few others on this thread that can take up the fight from
> here on out.
>
>
>> Regards,
>> Alex
>>
>>
>> On Thu, Sep 12, 2019 at 10:29 PM Chase Peeler 
>> wrote:
>>
>>> On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson 
>>> wrote:
>>>
>>> > On Thu, Sep 12, 2019 at 8:11 PM Michael Babker <
>>> michael.bab...@gmail.com>
>>> > wrote:
>>> >
>>> > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson >> >
>>> > > wrote:
>>> > >
>>> > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <
>>> > michael.bab...@gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot 
>>> > >>> wrote:
>>> > >>>
>>> > >>> > Just a dumb idea, since there clearly is a majority in favor of
>>> the
>>> > >>> > change with these warnings and strictness and all that now...
>>> Why not
>>> > >>> > making something like an LTS PHP 7.x where all the legacy code
>>> would
>>> > >>> > work OK as long as practically possible and 8.x+ would be the
>>> future
>>> > >>> > of

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Alexandru Pătrănescu

Hi Zeev,

I just reminded the rules so everyone remembers we have them for this
mailing list.
I actually was not referring to hints 1 and 2, even if I still believe they
are good hints to follow in order to have the discussion more productive
and respectful to everyone.

I was actually referring to rules 1 and 2 that I suspect might have been
violated.
Of course, the evaluation if they broke it or not would be first of all
(and best of all) done by each person individually.
I really hope everyone is self-evaluating every now and then.

Regards,
Alex

On Fri, Sep 13, 2019 at 12:51 AM Zeev Suraski  wrote:

>
>
> On Fri, Sep 13, 2019 at 12:00 AM Alexandru Pătrănescu 
> wrote:
>
>> Also, I would also like to remind of this:
>> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
>> I think some parts might have been violated multiple time in this thread.
>
>
> As was already pointed out in a different thread recently, the ones you
> seem to refer to are guidelines - or rather 'hints'.  They cannot be
> 'violated'.  It doesn't mean it doesn't make sense to follow them - but
> there's a reason they're only hints, and not rules.
>
> Zeev
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Zeev Suraski

> On 13 Sep 2019, at 2:50, Joe Watkins  wrote:
> 
> Zeev,
> 
> > Without getting to the technicalities, simply put, no.
> 
> I'm not sure what you intend to do to stop it.

I sincerely hope reason will prevail and we won't have to find out (as I was 
hoping this part of the RFC won't be put up for a vote so that we wouldn't be 
in this mess to begin with).  I am not looking forward to it - but we will not 
be depreciating fundamental language functionality regardless of the results of 
this or any other RFC - as RFCs have no mandate to do that.  That is a 
statement of fact.

Cheers,

Zeev

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Joe Watkins

Zeev,

> Without getting to the technicalities, simply put, no.

I'm not sure what you intend to do to stop it.

Once again, I remind you that you don't have the authority that your
behaviour communicates you have, at all.

I wasn't starting a conversation, I was communicating facts, and I'm
finished communicating with you.

Cheers
Joe

On Fri, 13 Sep 2019 at 01:45, Zeev Suraski  wrote:

>
>
> On 13 Sep 2019, at 2:21, Joe Watkins  wrote:
>
> Zeev,
>
> I'm going to keep this really short and simple ...
>
>
> I'll do the same.
>
> You don't have the authority to make unilateral decisions for PHP,.
>
>
> Neither does anybody else on this list.  Not even a plurality or a
> majority of folks on this list has the authority to apply the RFC process
> to something it was clearly not designed to handle.
>
> Nothing you are saying is going to have any effect, the people who actually
> work on the language will merge whatever is voted in.
>
>
> Without getting to the technicalities, simply put, no.
>
> Zeev
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Zeev Suraski



On 13 Sep 2019, at 2:21, Joe Watkins 
mailto:krak...@gmail.com>> wrote:

Zeev,

I'm going to keep this really short and simple ...

I'll do the same.

You don't have the authority to make unilateral decisions for PHP,.

Neither does anybody else on this list.  Not even a plurality or a majority of 
folks on this list has the authority to apply the RFC process to something it 
was clearly not designed to handle.

Nothing you are saying is going to have any effect, the people who actually
work on the language will merge whatever is voted in.

Without getting to the technicalities, simply put, no.

Zeev

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Joe Watkins

Zeev,

I'm going to keep this really short and simple ...

You don't have the authority to make unilateral decisions for PHP,.

Nothing you are saying is going to have any effect, the people who actually
work on the language will merge whatever is voted in.

Cheers

On Fri, 13 Sep 2019, 00:17 Mike Schinkel,  wrote:

> > How many of those are actually developers? Because the way I understand
> this numbers, "powering the web", that doesn't mean 34% are also
> developers. It wouldn't surprise me if a big portion of these applications
> could've also be a system written in another language, deployed, plugins
> installed, added some themes and done, no PHP knowledge required.
>
> Most WordPress users are *not* programmers.
>
> Which is why introducing breaking changes to PHP will potentially affect
> them so negatively; because they have no programmers on staff nor any skill
> to fix the problem. Which means they will have to hire expensive
> programmers — like me!!! — to fix a problem that from their perspective
> they do not understand nor will even recognize a benefit when the code is
> "fixed."
>
> Again, I am just presenting this perspective on this list.  Those who vote
> on this list will decide if breaking WordPress end-user's site bothers them
> or not.
>
>
> -Mike
>
> P.S. I am writing during a break at a WordPress conference, ironically.
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Mike Schinkel

> How many of those are actually developers? Because the way I understand this 
> numbers, "powering the web", that doesn't mean 34% are also developers. It 
> wouldn't surprise me if a big portion of these applications could've also be 
> a system written in another language, deployed, plugins installed, added some 
> themes and done, no PHP knowledge required.  

Most WordPress users are *not* programmers.  

Which is why introducing breaking changes to PHP will potentially affect them 
so negatively; because they have no programmers on staff nor any skill to fix 
the problem. Which means they will have to hire expensive programmers — like 
me!!! — to fix a problem that from their perspective they do not understand nor 
will even recognize a benefit when the code is "fixed."

Again, I am just presenting this perspective on this list.  Those who vote on 
this list will decide if breaking WordPress end-user's site bothers them or not.


-Mike

P.S. I am writing during a break at a WordPress conference, ironically.

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Zeev Suraski

On Fri, Sep 13, 2019 at 12:35 AM Lynn  wrote:

> On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer 
> wrote:
>
> >
> > One can argue that WordPress, with it powering 34% of the web (source:
> > wordpress.org) represents more than 50% of PHP users, and therefore
> > aligning the language to how they use it would be sensible, as they are
> the
> > majority of users. PHP and WordPress have had a symbiotic relationship,
> the
> > success of one increasing the success of the other.
> >
>
> How many of those are actually developers? Because the way I understand
> this numbers, "powering the web", that doesn't mean 34% are also
> developers. It wouldn't surprise me if a big portion of these applications
> could've also be a system written in another language, deployed, plugins
> installed, added some themes and done, no PHP knowledge required.
>

Many are. The WP developer ecosystem footprint is at the same order of
magnitude as (and in some geographics larger than) that of 'generic' PHP -
in terms of conferences and conference sizes, usergroups, available jobs,
etc.  I don't think any of us can pull numbers off of our sleeves - but the
vast majority of folks who deploy WordPress sites that I bumped into also
deal with at least some custom PHP code - and are responsible for the
deployment whether they wrote it or not.  It's true that there are many
agencies and freelancers that do a lot more than one site.  But it's also
true that the WordPress numbers are enormous even if we cut them down by a
factor of 10 (which I believe would be big exaggeration)
And of course, the can be said about PHP apps in general - many developers
produce a lot more than just one site.  So while there's no 1:1 correlation
between the number of sites and the number of developers, it's true for
both WP and generic PHP (perhaps in slightly different scales).   And of
course #2 - we're not only talking about WordPress - non-WP developers will
be affected by this as well.

Zeev

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Mike Schinkel

> It's not a matter of won't upgrade, but that they can't upgrade. If Wordpress 
> decides to take their time supporting PHP 8, wordpress users won't have any 
> option but to wait on upgrading.

To be clear, WordPress core upgrading to support PHP won't be a big issue.  And 
WordPress core code has actually improved significantly in recent years.

Upgrading the ~68,000 open source plugins available on wordpress.org 
, thousands of commercial plugins, and and an untold 
number of custom-developed bespoke plugins and custom themes is where the 
concern lies. 

-Mike

> On Sep 12, 2019, at 11:14 AM, Chase Peeler  wrote:
> 
> 
> 
> On Thu, Sep 12, 2019 at 2:10 PM Lynn  > wrote:
> On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel  > wrote:
> 
> >
> >
> > Just a few weeks ago I was refactoring some particularly horrible code
> > developed by previously employed developers — a code based that has a 1400
> > line function and many other functions 100s of lines long, and I added some
> > initialization for variable and array elements prior to their use.
> >
> > Unfortunately my changes broke the code because the original developer
> > using isset($var) as branching criteria.  After finding this bug, I
> > realized that this code base uses that technique frequently.  I am know
> > from lots of experience that this is a common technical among WordPress
> > plugins.
> >
> >
> The bug is not that you initialized the variable, it's that you initialized
> it with a different value: https://3v4l.org/8mB8B 
> ```
> var_dump(isset($a));
> $a = null;
> var_dump(isset($a));
> 
> // gives
> bool(false)
> bool(false)
> ```
> 
> Whenever one of these errors will occur, you can initialize either the
> array key or variable with null and it will work again without changing
> behavior. If anything, Wordpress shouldn't be an argument to not improve
> PHP, though I think it's important to consider the impact of a change,
> including for the Wordpress community. However, I think most people agree
> that the quality of Wordpress code and Plugins is highly debatable. I don't
> like the idea of not being able to progress because Wordpress users won't
> upgrade PHP.
> 
> It's not a matter of won't upgrade, but that they can't upgrade. If Wordpress 
> decides to take their time supporting PHP 8, wordpress users won't have any 
> option but to wait on upgrading.
>  
> Regards,
> Lynn van der Berg
> 
> 
> -- 
> Chase Peeler
> chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Mike Schinkel

> Whenever one of these errors will occur, you can initialize either the array 
> key or variable with null and it will work again without changing behavior. 

Whatever the case, changing warnings to errors would require fixing working 
code. And for many people, that would requiring investing lots of money.

> However, I think most people agree that the quality of Wordpress code and 
> Plugins is highly debatable.

That is probably very true, but it is orthogonal to whether or not certain 
potential changes in PHP would cause expense changes to be implemented in order 
for WordPress users to upgrade to an incompatible PHP8.

> If anything, Wordpress shouldn't be an argument to not improve PHP, though I 
> think it's important to consider the impact of a change, including for the 
> Wordpress community.
> I don't like the idea of not being able to progress because Wordpress users 
> won't upgrade PHP. 

I am not making that argument. I am simply pointing out that the changes being 
considered will almost certainly break a large percentage of WordPress sites 
and fixing those site will likely be very costly for site owners.  

So it is up to those who have a vote on the future of PHP to decide if a large 
number of broken WordPress matters to them or not.  I am just a messenger.

-Mike

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Zeev Suraski

On Fri, Sep 13, 2019 at 12:00 AM Alexandru Pătrănescu 
wrote:

> Also, I would also like to remind of this:
> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
> I think some parts might have been violated multiple time in this thread.

As was already pointed out in a different thread recently, the ones you
seem to refer to are guidelines - or rather 'hints'.  They cannot be
'violated'.  It doesn't mean it doesn't make sense to follow them - but
there's a reason they're only hints, and not rules.

Zeev

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Mike Schinkel

On Sep 12, 2019, at 11:06 AM, Olumide Samson  wrote:
> I think they could switch to using null instead, or perhaps get something 
> else to differentiate what they have initialized or not,

Perhaps, but switching the code requires finding the right people to do the 
work and then funding the changes.

A lot of WordPress code marginally maintained is at best — especially WordPress 
sites.  That differs from what it sounds like are the practices of those who 
are arguing for enforced strictness here on this list.

> that shouldn't stop them from using PHP, probably it will only make them not 
> upgrade to PHP if they think their bad coding practice is the way forward and 
> the best way to code..

Hopefully my words did not imply that. I think I instead stated that they would 
likely never upgrade.

> This is merely assumptions and you can't speak for companies you don't know, 
> what's the statistics backing these your use of "ever and never"?

It is absolutely an assumption. Based on my experience.  But YMMV.

That said, I can give you stats for how many WordPress plugins there are on the 
WordPress repository, around 68,000.  And in my experience a sizable percentage 
of them would break with these changes.  

Whether or not the PHP community cares about breaking a large number of 
WordPress sites or not is up to those of you who get to vote.  I just commented 
to include this perspective since I have not seen anyone else mention WordPress 
on the list recently.

>  It's up to them, PHP 7 is still available and will always be available for 
> them to use... 

Yes. But of course, at some point PHP 7 will no longer be officially supported. 

At which point PHP7 users will be forced to decide between support and choosing 
a support direction for their future.

And again, #jmtcw

-Mike

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Lynn

On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer 
wrote:

>
> One can argue that WordPress, with it powering 34% of the web (source:
> wordpress.org) represents more than 50% of PHP users, and therefore
> aligning the language to how they use it would be sensible, as they are the
> majority of users. PHP and WordPress have had a symbiotic relationship, the
> success of one increasing the success of the other.
>

How many of those are actually developers? Because the way I understand
this numbers, "powering the web", that doesn't mean 34% are also
developers. It wouldn't surprise me if a big portion of these applications
could've also be a system written in another language, deployed, plugins
installed, added some themes and done, no PHP knowledge required.

Regards,
Lynn van der Berg

76 matches

Mail list logo