Re: [PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi Lynn,

czw., 12 wrz 2019 o 17:01 Lynn  napisał(a):

> Heya,
>
> What's the added benefit of this compared to implementing a constructor?
>
> The part I like is that this can be used to replace stdClass/structured
> arrays. Perhaps something like this would nice to have in PHP:
>
> ```
> $people = [];
>
> foreach ($peopleFromDatabase as [$id, $username, $name]) {
> $people[] = {
> Uuid id => $id,
> string username => $username,
> string name => $name,
> };
> // and possible automatic assignment:
> $people[] = {Uuid $id, string $username, string $name};
> }
> ```
>

Removing stdClass for instantiation and initialization of simple objects is
one of a future scope proposal.

This RFC tries to address instantiation and initialization boilerplate
reduction with a syntax which would
not be restricted to stdClass only.

Although it's not a game-changer, simple addition to the language which
reduces boilerplate when dealing
with objects which don't need complex constructors like for eg. DTO objects.

Regards,
> Lynn van der Berg
>
>

Regards,
Michał Brzuchalski

[PHP-DEV] Happy International programmers day!

[Alexandru Pătrănescu]

Hi internals!

Thank you for supporting and improving PHP!
https://github.com/php/php-src/graphs/contributors

Have a great day celebrating the 256th day of this year!

You are great and you should know this.

Thank you!

Re: [PHP-DEV] Changing fundamental language behaviors

[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

[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

[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

[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

[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] [RFC] Reclassifying engine warnings

[Arnold Daniels]

l want to point out that way in which notices and warnings are triggered
when concerning operators, is also inconsistent.
Sometimes a check is done by the function of the operator (or a deeper
function). Other times the operator will simply cast the operand and the
casting produces a notice, warning or error.

As an example; The concatenation operator will implicitly cast anything to
a string. Explicitly casting it has no effect

[ ] . 'abc'; // Notice:  Array to string conversion
(string)[ ] . 'abc'; // Notice:  Array to string conversion

But arithmetic operators will do a check. Explicitly casting will remove
any warning or error

[ ] * 10; // Fatal error:  Unsupported operand types
(int)[ ] * 10; // 0
"22 bikes" * 10; // Notice:  A non well formed numeric value encountered
(int)"22 bikes" * 10; // 220

To some extent, the inconsistent error levels come from a different
approach. Even more, there is a big difference between types that can are
cast silently to a non-sensical value and types where any type of warning
or error is given, for seemingly no apparent reason.

Changing the warning levels without addressing this issue doesn't make a
whole lot of sense.

- Arnold
In the past I suggested operators like
??++
??+=
for this purpose.

But the [? $key] is even better, because it makes it explicit which array
keys we expect to already exist and which we don't.

$var[$k0][? $k1][? $k2]++;

This is great but the second "?" is redundant isn't it?
Tekst uit oorspronkelijke berichten weergeven

Re: [PHP-DEV] Changing fundamental language behaviors

[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.
>
>

[PHP-DEV] Syntax Sugar (was [PHP-DEV] [RFC] Reclassifying engine warnings)

[Mike Schinkel]

> One thing I like PHP for is a distinct lack of huge amounts of syntax
> sugar.  Take Ruby - it's a hell to read the code.

I think it is unfair to reference Ruby's capabilities as a counter-example for 
syntax sugar.

The Ruby language allows developers to create what are effectively new language 
constructs and it is possible in Ruby to write code that cannot be recognized 
anyone that has not written the language extensions being used.

PHP does not have that capability, thankfully, and I do not think any proposed 
syntax sugar has any chance of adding those meta-language capabilities into PHP.

Syntax sugar is a good thing when it reduces the need to write boilerplate code 
for a commonly occurring pattern, especially when the boilerplate code is 
tedious and potentially error prone because of typos or logic.  And it is 
naturally occurring in language evolution, i.e. newer languages often provide 
"syntax sugar" for features that are more verbose in earlier languages.

Personally I am not sure I like the proposed syntax, but I am definitely fond 
of the idea to eliminate the boilerplate code that would be otherwise needed to 
build a robust solution.

#fwiw

-Mike
P.S. I wrote a blog post in defense of syntactic sugar a while ago. 
If you are interested in all the arguments in support of syntactic sugar, 
here is the post: https://mikeschinkel.me/2019/in-defense-of-syntactic-sugar/ 





> Even Vagrantfile has tons of
> results about what syntax for arrays to use and things breaking because you
> end up mixing stuff and you get at least 4 different answers to the same
> question and it looks like all are correct. Confusing as hell :)
> 
> What I'm trying to say is some of us choose PHP for it's "there is one
> syntax - use it". If people want syntax sugar - there are other languages
> that fit that much better. Leave us, peasants, in our peasant non-syntax
> sugar world alone :D
> 
> But many of us would also like the language engine to tighten up some of
> its extremely relaxed parts that do not fit in modern development
> environments and the lowest bar of the code quality rise a bit. Otherwise,
> the gap between high-end development and newbies is going to be even bigger
> than it is now.
> I hire people, that's part of my job. One of the criteria is the approach
> to errors/warning/notices. Imagine how that goes.
> 
> -- 
> Arvīds Godjuks
> 
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] Changing fundamental language behaviors

[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

[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

[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

[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] [RFC] Reclassifying engine warnings

[Andreas Hennings]

In the past I suggested operators like
??++
??+=
for this purpose.

But the [? $key] is even better, because it makes it explicit which array
keys we expect to already exist and which we don't.

$var[$k0][? $k1][? $k2]++;

This is great but the second "?" is redundant isn't it?




Marco Pivetta  schrieb am Do., 12. Sep. 2019, 16:26:

>  
>
>
> On Thu, Sep 12, 2019 at 4:02 PM Arvids Godjuks 
> wrote:
>
> >
> >
> > чт, 12 сент. 2019 г. в 15:33, Marco Pivetta :
> >
> >> Hey Rowan,
> >> 
> >>
> >>
> >> On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins 
> >> wrote:
> >>
> >> > For instance, for undefined array keys, what if we had an operator for
> >> > "initialise and retrieve", such as $foo[? 'bar']. Then we could
> simplify
> >> > ugly code like this:
> >> >
> >> > if ( ! isset($foo[$key1]) {
> >> >$foo[$key1] = [];
> >> > }
> >> > if ( ! isset($foo[$key1][$key2]) {
> >> >$foo[$key1][$key2] = 0;
> >> > }
> >> > $foo[$key1][$key2]++;
> >> >
> >> >
> >> > With something safe but succinct like this:
> >> >
> >> > $foo[? $key1][? $key2]++;
> >> >
> >>
> >> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> >>
> >>
> >>
> > This message contains a healthy dose of sarcasm.
> >
> >
> No sarcasm intended: question is about the verbosity and length of a
> *proper* (correct = no warnings/notices/errors, matches type expectations)
> checked solution, and I provided a simple one-liner that is both readable
> and correct.
>
> You can make what you want out of this, but there was most certainly no
> sarcasm.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

Re: [PHP-DEV] Changing fundamental language behaviors

[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] [RFC] Reclassifying engine warnings

[Stanislav Malyshev]

Hi!

> FTR this is basically what Python does via defaultdict:
> https://docs.python.org/3/library/collections.html#collections.defaultdict
> 
> I think it is the "cleanest" solution to this problem overall. Though it
> does need a separate structure, rather than our favorite PHP array.

This is one of the most annoying quirks of python - that you have to use
special package to do simplest tasks like counting anything by key or
write annoying boilerplate code that reminds python that counting starts
with 0. Now strictness zealots want to bring that into PHP. If I was a
person to do that, I'd definitely write a long "python sadness" text and
that would feature there prominently, but I don't have time to do that
so I just note that now, that it is very sad that the annoying quirks of
python are brought into php apparently because more strict is always
better.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Changing fundamental language behaviors

[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

[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

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

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.


> 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 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.
>> > >>> >
>> > >>>
>> > >>> Please don't tie the notion of LTS with the idea that a new major
>> can
>> > >>> break
>> > >>> BC at will or create larger scale breaks because the previous major
>> has
>> > >>> extended support.  Sooner or later that will end up back at the ++
>> idea
>> > >>> and
>> > >>> fragmentation encouraged by the language is a bad idea.
>> > >>>
>> > >>
>> > >> Not sure you are really seeing the goal...
>> > >>
>> > >> Why is LTS not a good idea?
>> > >>
>> > >
>> > > I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
>> > > shipping larger scale BC breaks, such as the changes suggested in the
>> > last
>> > > couple of "contentious" RFCs in a major version because "hey, we have
>> a
>> > LTS
>> > 

Re: [PHP-DEV] Changing fundamental language behaviors

[Alexandru Pătrănescu]

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.
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.

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.

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.

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  >
> > 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 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.
> > >>> >
> > >>>
> > >>> Please don't tie the notion of LTS with the idea that a new major can
> > >>> break
> > >>> BC at will or create larger scale breaks because the previous major
> has
> > >>> extended support.  Sooner or later that will end up back at the ++
> idea
> > >>> and
> > >>> fragmentation encouraged by the language is a bad idea.
> > >>>
> > >>
> > >> Not sure you are really seeing the goal...
> > >>
> > >> Why is LTS not a good idea?
> > >>
> > >
> > > I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
> > > shipping larger scale BC breaks, such as the changes suggested in the
> > last
> > > couple of "contentious" RFCs in a major version because "hey, we have a
> > LTS
> > > version you can use that until you're ready to deal with the backlog of
> > BC
> > > breaks created" is a bad idea.
> > >
> >
> >
> > > For the record, I happen to agree with as these RFCs would have minimal
> > > impact on my day-to-day work, but having also been in the role of a
> > > maintainer of open source libraries and applications I also grasp why
> > these
> > > types of changes can be problematic to the ecosystem (both end users of
> > > those libraries and applications and the maintainers of them) and
> > wouldn't
> > > jump the gun to ship them without careful consideration.
> > >
> >
> > Most of these changes wouldn't have been problematic to you if the
> language
> > has prevented you from writing what we can now consider bad code, so
> please
> > allow the new PHP developer that newly start using PHP to not follow that
> > your path that will/might hunt him later in the future...
> >
> >
> 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.
>
>
> > There a notices, warning and errors to inform you that this shouldn't
> have
> > been the use case of this feature and you chose to ignore it and now, we
> > are simplifying things and making those your errors teach you how to
> write
> > proper codes in the future, you're objecting..
>
>
> As has been discussed before, notices are not the same as warnings and
> errors.  Also, if those things are so wonderful, why can't you use them to
> catch the issues 

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Rowan Tommins]

On 12/09/2019 15:13, Nikita Popov wrote:
FTR this is basically what Python does via defaultdict: 
https://docs.python.org/3/library/collections.html#collections.defaultdict



Thanks, I'm glad I wasn't completely daft thinking there might be some 
way to express it. :)



I think it is the "cleanest" solution to this problem overall. Though 
it does need a separate structure, rather than our favorite PHP array.



Indeed it does, and I think that's the better route to making PHP a 
stricter language: before we take away the existing features, add the 
new ones that let you express things better.


PHP's array type, and its type system in general, allow a lot of very 
expressive algorithms which are hard to do with more rigid type systems. 
Modern languages like C# bring back that expressiveness using things 
like generics, a rich library of built-in collections and interfaces, 
and so on; they don't just say "sorry, you can't do that".


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Peter Bowyer]

On Thu, 12 Sep 2019 at 19:10, Lynn  wrote:

> 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.
>

This raises an interesting, tangential point. Who is PHP for?

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.

Those who wish PHP was more advanced and different (and I count myself
amongst them) do well to remember that PHP has become extraordinarily
successful in spite of the flaws now perceived. It's a good language that
fills a niche even server-side JavaScript hasn't usurped. There is no shame
in a language staying true to its roots, plateauing and eventually dying a
death (cf Perl 5). I don't want that, but it's a valid route. And the
communities that use PHP in a way many on this list look down on will be
thankful to continue to have a language they can use, can hack with, and
get stuff done. Even if there's a few extra bugs.

The rest of us, meanwhile, have the opportunity to use a programming
language that's closer to whatever we feel is a "proper" language (a vibe I
pick up in the "they look down on us" and "I'd rather PHP was more like X"
messages). If you're going to have to justify upgrading your code, why not
propose a rewrite in another language? One can sell it on the fact it won't
have the flaws regularly brought up on this list - like warnings instead of
exceptions, or two opening tags. Or, despite the fuss on-list, do those who
decide how the next project will be written/the current one rewritten, not
care to the same extent, and other factors will influence their choice?

Personally I cannot wait for new features to be added, but feel our
heritage is as important as the future. Jordi expresses my feelings, and I
quote him:

Breaking BC here does not seem to bring much. If there are cases where
> enforcing strictness might allow better JIT for example, then I could
> see the case being made. But simply turning working code into fatally
> failing code isn't progress. [...] So what do we gain exactly?
>

Peter

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Rowan Tommins]

On 12/09/2019 15:43, Robert Korulczyk wrote:

One additional line will make your code much more obvious and easier to read 
and understand:

$i ??= 0;
$i++;



I don't find this code at all obvious:

foreach ( $something as $foo ) {
    $i ??= 0;
    $i++;
}

I mean, huh? What's that zero doing there, is it resetting the variable 
every loop?


Now, in that simple case, you can and probably should initialise the 
counter before the loop:


$i=0;
foreach ( $something as $foo ) {
    $i++;
}


But that's not the example I gave earlier! The example I gave earlier 
was a multi-dimensional array:


$foo = [];
foreach ( $something as $key1 ) {
    foreach ( $somethingElse as $key2 ) {
  $foo[$key1][$key2]++;
    }
}

Even using ??= the initialise-everything-before-use version looks like this:

$foo = [];
foreach ( $something as $key1 ) {
    foreach ( $somethingElse as $key2 ) {
  $foo[$key1] ??= [];
  $foo[$key1][$key2] ??= 0;
  $foo[$key1][$key2]++;
    }
}


Again, the values are confusing: the end result will never contain an 
empty array at the first level, and will never contain a 0 at the second 
level.


Those two lines aren't aiding the readability of that algorithm in any 
way; I have to read past them to find the actual business of the loop, 
which is counting something, using the ++ operator.


What's more, they're not preventing any bugs either! If I accidentally 
reuse $foo from a previous loop, the extra lines won't reinitialise 
anything for me; if I initialise it to empty, the two loops are 
functionally identical.



So that's where I came up with two suggestions to actually add to the 
language, rather than just taking away:


- a more granular way to express that this code is not actually 
error-prone, combining the 3 lines back into one
- or, a way to express the intent of the code more clearly, such as 
declaring the shape of an array



Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 8: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 
>> 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 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.
>> >>> >
>> >>>
>> >>> Please don't tie the notion of LTS with the idea that a new major can
>> >>> break
>> >>> BC at will or create larger scale breaks because the previous major
>> has
>> >>> extended support.  Sooner or later that will end up back at the ++
>> idea
>> >>> and
>> >>> fragmentation encouraged by the language is a bad idea.
>> >>>
>> >>
>> >> Not sure you are really seeing the goal...
>> >>
>> >> Why is LTS not a good idea?
>> >>
>> >
>> > I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
>> > shipping larger scale BC breaks, such as the changes suggested in the
>> last
>> > couple of "contentious" RFCs in a major version because "hey, we have a
>> LTS
>> > version you can use that until you're ready to deal with the backlog of
>> BC
>> > breaks created" is a bad idea.
>> >
>>
>>
>> > For the record, I happen to agree with as these RFCs would have minimal
>> > impact on my day-to-day work, but having also been in the role of a
>> > maintainer of open source libraries and applications I also grasp why
>> these
>> > types of changes can be problematic to the ecosystem (both end users of
>> > those libraries and applications and the maintainers of them) and
>> wouldn't
>> > jump the gun to ship them without careful consideration.
>> >
>>
>> Most of these changes wouldn't have been problematic to you if the
>> language
>> has prevented you from writing what we can now consider bad code, so
>> please
>> allow the new PHP developer that newly start using PHP to not follow that
>> your path that will/might hunt him later in the future...
>>
>>
> 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.
>
>
>> There a notices, warning and errors to inform you that this shouldn't have
>> been the use case of this feature and you chose to ignore it and now, we
>> are simplifying things and making those your errors teach you how to write
>> proper codes in the future, you're objecting..
>
>
> As has been discussed before, notices are not the same as warnings and
> errors.  Also, if those things are so wonderful, why can't you use them to
> catch the issues you are complaining you can't catch right now? Again, you
> are telling me there is something out there which will allow you to force
> yourself to write "good code" without forcing me to follow the same
> restrictions. Yet, you still feel it's necessary to not use those tools,
> and instead modify the entire language so that I am forced to follow what
> you deem best practices, even if I don't?
>
>
>
>> Why not just stay in PHP 7.x?
>>
>> Because other features that I want to utilize will also be added in PHP
> 8.
>
> I think it's all up to you to decide if those features you need would be
worth it moving to PHP 8(perhaps helping you clean up some codes i would
seem as bad practice IMO) or those features are not worth cleaning up for(
then  you can stay on PHP 7, even 5 for as long as you wan to)...

In all of these, those who would upgrade would do so and those who won't
would never upgrade coz they don't see good reasons to or such codes are
not more in maintenance...

> Or were you implying you want hitch-free, no-modification upgrade to PHP 8
>> from PHP 7.0?
>>
>
> I never said that. Here we go again with the "I guess you are against all
> BC breaks" nonsense. If BC breaks are required to add new functionality,
> or, have a very minimal negative impact, then I don't have a problem with
> them. This is not one of those cases. It changes a fundamental aspect of
> the language, an aspect that many people actually like, and it doesn't add
> any new features to the language, nor is it needed to add any new features
> to the language.
>
>
>> If yes, follow the best practices and not suppress error notices.
>>
>> Just My Opinion
>>
>
>
> --
> Chase Peeler
> 

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson  wrote:

> On Thu, Sep 12, 2019 at 8:11 PM Michael Babker 
> 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 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.
> >>> >
> >>>
> >>> Please don't tie the notion of LTS with the idea that a new major can
> >>> break
> >>> BC at will or create larger scale breaks because the previous major has
> >>> extended support.  Sooner or later that will end up back at the ++ idea
> >>> and
> >>> fragmentation encouraged by the language is a bad idea.
> >>>
> >>
> >> Not sure you are really seeing the goal...
> >>
> >> Why is LTS not a good idea?
> >>
> >
> > I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
> > shipping larger scale BC breaks, such as the changes suggested in the
> last
> > couple of "contentious" RFCs in a major version because "hey, we have a
> LTS
> > version you can use that until you're ready to deal with the backlog of
> BC
> > breaks created" is a bad idea.
> >
>
>
> > For the record, I happen to agree with as these RFCs would have minimal
> > impact on my day-to-day work, but having also been in the role of a
> > maintainer of open source libraries and applications I also grasp why
> these
> > types of changes can be problematic to the ecosystem (both end users of
> > those libraries and applications and the maintainers of them) and
> wouldn't
> > jump the gun to ship them without careful consideration.
> >
>
> Most of these changes wouldn't have been problematic to you if the language
> has prevented you from writing what we can now consider bad code, so please
> allow the new PHP developer that newly start using PHP to not follow that
> your path that will/might hunt him later in the future...
>
>
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.


> There a notices, warning and errors to inform you that this shouldn't have
> been the use case of this feature and you chose to ignore it and now, we
> are simplifying things and making those your errors teach you how to write
> proper codes in the future, you're objecting..


As has been discussed before, notices are not the same as warnings and
errors.  Also, if those things are so wonderful, why can't you use them to
catch the issues you are complaining you can't catch right now? Again, you
are telling me there is something out there which will allow you to force
yourself to write "good code" without forcing me to follow the same
restrictions. Yet, you still feel it's necessary to not use those tools,
and instead modify the entire language so that I am forced to follow what
you deem best practices, even if I don't?



> Why not just stay in PHP 7.x?
>
> Because other features that I want to utilize will also be added in PHP
8.

Or were you implying you want hitch-free, no-modification upgrade to PHP 8
> from PHP 7.0?
>

I never said that. Here we go again with the "I guess you are against all
BC breaks" nonsense. If BC breaks are required to add new functionality,
or, have a very minimal negative impact, then I don't have a problem with
them. This is not one of those cases. It changes a fundamental aspect of
the language, an aspect that many people actually like, and it doesn't add
any new features to the language, nor is it needed to add any new features
to the language.


> If yes, follow the best practices and not suppress error notices.
>
> Just My Opinion
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Michael Babker]

On Thu, Sep 12, 2019 at 2:17 PM Olumide Samson  wrote:

> Most of these changes wouldn't have been problematic to you if the
> language has prevented you from writing what we can now consider bad code,
> so please allow the new PHP developer that newly start using PHP to not
> follow that your path that will/might hunt him later in the future...
>
> There a notices, warning and errors to inform you that this shouldn't have
> been the use case of this feature and you chose to ignore it and now, we
> are simplifying things and making those your errors teach you how to write
> proper codes in the future, you're objecting.. Why not just stay in PHP 7.x?
>
> Or were you implying you want hitch-free, no-modification upgrade to PHP 8
> from PHP 7.0?
> If yes, follow the best practices and not suppress error notices.
>

We're clearly talking past one another so I will be going back to work
after this response.

I am not saying anything about whether the warnings RFC should pass or
fail, or if it makes my code good or bad.  I responded explicitly to one
idea about creating a LTS version that might somehow make it easier for
RFCs like this one to be accepted because users could basically be
encouraged to stay on the LTS version if the new major version introduces
too many breaking changes, which I think is bad justification for creating
a LTS version.  I'm not sure how that equates to my code being good or bad
or whether I am following someone else's recommended best practices, but
that was never the point of discussion.

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

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

>
>
> On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson 
> wrote:
>
>> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 
>> 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 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.
>> > >
>> >
>> > Please don't tie the notion of LTS with the idea that a new major can
>> break
>> > BC at will or create larger scale breaks because the previous major has
>> > extended support.  Sooner or later that will end up back at the ++ idea
>> and
>> > fragmentation encouraged by the language is a bad idea.
>> >
>>
>> Not sure you are really seeing the goal...
>>
>> Why is LTS not a good idea?
>> And, if the majority want this or that, can we just blow everything into
>> full dictatorship where i can host my fork of PHP doing uncountable
>> unwanted things i can call it..?
>>
>> Any which way, i think the majority of us are tired of writing bad codes,
>> but since the language is allowing it we don't have choices than to spend
>> some hours or weeks later debugging the wrong or right line we did that
>> last "big mistake", who knows there might be another line smiling coz i
>> haven't detected it...
>>
>
> I can write good code without sacrificing the flexibility provided by PHP.
> Don't force ME to write code a specific way because you aren't disciplined
> enough to not write bad code without the compiler forcing you to do things
> a certain way.
>
> Of all of the justifications for this RFC I've heard, "I can't stop
> writing bad code as long as I'm allowed to" has to be the worst.
>
> Yea, that's just one of the popular reasons, there are more if you go on
Stack Overflow and see what this dynamism(my foot) has caused to real-world
codes and fortunes that has been lost due to it(Which i'm also a testimony
to the fact).

> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 8:11 PM Michael Babker 
wrote:

> On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson 
> wrote:
>
>> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 
>> 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 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.
>>> >
>>>
>>> Please don't tie the notion of LTS with the idea that a new major can
>>> break
>>> BC at will or create larger scale breaks because the previous major has
>>> extended support.  Sooner or later that will end up back at the ++ idea
>>> and
>>> fragmentation encouraged by the language is a bad idea.
>>>
>>
>> Not sure you are really seeing the goal...
>>
>> Why is LTS not a good idea?
>>
>
> I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
> shipping larger scale BC breaks, such as the changes suggested in the last
> couple of "contentious" RFCs in a major version because "hey, we have a LTS
> version you can use that until you're ready to deal with the backlog of BC
> breaks created" is a bad idea.
>


> For the record, I happen to agree with as these RFCs would have minimal
> impact on my day-to-day work, but having also been in the role of a
> maintainer of open source libraries and applications I also grasp why these
> types of changes can be problematic to the ecosystem (both end users of
> those libraries and applications and the maintainers of them) and wouldn't
> jump the gun to ship them without careful consideration.
>

Most of these changes wouldn't have been problematic to you if the language
has prevented you from writing what we can now consider bad code, so please
allow the new PHP developer that newly start using PHP to not follow that
your path that will/might hunt him later in the future...

There a notices, warning and errors to inform you that this shouldn't have
been the use case of this feature and you chose to ignore it and now, we
are simplifying things and making those your errors teach you how to write
proper codes in the future, you're objecting.. Why not just stay in PHP 7.x?

Or were you implying you want hitch-free, no-modification upgrade to PHP 8
from PHP 7.0?
If yes, follow the best practices and not suppress error notices.

Just My Opinion

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson  wrote:

> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 
> 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 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.
> > >
> >
> > Please don't tie the notion of LTS with the idea that a new major can
> break
> > BC at will or create larger scale breaks because the previous major has
> > extended support.  Sooner or later that will end up back at the ++ idea
> and
> > fragmentation encouraged by the language is a bad idea.
> >
>
> Not sure you are really seeing the goal...
>
> Why is LTS not a good idea?
> And, if the majority want this or that, can we just blow everything into
> full dictatorship where i can host my fork of PHP doing uncountable
> unwanted things i can call it..?
>
> Any which way, i think the majority of us are tired of writing bad codes,
> but since the language is allowing it we don't have choices than to spend
> some hours or weeks later debugging the wrong or right line we did that
> last "big mistake", who knows there might be another line smiling coz i
> haven't detected it...
>

I can write good code without sacrificing the flexibility provided by PHP.
Don't force ME to write code a specific way because you aren't disciplined
enough to not write bad code without the compiler forcing you to do things
a certain way.

Of all of the justifications for this RFC I've heard, "I can't stop writing
bad code as long as I'm allowed to" has to be the worst.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Michael Babker]

On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson  wrote:

> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 
> 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 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.
>> >
>>
>> Please don't tie the notion of LTS with the idea that a new major can
>> break
>> BC at will or create larger scale breaks because the previous major has
>> extended support.  Sooner or later that will end up back at the ++ idea
>> and
>> fragmentation encouraged by the language is a bad idea.
>>
>
> Not sure you are really seeing the goal...
>
> Why is LTS not a good idea?
>

I'm not saying LTS is a bad idea.  I'm saying using LTS to justify shipping
larger scale BC breaks, such as the changes suggested in the last couple of
"contentious" RFCs in a major version because "hey, we have a LTS version
you can use that until you're ready to deal with the backlog of BC breaks
created" is a bad idea. For the record, I happen to agree with as these
RFCs would have minimal impact on my day-to-day work, but having also been
in the role of a maintainer of open source libraries and applications I
also grasp why these types of changes can be problematic to the ecosystem
(both end users of those libraries and applications and the maintainers of
them) and wouldn't jump the gun to ship them without careful consideration.

>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 8:00 PM Michael Babker 
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 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.
> >
>
> Please don't tie the notion of LTS with the idea that a new major can break
> BC at will or create larger scale breaks because the previous major has
> extended support.  Sooner or later that will end up back at the ++ idea and
> fragmentation encouraged by the language is a bad idea.
>

Not sure you are really seeing the goal...

Why is LTS not a good idea?
And, if the majority want this or that, can we just blow everything into
full dictatorship where i can host my fork of PHP doing uncountable
unwanted things i can call it..?

Any which way, i think the majority of us are tired of writing bad codes,
but since the language is allowing it we don't have choices than to spend
some hours or weeks later debugging the wrong or right line we did that
last "big mistake", who knows there might be another line smiling coz i
haven't detected it...

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 2:35 PM Zeev Suraski  wrote:

> On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl  wrote:
>
> >
> >
> > > You may be wondering, in that case, what processes do we have to deal
> > with
> > > such changes then?  The answer is simple.  We don't.  We don't have to
> > have
> > > them either - the fundamental language behaviors are here to stay.
> >
> > But we still need processes to define which are the "fundamental
> > language behaviours". And as change is the only constant in
> > software-development, these "fundamental language behaviours" might, can
> > and probably should be changeable. I'm not saying they need to change,
> > but it has to be possible to change them. Otherwise we would still
> > program business-logic in C as that was Rasmus' fundamental idea IIRC
> > (Correct me if I'm wrong)
> >
>
> You're right.  The thing is this - as I said, the RFC process was designed
> to address additions to the language - as is implied in numerous places
> (both the part I quoted from the RFC itself, as well as elements in RFC
> template as well as the RFC howto).  It was never meant to handle
> deprecations - mainly because we simply weren't doing much of that back in
> the days where it was introduced.  It was meant to resolve the issue at
> hand at the time (and in the years leading up to it) - which is a formal
> way to agree on which features make it in and which ones don't.
> Now, over the years (and more and more as of late) - it started being used
> for deprecations.  But these deprecations have become more and more extreme
> recently in terms of their impact.  Of course I do think deprecations
> should be allowed, like in any other language.  I do think we need to have
> a higher bar for them in general (both in terms of a clear benefits and
> required majority - as is implied in the Voting RFC) - but since we've
> grown used to using 2/3 for them - and given the pro-deprecation bias of
> the current composition of internals@ - I also realize it will be tough to
> do.  But when dealing with deprecation proposals that are likely to effect
> a very sizable subset of our userbase and codebase, and deal with some of
> the most basic building blocks of the language - we simply can't start
> using the same process.  We never have in the past (none of the
> deprecations we voted on since 2013 comes even remotely close to the level
> of impact of the two proposals that have been put forward to a vote in the
> recent couple of months, and the more recent one clearly far outdoes the
> prior one in terms of impact).
>
> Should we have 'woken up' many years ago when we started using the Voting
> RFC for deprecations it wasn't meant to handle?  Probably.  It would have
> been much easier to install a new mechanism.  But it doesn't mean we should
> repeat the same mistake, now that it begins to be used to deprecate
> mainstream language behaviors.
>
> In terms of telling one from the other - right now, I'm afraid it's a bit
> like some other things that fall into the category of 'you know it when you
> see it'.  I think few can deny that far-reaching effect of changing how
> variables behave in a language, whether they think it's a change for the
> better or for the worse.  But I think it *may* be possible to formally
> define.  These are just random thoughts at this point - but we could have a
> set of apps/frameworks that we use as a testing bed to check the level of
> impact of a certain proposal.  If that impact is above a certain threshold
> - it will be considered fundamental.  Of course, things like WordPress,
> Joomla and MediaWiki would have to be a part of that - not just modern
> frameworks.  It's still not ideal since it doesn't account for the majority
> of PHP code out there which isn't Open Source - but it may be a start.
> There may be other ways - such as letting folks run that analysis on their
> own code behind the firewall and report results back.
>
> But there's also a simpler solution to this.  This 'can of worms' as Arvids
> called it, wouldn't have been opened had we agreed to focus on extending
> PHP instead of trying to replace it with something else.  This is what the
> RFC process was meant to facilitate.  It still can, but for that, we need
> to change the dynamics from a zero-sum game to a goal of a win/win.  Yes, I
> realize that I'm sounding like a broken record.  But call me naive - I'm
> still hoping that given it obviously can be done from a technical
> perspective (in a wide variety of ways too) - we can find the good will to
> do it from a human perspective.
>
>
Exactly. I think it's telling that the majority of the rebuttals to
arguments against the RFC are to claim that we're against moving the
language forward, against BC breaks, etc. That couldn't be further from the
truth. We do want to move the language forward. We want do that by adding
to the language, and not changing it into an entirely different language.


> Zeev
>
>
> >
>


-- 
Chase Peeler

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 2:51 PM Peter Kokot  wrote:

> On Thu, 12 Sep 2019 at 20:35, Zeev Suraski  wrote:
> >
> > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl  wrote:
> >
> > >
> > >
> > > > You may be wondering, in that case, what processes do we have to deal
> > > with
> > > > such changes then?  The answer is simple.  We don't.  We don't have
> to
> > > have
> > > > them either - the fundamental language behaviors are here to stay.
> > >
> > > But we still need processes to define which are the "fundamental
> > > language behaviours". And as change is the only constant in
> > > software-development, these "fundamental language behaviours" might,
> can
> > > and probably should be changeable. I'm not saying they need to change,
> > > but it has to be possible to change them. Otherwise we would still
> > > program business-logic in C as that was Rasmus' fundamental idea IIRC
> > > (Correct me if I'm wrong)
> > >
> >
> > You're right.  The thing is this - as I said, the RFC process was
> designed
> > to address additions to the language - as is implied in numerous places
> > (both the part I quoted from the RFC itself, as well as elements in RFC
> > template as well as the RFC howto).  It was never meant to handle
> > deprecations - mainly because we simply weren't doing much of that back
> in
> > the days where it was introduced.  It was meant to resolve the issue at
> > hand at the time (and in the years leading up to it) - which is a formal
> > way to agree on which features make it in and which ones don't.
> > Now, over the years (and more and more as of late) - it started being
> used
> > for deprecations.  But these deprecations have become more and more
> extreme
> > recently in terms of their impact.  Of course I do think deprecations
> > should be allowed, like in any other language.  I do think we need to
> have
> > a higher bar for them in general (both in terms of a clear benefits and
> > required majority - as is implied in the Voting RFC) - but since we've
> > grown used to using 2/3 for them - and given the pro-deprecation bias of
> > the current composition of internals@ - I also realize it will be tough
> to
> > do.  But when dealing with deprecation proposals that are likely to
> effect
> > a very sizable subset of our userbase and codebase, and deal with some of
> > the most basic building blocks of the language - we simply can't start
> > using the same process.  We never have in the past (none of the
> > deprecations we voted on since 2013 comes even remotely close to the
> level
> > of impact of the two proposals that have been put forward to a vote in
> the
> > recent couple of months, and the more recent one clearly far outdoes the
> > prior one in terms of impact).
> >
> > Should we have 'woken up' many years ago when we started using the Voting
> > RFC for deprecations it wasn't meant to handle?  Probably.  It would have
> > been much easier to install a new mechanism.  But it doesn't mean we
> should
> > repeat the same mistake, now that it begins to be used to deprecate
> > mainstream language behaviors.
> >
> > In terms of telling one from the other - right now, I'm afraid it's a bit
> > like some other things that fall into the category of 'you know it when
> you
> > see it'.  I think few can deny that far-reaching effect of changing how
> > variables behave in a language, whether they think it's a change for the
> > better or for the worse.  But I think it *may* be possible to formally
> > define.  These are just random thoughts at this point - but we could
> have a
> > set of apps/frameworks that we use as a testing bed to check the level of
> > impact of a certain proposal.  If that impact is above a certain
> threshold
> > - it will be considered fundamental.  Of course, things like WordPress,
> > Joomla and MediaWiki would have to be a part of that - not just modern
> > frameworks.  It's still not ideal since it doesn't account for the
> majority
> > of PHP code out there which isn't Open Source - but it may be a start.
> > There may be other ways - such as letting folks run that analysis on
> their
> > own code behind the firewall and report results back.
> >
> > But there's also a simpler solution to this.  This 'can of worms' as
> Arvids
> > called it, wouldn't have been opened had we agreed to focus on extending
> > PHP instead of trying to replace it with something else.  This is what
> the
> > RFC process was meant to facilitate.  It still can, but for that, we need
> > to change the dynamics from a zero-sum game to a goal of a win/win.
> Yes, I
> > realize that I'm sounding like a broken record.  But call me naive - I'm
> > still hoping that given it obviously can be done from a technical
> > perspective (in a wide variety of ways too) - we can find the good will
> to
> > do it from a human perspective.
> >
> > Zeev
> >
> >
> > >
>
> Just a dumb idea, since there clearly is a majority in favor of the
> change with these warnings and strictness and all that now... 

Re: [PHP-DEV] Changing fundamental language behaviors

[Michael Babker]

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 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.
>

Please don't tie the notion of LTS with the idea that a new major can break
BC at will or create larger scale breaks because the previous major has
extended support.  Sooner or later that will end up back at the ++ idea and
fragmentation encouraged by the language is a bad idea.

Re: [PHP-DEV] Changing fundamental language behaviors

[Peter Kokot]

On Thu, 12 Sep 2019 at 20:35, Zeev Suraski  wrote:
>
> On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl  wrote:
>
> >
> >
> > > You may be wondering, in that case, what processes do we have to deal
> > with
> > > such changes then?  The answer is simple.  We don't.  We don't have to
> > have
> > > them either - the fundamental language behaviors are here to stay.
> >
> > But we still need processes to define which are the "fundamental
> > language behaviours". And as change is the only constant in
> > software-development, these "fundamental language behaviours" might, can
> > and probably should be changeable. I'm not saying they need to change,
> > but it has to be possible to change them. Otherwise we would still
> > program business-logic in C as that was Rasmus' fundamental idea IIRC
> > (Correct me if I'm wrong)
> >
>
> You're right.  The thing is this - as I said, the RFC process was designed
> to address additions to the language - as is implied in numerous places
> (both the part I quoted from the RFC itself, as well as elements in RFC
> template as well as the RFC howto).  It was never meant to handle
> deprecations - mainly because we simply weren't doing much of that back in
> the days where it was introduced.  It was meant to resolve the issue at
> hand at the time (and in the years leading up to it) - which is a formal
> way to agree on which features make it in and which ones don't.
> Now, over the years (and more and more as of late) - it started being used
> for deprecations.  But these deprecations have become more and more extreme
> recently in terms of their impact.  Of course I do think deprecations
> should be allowed, like in any other language.  I do think we need to have
> a higher bar for them in general (both in terms of a clear benefits and
> required majority - as is implied in the Voting RFC) - but since we've
> grown used to using 2/3 for them - and given the pro-deprecation bias of
> the current composition of internals@ - I also realize it will be tough to
> do.  But when dealing with deprecation proposals that are likely to effect
> a very sizable subset of our userbase and codebase, and deal with some of
> the most basic building blocks of the language - we simply can't start
> using the same process.  We never have in the past (none of the
> deprecations we voted on since 2013 comes even remotely close to the level
> of impact of the two proposals that have been put forward to a vote in the
> recent couple of months, and the more recent one clearly far outdoes the
> prior one in terms of impact).
>
> Should we have 'woken up' many years ago when we started using the Voting
> RFC for deprecations it wasn't meant to handle?  Probably.  It would have
> been much easier to install a new mechanism.  But it doesn't mean we should
> repeat the same mistake, now that it begins to be used to deprecate
> mainstream language behaviors.
>
> In terms of telling one from the other - right now, I'm afraid it's a bit
> like some other things that fall into the category of 'you know it when you
> see it'.  I think few can deny that far-reaching effect of changing how
> variables behave in a language, whether they think it's a change for the
> better or for the worse.  But I think it *may* be possible to formally
> define.  These are just random thoughts at this point - but we could have a
> set of apps/frameworks that we use as a testing bed to check the level of
> impact of a certain proposal.  If that impact is above a certain threshold
> - it will be considered fundamental.  Of course, things like WordPress,
> Joomla and MediaWiki would have to be a part of that - not just modern
> frameworks.  It's still not ideal since it doesn't account for the majority
> of PHP code out there which isn't Open Source - but it may be a start.
> There may be other ways - such as letting folks run that analysis on their
> own code behind the firewall and report results back.
>
> But there's also a simpler solution to this.  This 'can of worms' as Arvids
> called it, wouldn't have been opened had we agreed to focus on extending
> PHP instead of trying to replace it with something else.  This is what the
> RFC process was meant to facilitate.  It still can, but for that, we need
> to change the dynamics from a zero-sum game to a goal of a win/win.  Yes, I
> realize that I'm sounding like a broken record.  But call me naive - I'm
> still hoping that given it obviously can be done from a technical
> perspective (in a wide variety of ways too) - we can find the good will to
> do it from a human perspective.
>
> Zeev
>
>
> >

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 

Re: [PHP-DEV] Changing fundamental language behaviors

[Zeev Suraski]

On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl  wrote:

>
>
> > You may be wondering, in that case, what processes do we have to deal
> with
> > such changes then?  The answer is simple.  We don't.  We don't have to
> have
> > them either - the fundamental language behaviors are here to stay.
>
> But we still need processes to define which are the "fundamental
> language behaviours". And as change is the only constant in
> software-development, these "fundamental language behaviours" might, can
> and probably should be changeable. I'm not saying they need to change,
> but it has to be possible to change them. Otherwise we would still
> program business-logic in C as that was Rasmus' fundamental idea IIRC
> (Correct me if I'm wrong)
>

You're right.  The thing is this - as I said, the RFC process was designed
to address additions to the language - as is implied in numerous places
(both the part I quoted from the RFC itself, as well as elements in RFC
template as well as the RFC howto).  It was never meant to handle
deprecations - mainly because we simply weren't doing much of that back in
the days where it was introduced.  It was meant to resolve the issue at
hand at the time (and in the years leading up to it) - which is a formal
way to agree on which features make it in and which ones don't.
Now, over the years (and more and more as of late) - it started being used
for deprecations.  But these deprecations have become more and more extreme
recently in terms of their impact.  Of course I do think deprecations
should be allowed, like in any other language.  I do think we need to have
a higher bar for them in general (both in terms of a clear benefits and
required majority - as is implied in the Voting RFC) - but since we've
grown used to using 2/3 for them - and given the pro-deprecation bias of
the current composition of internals@ - I also realize it will be tough to
do.  But when dealing with deprecation proposals that are likely to effect
a very sizable subset of our userbase and codebase, and deal with some of
the most basic building blocks of the language - we simply can't start
using the same process.  We never have in the past (none of the
deprecations we voted on since 2013 comes even remotely close to the level
of impact of the two proposals that have been put forward to a vote in the
recent couple of months, and the more recent one clearly far outdoes the
prior one in terms of impact).

Should we have 'woken up' many years ago when we started using the Voting
RFC for deprecations it wasn't meant to handle?  Probably.  It would have
been much easier to install a new mechanism.  But it doesn't mean we should
repeat the same mistake, now that it begins to be used to deprecate
mainstream language behaviors.

In terms of telling one from the other - right now, I'm afraid it's a bit
like some other things that fall into the category of 'you know it when you
see it'.  I think few can deny that far-reaching effect of changing how
variables behave in a language, whether they think it's a change for the
better or for the worse.  But I think it *may* be possible to formally
define.  These are just random thoughts at this point - but we could have a
set of apps/frameworks that we use as a testing bed to check the level of
impact of a certain proposal.  If that impact is above a certain threshold
- it will be considered fundamental.  Of course, things like WordPress,
Joomla and MediaWiki would have to be a part of that - not just modern
frameworks.  It's still not ideal since it doesn't account for the majority
of PHP code out there which isn't Open Source - but it may be a start.
There may be other ways - such as letting folks run that analysis on their
own code behind the firewall and report results back.

But there's also a simpler solution to this.  This 'can of worms' as Arvids
called it, wouldn't have been opened had we agreed to focus on extending
PHP instead of trying to replace it with something else.  This is what the
RFC process was meant to facilitate.  It still can, but for that, we need
to change the dynamics from a zero-sum game to a goal of a win/win.  Yes, I
realize that I'm sounding like a broken record.  But call me naive - I'm
still hoping that given it obviously can be done from a technical
perspective (in a wide variety of ways too) - we can find the good will to
do it from a human perspective.

Zeev


>

Re: [PHP-DEV] Changing fundamental language behaviors

[Andreas Hennings]

Indeed, for the case of local variables that were undefined before,
this can usually be fixed in a straightforward way by initializing to
NULL.
The goal here is to get rid of the error or notice while preserving
the original behavior (even if it was buggy).

This is IF this is your own custom code, or you have a strategy for
maintaining patches on 3rd party code. (which you probably should).

Another problem which has not been talked about much is code like
this, which I have seen in multiple legacy code bases for Drupal 7
projects. Code like this is not considered good practice in Drupal 7,
but it does exist.

  
$element['field_category'][LANGUAGE_NONE][0]['#entity']->field_author_label['en'][0]['value'];

This is crying for "trying to access property of non-object". Because
the values in $element were usually created "elsewhere", and who knows
if the value at that position is an object?

Even worse: This might go unnoticed 99% of the time, but in a specific
edge case the value might not be initialized and the website would
crash with error in PHP8.

The "minimal fix" to preserve behavior 1:1 is to call if (isset()) or
if (!empty()) on the whole thing before every such construct, even if
at the moment you are not aware of cases where it might fail. In the
"else" case, you do whatever would have happened before if the value
was NULL.

On Thu, 12 Sep 2019 at 20:10, 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.
>
> Regards,
> Lynn van der Berg

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Matthew Brown]

I'm sure that some people wrote code like this, expecting it to always work
in PHP:

if ($some_condition) define("HELLO", 0);
if (HELLO) { var_dump("got here"); }

The equivalent, relying on buggy behaviour, PHP code looks like

if ($some_condition) $hello = 1;
if (!$hello) { var_dump("got here"); }

If preventing undefined constants wasn't a fundamental change to the
language, neither is preventing undefined variables.

>

Re: [PHP-DEV] Changing fundamental language behaviors

[Stephen Reay]

> On 13 Sep 2019, at 01:07, Chase Peeler  wrote:
> 
> 
> 
> On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay  wrote:
> 
> > On 13 Sep 2019, at 00:41, Chase Peeler  wrote:
> > 
> > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown 
> > wrote:
> > 
> >> What if Java suddenly said that all properties are suddenly private, and
> >>> can only be accessed through getter/setter methods?
> >>> 
> >> 
> >> If Java announced that the next major version was to make the change after
> >> 95% of userland developers favoured it and over 2/3rds of their internals
> >> team did, I'd think "huh ok I guess they have good reasons".
> >> 
> >> For 20 years people have developed code based on that feature. It was
> >>> never considered an error, and often not even considered bad practice
> >> 
> >> 
> >> You seem to be arguing against *ever* changing something that a majority
> >> once thought was good, and fundamental to a given system. Lots of things
> >> fall into that category - restricting voting to men, segregation, etc.
> >> 
> > 
> > Now you're just being silly. I actually don't have a problem with
> > fundamental language change, provided that the positives that are gained
> > far outweigh the negatives of the BC break and there is no other way to
> > accomplish those positives without such a BC break.
> > 
> > There are a myriad of ways to achieve what the RFC attempts to achieve.
> > Whether that's analysis tools, custom error handlers, detailed code
> > reviews, etc. Nothing prevents anyone from initializing all of their
> > variables or performing as many sanity checks on a variable before
> > accessing it as they want to. Nothing in the RFC is required to implement
> > other new functionality like enums, union types, variable typing, etc.
> > 
> > I also think it's a bit of a stretch to compare something like variable
> > initialization with things that denied people their basic human rights.
> > 
> > -- 
> > Chase Peeler
> > chasepee...@gmail.com
> 
> 
> Please, will someone arguing against making use of undefined variables a 
> higher severity, explain to me why the same argument was not made for use of 
> undefined constants, for which the RFC to deprecate/remove support, passed 
> 41:0.
> 
> How is one undefined symbol more acceptable than another undefined symbol?
> 
> First of all, I wasn't as involved with this list back then as I was now. 
> However, I can see a fundamental difference in the two. Not needing to 
> initialize variables just for the sake of initializing them (e.g. just doing 
> $i++ without $i=0 before it) is something that is going to behave as expected 
> almost all of the time. When it doesn't, you can easily initialize $i to a 
> non-zero value, or, you can initialize it to zero if you want - it doesn't 
> hurt anything.
> 
> An undefined constant getting converted to a string, though, is much less 
> likely to be the intended behavior. String literals are required to be in 
> quotes. Constants can never be in quotes. Assuming that the token that looks 
> like a constant, but can't be because the constant didn't exist, so, we'll 
> pretend it's a string even though it doesn't match the proper syntax for such 
> a token is drastically different than assuming the variable you are 
> incrementing that wasn't initialized is 0, or, that the variable you are 
> concatenating to, but wasn't initialized, is an empty string. 
> 
> Finally, let's pretend that the undefined constants RFC was a horrible RFC 
> that shouldn't have passed. The fact that it did has no impact on whether or 
> not this RFC should pass. 
> 
> -- 
> Chase Peeler
> chasepee...@gmail.com


Apologies if you thought I was specifically replying to you Chase, I simply hit 
reply-all to the last message I had.


The RFC I referred to explicitly describes the use-case for the (mis-)feature 
it removed:

> The current behaviour appears to have been added as an attempt to guess the 
> user's intention, and continue gracefully.

Sounds familiar, doesn’t it? “If I write $foo++ and $foo is undefined, it 
should know what I mean”.

> The value of keeping the current behaviour would be for programs written to 
> deliberately take advantage of it. In particular, I have seen sample code of 
> the form $_GET[bar] where bar is taken to be the string key bar. 

So, it clearly was (ab)used.


IMO this also flies in the face of the “we can’t change behaviour” argument - 
bare word strings were added around 20 years ago, and yet not a single person 
thought it worthwhile voting against the deprecation and removal of this 
behaviour?

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

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

[Olumide Samson]

On Thu, Sep 12, 2019 at 7: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.
>
> even without a statistics to back the word is plainfully meaningless...

I guess we tend to use the word "HUGELY","NEVER","EVER","COMPANY", etc
wrongly on the list just to prove some points.

And, we're better off than that IMO...

> Regards,
> Lynn van der Berg
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 1:58 PM Olumide Samson  wrote:

>
>
> On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler 
> wrote:
>
>> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown 
>> wrote:
>>
>> > What if Java suddenly said that all properties are suddenly private, and
>> >> can only be accessed through getter/setter methods?
>> >>
>> >
>> > If Java announced that the next major version was to make the change
>> after
>> > 95% of userland developers favoured it and over 2/3rds of their
>> internals
>> > team did, I'd think "huh ok I guess they have good reasons".
>> >
>> >
>> I call shenanigans on that 95% number. Can you please back that up?
>> Personally, I don't think it's even possible to gauge userland
>> support because the vast majority of userland developers aren't involved
>> in
>> the community at all. Those people don't even know this is being
>> discussed,
>> and probably won't until they start looking to upgrade to PHP 8.
>>
>> I'm sure you need to read the message properly before replying, he ain't
> talking about PHP there...
>
> Even 95% can be called anything(of users who are involved in the
> community, who knows, who are actual users, etc)
>
>>
>>
No, I think you misunderstood. I said "What if Java did XYZ" - The reply
was "If 95% of userland Java developers supported such a change..." That
implies that 95% of userland PHP developers support the changes in the RFC.

It wouldn't make sense to say "Well, if 95% of Java userland developers
supported the change, then it would make sense, just like we should pass
this RFC that 45% of PHP userland developers support"


> > For 20 years people have developed code based on that feature. It was
>> >> never considered an error, and often not even considered bad practice
>> >
>> >
>> > You seem to be arguing against *ever* changing something that a majority
>> > once thought was good, and fundamental to a given system. Lots of things
>> > fall into that category - restricting voting to men, segregation, etc.
>> >
>> >>
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Lynn]

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.

Regards,
Lynn van der Berg

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 2:07 PM Olumide Samson  wrote:

> I think it would do this list more good than not, if we talk or assume
> about some people who will ever or never upgrade...
> Seriously?
> How do you know if they would never or ever upgrade, you can only and
> should probably speak for yourself...
>
> If they want more customers(translating to revenue), they can upgrade and
> if they don't it's all up to them...
>
> On Thu, Sep 12, 2019 at 6:59 PM Mike Schinkel  wrote:
>
> > > On Sep 12, 2019, at 10:37 AM, Lynn  wrote:
> > >
> > > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler 
> > wrote:
> > >
> > >> There are valid reasons for not always initializing variables or array
> > >> keys. It might be a bad
> > >> reason in your opinion, but others view it as perfectly acceptable.
> > >>
> > >
> > > I recently had to fix a bug where a variable was renamed, caused a
> merge
> > > conflict and resulted in months long of changing a business process
> with
> > a
> > > subtle bug, as null was not the intended initialized value. Whether or
> > not
> > > people should initialize variables is debatable from a programming
> > > perspective. From a reader's perspective it's really important to have
> > > variables initialized with a default value, even if it's just null, to
> > > prevent missing certain assignment branches and avoid bugs. From my
> > > perspective, this should've thrown an error, so we would've fixed it
> the
> > > same day. Now PHP simply broke our business process for months.
> > >
> > > Yes, we hide notices, even in production as our logging server would
> die
> > > within a minute if we'd turn it on. Yes, this is a massive legacy code
> > base
> > > where lots of tests are lacking. Can we change this? Sure, will take
> > years
> > > though. Would we have benefited from PHP throwing an error in this
> case?
> > > Most certainly, would've saved us a lot of headache, and money.
> > >
> > > You argue that it's a fundamental language change, I -and seemingly a
> lot
> > > of others- argue that this is more of a bug fix.
> >
> > 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.
> >
> I think they could switch to using null instead, or perhaps get something
> else to differentiate what they have initialized or not, 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..
>
>
Can you please stop speaking for what you think they should do? Only they
can speak for what they should do.


> If PHP8 were to change to require variables and/or array elements to be
> > initialized then this code base and any similar to it will be broken.
> > Companies with these code bases almost certainly will simply not upgrade
> to
> > PHP 8.  Probably ever.
> >
> > 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"?
>
>
> > BTW, prior to gaining this company as a client, the internal people felt
> > that the codebase needed to be completely rewritten rather than
> > incrementally refactored. And because rewriting would have been such a
> > large project they have been putting it off for several years.  In their
> > case, we will be cleaning up the code base (although doing so will be
> very
> > costly for them.)
> >
> > And I estimate there are a large number of similar scenarios in the wild
> > that do not currently have plans the people or the funds to clean up
> their
> > similar code.
> >
> > It's up to them, PHP 7 is still available and will always be available
> for
> them to use...
>
>
Yes, but, there are going to be other features in PHP 8 that won't break
existing code and are beneficial. They may be forced to stick with PHP 7,
but don't act like that is a perfectly acceptable option without any
downsides.


> > #jmtcw
> >
> > -Mike
> >
> >
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

I think it would do this list more good than not, if we talk or assume
about some people who will ever or never upgrade...
Seriously?
How do you know if they would never or ever upgrade, you can only and
should probably speak for yourself...

If they want more customers(translating to revenue), they can upgrade and
if they don't it's all up to them...

On Thu, Sep 12, 2019 at 6:59 PM Mike Schinkel  wrote:

> > On Sep 12, 2019, at 10:37 AM, Lynn  wrote:
> >
> > On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler 
> wrote:
> >
> >> There are valid reasons for not always initializing variables or array
> >> keys. It might be a bad
> >> reason in your opinion, but others view it as perfectly acceptable.
> >>
> >
> > I recently had to fix a bug where a variable was renamed, caused a merge
> > conflict and resulted in months long of changing a business process with
> a
> > subtle bug, as null was not the intended initialized value. Whether or
> not
> > people should initialize variables is debatable from a programming
> > perspective. From a reader's perspective it's really important to have
> > variables initialized with a default value, even if it's just null, to
> > prevent missing certain assignment branches and avoid bugs. From my
> > perspective, this should've thrown an error, so we would've fixed it the
> > same day. Now PHP simply broke our business process for months.
> >
> > Yes, we hide notices, even in production as our logging server would die
> > within a minute if we'd turn it on. Yes, this is a massive legacy code
> base
> > where lots of tests are lacking. Can we change this? Sure, will take
> years
> > though. Would we have benefited from PHP throwing an error in this case?
> > Most certainly, would've saved us a lot of headache, and money.
> >
> > You argue that it's a fundamental language change, I -and seemingly a lot
> > of others- argue that this is more of a bug fix.
>
> 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.
>
I think they could switch to using null instead, or perhaps get something
else to differentiate what they have initialized or not, 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..

If PHP8 were to change to require variables and/or array elements to be
> initialized then this code base and any similar to it will be broken.
> Companies with these code bases almost certainly will simply not upgrade to
> PHP 8.  Probably ever.
>
> 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"?


> BTW, prior to gaining this company as a client, the internal people felt
> that the codebase needed to be completely rewritten rather than
> incrementally refactored. And because rewriting would have been such a
> large project they have been putting it off for several years.  In their
> case, we will be cleaning up the code base (although doing so will be very
> costly for them.)
>
> And I estimate there are a large number of similar scenarios in the wild
> that do not currently have plans the people or the funds to clean up their
> similar code.
>
> It's up to them, PHP 7 is still available and will always be available for
them to use...

> #jmtcw
>
> -Mike
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay 
wrote:

>
> > On 13 Sep 2019, at 00:41, Chase Peeler  wrote:
> >
> > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown 
> > wrote:
> >
> >> What if Java suddenly said that all properties are suddenly private, and
> >>> can only be accessed through getter/setter methods?
> >>>
> >>
> >> If Java announced that the next major version was to make the change
> after
> >> 95% of userland developers favoured it and over 2/3rds of their
> internals
> >> team did, I'd think "huh ok I guess they have good reasons".
> >>
> >> For 20 years people have developed code based on that feature. It was
> >>> never considered an error, and often not even considered bad practice
> >>
> >>
> >> You seem to be arguing against *ever* changing something that a majority
> >> once thought was good, and fundamental to a given system. Lots of things
> >> fall into that category - restricting voting to men, segregation, etc.
> >>
> >
> > Now you're just being silly. I actually don't have a problem with
> > fundamental language change, provided that the positives that are gained
> > far outweigh the negatives of the BC break and there is no other way to
> > accomplish those positives without such a BC break.
> >
> > There are a myriad of ways to achieve what the RFC attempts to achieve.
> > Whether that's analysis tools, custom error handlers, detailed code
> > reviews, etc. Nothing prevents anyone from initializing all of their
> > variables or performing as many sanity checks on a variable before
> > accessing it as they want to. Nothing in the RFC is required to implement
> > other new functionality like enums, union types, variable typing, etc.
> >
> > I also think it's a bit of a stretch to compare something like variable
> > initialization with things that denied people their basic human rights.
> >
> > --
> > Chase Peeler
> > chasepee...@gmail.com
>
>
> Please, will someone arguing against making use of undefined variables a
> higher severity, explain to me why the same argument was not made for use
> of undefined constants, for which the RFC to deprecate/remove support,
> passed 41:0.
>
> How is one undefined symbol more acceptable than another undefined symbol?


First of all, I wasn't as involved with this list back then as I was now.
However, I can see a fundamental difference in the two. Not needing to
initialize variables just for the sake of initializing them (e.g. just
doing $i++ without $i=0 before it) is something that is going to behave as
expected almost all of the time. When it doesn't, you can easily initialize
$i to a non-zero value, or, you can initialize it to zero if you want - it
doesn't hurt anything.

An undefined constant getting converted to a string, though, is much less
likely to be the intended behavior. String literals are required to be in
quotes. Constants can never be in quotes. Assuming that the token that
looks like a constant, but can't be because the constant didn't exist, so,
we'll pretend it's a string even though it doesn't match the proper syntax
for such a token is drastically different than assuming the variable you
are incrementing that wasn't initialized is 0, or, that the variable you
are concatenating to, but wasn't initialized, is an empty string.

Finally, let's pretend that the undefined constants RFC was a horrible RFC
that shouldn't have passed. The fact that it did has no impact on whether
or not this RFC should pass.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler  wrote:

> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown 
> wrote:
>
> > What if Java suddenly said that all properties are suddenly private, and
> >> can only be accessed through getter/setter methods?
> >>
> >
> > If Java announced that the next major version was to make the change
> after
> > 95% of userland developers favoured it and over 2/3rds of their internals
> > team did, I'd think "huh ok I guess they have good reasons".
> >
> >
> I call shenanigans on that 95% number. Can you please back that up?
> Personally, I don't think it's even possible to gauge userland
> support because the vast majority of userland developers aren't involved in
> the community at all. Those people don't even know this is being discussed,
> and probably won't until they start looking to upgrade to PHP 8.
>
> I'm sure you need to read the message properly before replying, he ain't
talking about PHP there...

Even 95% can be called anything(of users who are involved in the community,
who knows, who are actual users, etc)

>
> > For 20 years people have developed code based on that feature. It was
> >> never considered an error, and often not even considered bad practice
> >
> >
> > You seem to be arguing against *ever* changing something that a majority
> > once thought was good, and fundamental to a given system. Lots of things
> > fall into that category - restricting voting to men, segregation, etc.
> >
> >>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Mike Schinkel]

> On Sep 12, 2019, at 10:37 AM, Lynn  wrote:
> 
> On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler  wrote:
> 
>> There are valid reasons for not always initializing variables or array
>> keys. It might be a bad
>> reason in your opinion, but others view it as perfectly acceptable.
>> 
> 
> I recently had to fix a bug where a variable was renamed, caused a merge
> conflict and resulted in months long of changing a business process with a
> subtle bug, as null was not the intended initialized value. Whether or not
> people should initialize variables is debatable from a programming
> perspective. From a reader's perspective it's really important to have
> variables initialized with a default value, even if it's just null, to
> prevent missing certain assignment branches and avoid bugs. From my
> perspective, this should've thrown an error, so we would've fixed it the
> same day. Now PHP simply broke our business process for months.
> 
> Yes, we hide notices, even in production as our logging server would die
> within a minute if we'd turn it on. Yes, this is a massive legacy code base
> where lots of tests are lacking. Can we change this? Sure, will take years
> though. Would we have benefited from PHP throwing an error in this case?
> Most certainly, would've saved us a lot of headache, and money.
> 
> You argue that it's a fundamental language change, I -and seemingly a lot
> of others- argue that this is more of a bug fix.

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.

If PHP8 were to change to require variables and/or array elements to be 
initialized then this code base and any similar to it will be broken. Companies 
with these code bases almost certainly will simply not upgrade to PHP 8.  
Probably ever.

BTW, prior to gaining this company as a client, the internal people felt that 
the codebase needed to be completely rewritten rather than incrementally 
refactored. And because rewriting would have been such a large project they 
have been putting it off for several years.  In their case, we will be cleaning 
up the code base (although doing so will be very costly for them.) 

And I estimate there are a large number of similar scenarios in the wild that 
do not currently have plans the people or the funds to clean up their similar 
code.

#jmtcw

-Mike

Re: [PHP-DEV] Changing fundamental language behaviors

[Stephen Reay]

> On 13 Sep 2019, at 00:41, Chase Peeler  wrote:
> 
> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown 
> wrote:
> 
>> What if Java suddenly said that all properties are suddenly private, and
>>> can only be accessed through getter/setter methods?
>>> 
>> 
>> If Java announced that the next major version was to make the change after
>> 95% of userland developers favoured it and over 2/3rds of their internals
>> team did, I'd think "huh ok I guess they have good reasons".
>> 
>> For 20 years people have developed code based on that feature. It was
>>> never considered an error, and often not even considered bad practice
>> 
>> 
>> You seem to be arguing against *ever* changing something that a majority
>> once thought was good, and fundamental to a given system. Lots of things
>> fall into that category - restricting voting to men, segregation, etc.
>> 
> 
> Now you're just being silly. I actually don't have a problem with
> fundamental language change, provided that the positives that are gained
> far outweigh the negatives of the BC break and there is no other way to
> accomplish those positives without such a BC break.
> 
> There are a myriad of ways to achieve what the RFC attempts to achieve.
> Whether that's analysis tools, custom error handlers, detailed code
> reviews, etc. Nothing prevents anyone from initializing all of their
> variables or performing as many sanity checks on a variable before
> accessing it as they want to. Nothing in the RFC is required to implement
> other new functionality like enums, union types, variable typing, etc.
> 
> I also think it's a bit of a stretch to compare something like variable
> initialization with things that denied people their basic human rights.
> 
> -- 
> Chase Peeler
> chasepee...@gmail.com


Please, will someone arguing against making use of undefined variables a higher 
severity, explain to me why the same argument was not made for use of undefined 
constants, for which the RFC to deprecate/remove support, passed 41:0.

How is one undefined symbol more acceptable than another undefined symbol?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown 
wrote:

> What if Java suddenly said that all properties are suddenly private, and
>> can only be accessed through getter/setter methods?
>>
>
> If Java announced that the next major version was to make the change after
> 95% of userland developers favoured it and over 2/3rds of their internals
> team did, I'd think "huh ok I guess they have good reasons".
>
>
I call shenanigans on that 95% number. Can you please back that up?
Personally, I don't think it's even possible to gauge userland
support because the vast majority of userland developers aren't involved in
the community at all. Those people don't even know this is being discussed,
and probably won't until they start looking to upgrade to PHP 8.


> For 20 years people have developed code based on that feature. It was
>> never considered an error, and often not even considered bad practice
>
>
> You seem to be arguing against *ever* changing something that a majority
> once thought was good, and fundamental to a given system. Lots of things
> fall into that category - restricting voting to men, segregation, etc.
>
>>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 1:39 PM Olumide Samson  wrote:

>
>
> On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler 
> wrote:
>
>> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown 
>> wrote:
>>
>> > that don't fundamentally change the language
>> >
>> >
>> > There's clearly a big disagreement about whether this is a fundamental
>> > change or not.
>> >
>> > Preventing something that the entire field of software engineering
>> frowns
>> > upon (and that most PHP developers avoid like the plague) doesn't seem
>> like
>> > a *fundamental* change.
>> >
>> >
>> I would argue that this is exactly such a change. The flexibility of PHP
>> has often been touted as a feature and something that sets it apart.
>> Whether that's good or bad is, frankly, irrelevant. There are valid
>> reasons
>> for not always initializing variables or array keys.
>
>  The major valid reason i see is creating a bolierplate or being lazy to
> initialize the variable with even null or similar null-type depending on
> its context.
>
> It might be a bad reason in your opinion, but others view it as perfectly
>> acceptable.
>
>  Who are those "others"?
> I think he(me included) is also one of those "others" that view it as bad
> programming style...
>
> For 20 years people have developed code based on that feature. It was never
>> considered an error, and often not even considered bad practice.
>
>  It was considered an error, that's why you were been warned or given
> notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of
> already-problematic-file.php" and only if we want to remove Notice,Warning
> or Error in the language.
>

No, as discussed previously, notices were never meant to signify a definite
issue. They are "Hey, this might be an issue, it might not, maybe check it
out if you want?" thing. This RFC is proposing that we actually halt
execution of programs that currently work perfectly fine and run exactly as
they were intended to.


> To suddenly define it as such is the exact definition of a fundamental
>> change
>> to the language itself.
>>
> Fundamental is always "fundamental", i think there's no good definition
> for it in this context, so leave fundamental changes out of this discussion
> as something totally bad been cleaned up is a fundamental change and
> something new but not used right and changed to be used right is also
> fundamental...
>

I would said fundamental is any behavior that is expected and intended. At
this point, the fact that you don't have to initialize your variables is an
intended feature of the language. That means people should be able to
depend on such a feature existing. The fact that you don't like it
shouldn't be a justification for breaking that, especially when nothing is
stopping you from being as strict as you want with your own code. You can
also hold any third party libraries that you use to the same standard if
you want.


>
>> What if Java suddenly said that all properties are suddenly private, and
>> can only be accessed through getter/setter methods? The fact that you
>> should make properties private and use such methods is a practice that was
>> drilled into me from day one. Would that justify making such a change,
>> though?
>>
>> I'm not sure how this relates, i think Java would let you see the good or
> bad, it's up to you to see or not from their view, let the majority move
> forward and don't be a stopping stone in moving this language past the 1993
> bondage(needle-haystack, inconsistent naming and many issues we couldn't
> count)...
>

It relates because right now, it's a feature of Java that you can make
properties public and then modify those directly from outside the class.
Since it's an intended feature, a lot of people have written code that
directly accesses public properties.You could argue the only use-case for
doing so is that they are too lazy to write the getter/setter methods, but
that doesn't change the fact that such code exists and is not an error or
even a misuse of a current feature.


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown 
wrote:

> What if Java suddenly said that all properties are suddenly private, and
>> can only be accessed through getter/setter methods?
>>
>
> If Java announced that the next major version was to make the change after
> 95% of userland developers favoured it and over 2/3rds of their internals
> team did, I'd think "huh ok I guess they have good reasons".
>
> For 20 years people have developed code based on that feature. It was
>> never considered an error, and often not even considered bad practice
>
>
> You seem to be arguing against *ever* changing something that a majority
> once thought was good, and fundamental to a given system. Lots of things
> fall into that category - restricting voting to men, segregation, etc.
>

Now you're just being silly. I actually don't have a problem with
fundamental language change, provided that the positives that are gained
far outweigh the negatives of the BC break and there is no other way to
accomplish those positives without such a BC break.

There are a myriad of ways to achieve what the RFC attempts to achieve.
Whether that's analysis tools, custom error handlers, detailed code
reviews, etc. Nothing prevents anyone from initializing all of their
variables or performing as many sanity checks on a variable before
accessing it as they want to. Nothing in the RFC is required to implement
other new functionality like enums, union types, variable typing, etc.

I also think it's a bit of a stretch to compare something like variable
initialization with things that denied people their basic human rights.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler  wrote:

> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown 
> wrote:
>
> > that don't fundamentally change the language
> >
> >
> > There's clearly a big disagreement about whether this is a fundamental
> > change or not.
> >
> > Preventing something that the entire field of software engineering frowns
> > upon (and that most PHP developers avoid like the plague) doesn't seem
> like
> > a *fundamental* change.
> >
> >
> I would argue that this is exactly such a change. The flexibility of PHP
> has often been touted as a feature and something that sets it apart.
> Whether that's good or bad is, frankly, irrelevant. There are valid reasons
> for not always initializing variables or array keys.

 The major valid reason i see is creating a bolierplate or being lazy to
initialize the variable with even null or similar null-type depending on
its context.

It might be a bad reason in your opinion, but others view it as perfectly
> acceptable.

 Who are those "others"?
I think he(me included) is also one of those "others" that view it as bad
programming style...

For 20 years people have developed code based on that feature. It was never
> considered an error, and often not even considered bad practice.

 It was considered an error, that's why you were been warned or given
notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of
already-problematic-file.php" and only if we want to remove Notice,Warning
or Error in the language.


> To suddenly define it as such is the exact definition of a fundamental
> change
> to the language itself.
>
Fundamental is always "fundamental", i think there's no good definition for
it in this context, so leave fundamental changes out of this discussion as
something totally bad been cleaned up is a fundamental change and something
new but not used right and changed to be used right is also fundamental...


>
> What if Java suddenly said that all properties are suddenly private, and
> can only be accessed through getter/setter methods? The fact that you
> should make properties private and use such methods is a practice that was
> drilled into me from day one. Would that justify making such a change,
> though?
>
> I'm not sure how this relates, i think Java would let you see the good or
bad, it's up to you to see or not from their view, let the majority move
forward and don't be a stopping stone in moving this language past the 1993
bondage(needle-haystack, inconsistent naming and many issues we couldn't
count)...

Re: [PHP-DEV] Changing fundamental language behaviors

[Lynn]

On Thu, Sep 12, 2019 at 7:22 PM Chase Peeler  wrote:

> There are valid reasons for not always initializing variables or array
> keys. It might be a bad
> reason in your opinion, but others view it as perfectly acceptable.
>

I recently had to fix a bug where a variable was renamed, caused a merge
conflict and resulted in months long of changing a business process with a
subtle bug, as null was not the intended initialized value. Whether or not
people should initialize variables is debatable from a programming
perspective. From a reader's perspective it's really important to have
variables initialized with a default value, even if it's just null, to
prevent missing certain assignment branches and avoid bugs. From my
perspective, this should've thrown an error, so we would've fixed it the
same day. Now PHP simply broke our business process for months.

Yes, we hide notices, even in production as our logging server would die
within a minute if we'd turn it on. Yes, this is a massive legacy code base
where lots of tests are lacking. Can we change this? Sure, will take years
though. Would we have benefited from PHP throwing an error in this case?
Most certainly, would've saved us a lot of headache, and money.

You argue that it's a fundamental language change, I -and seemingly a lot
of others- argue that this is more of a bug fix.

Regards,
Lynn van der Berg

Re: [PHP-DEV] Changing fundamental language behaviors

[Matthew Brown]

>
> What if Java suddenly said that all properties are suddenly private, and
> can only be accessed through getter/setter methods?
>

If Java announced that the next major version was to make the change after
95% of userland developers favoured it and over 2/3rds of their internals
team did, I'd think "huh ok I guess they have good reasons".

For 20 years people have developed code based on that feature. It was never
> considered an error, and often not even considered bad practice


You seem to be arguing against *ever* changing something that a majority
once thought was good, and fundamental to a given system. Lots of things
fall into that category - restricting voting to men, segregation, etc.

>

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown 
wrote:

> that don't fundamentally change the language
>
>
> There's clearly a big disagreement about whether this is a fundamental
> change or not.
>
> Preventing something that the entire field of software engineering frowns
> upon (and that most PHP developers avoid like the plague) doesn't seem like
> a *fundamental* change.
>
>
I would argue that this is exactly such a change. The flexibility of PHP
has often been touted as a feature and something that sets it apart.
Whether that's good or bad is, frankly, irrelevant. There are valid reasons
for not always initializing variables or array keys. It might be a bad
reason in your opinion, but others view it as perfectly acceptable. For 20
years people have developed code based on that feature. It was never
considered an error, and often not even considered bad practice. To
suddenly define it as such is the exact definition of a fundamental change
to the language itself.

What if Java suddenly said that all properties are suddenly private, and
can only be accessed through getter/setter methods? The fact that you
should make properties private and use such methods is a practice that was
drilled into me from day one. Would that justify making such a change,
though?

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Union Class Types (was Union Type (singular) straw man proposal)

[Mike Schinkel]

Hi Larry,

Thank you for the comment.

> It seems like what you're describing here is more user-customizable 
> autoboxing than anything to do with union types.  

Your first statement ("user-customizable autoboxing") is probably fair to say.

OTOH, rather than say "anything to do with union type" I would instead say 
"where union-types is an excellent use-case for auto-boxing."

> For that, it seems like you'd want more of a fromString() method (magic or 
> interface):

That would certainly work. 

But unfortunately that requires the class developer to be forward-thinking 
enough to implement methods required for all the use-cases of their class 
users, and I think it is unlikely we can depend on that case for most classes 
in the wild.

What I'd rather see is a solution that gives the user of the class more control 
and a well-known/consistent programming model (e.g. ->toGuid().)


> Whether or not something like that is wise I don't know, but it seems like it 
> would resolve the use case you describe better than fiddling with union 
> types.  Or am I totally misunderstanding you as well? :-)

I made the proposal because I felt that auto-boxing was the best solutions for 
the union-types use-case.  So if renaming the proposal to "user-customizable 
autoboxing" is more preferred by others I'd see that to be fine, assuming it 
was implemented in a manner that allowed for adding the use-case of union 
types. :-)

-Mike

P.S. I am not seeing much traction from this proposal so even though we discuss 
the nuances it seems likely it won't matter beyond this discussion.


> On Sep 11, 2019, at 6:07 AM, Larry Garfield  wrote:
> 
> On Sun, Sep 8, 2019, at 2:11 PM, Mike Schinkel wrote:
>> Hi Stephen,
>> 
>> Thanks again.
>> 
>>> So let me start out by clarifying that what *I* was suggesting with unions 
>>> is quite a different concept than you’re talking about. 
>> 
>> I did not realize you were proposing a different solution, too. Sorry I 
>> missed that.
>> 
>>> yes, I’m aware there’s potential ambiguous cases - what if the destination 
>>> accepts `string|int` and the object supports both interfaces?
>> 
>> 
>> Precisely. And the goal of my proposal was in part to eliminate that 
>> ambiguity.
>> 
>>> Ok - the example given makes “sense” with the understanding that it’s 
>>> alternative ‘short’ syntax - but that makes it yet another step further 
>>> from ‘intuitive’ to me, compared with current type hints, and the extension 
>>> to allow unions Nikita introduced -
>> 
>> Acknowledged.
>> 
>>> and if Im not mistaken it makes it incompatible too (i.e. you can’t have 
>>> the behaviour Nikita’s RFC describes and what you describe with the 
>>> ‘anonymous unions’ - they’re too very different approaches using the same 
>>> syntax.
>> 
>> I do not see how they are incompatible except for the details mine 
>> changes, but maybe that is moot at this point?
>> 
>>> I think the intuitiveness factor is easier to explain if you consider the 
>>> case of the Number example - plenty of things will work exactly as you 
>>> expect if you use either an int or a float. But then with your proposal 
>>> suddenly you don’t have a scalar variable any more - yes I know you can 
>>> call `value()` - part of the point of type hints is to reduce boilerplate 
>>> with type checking arguments within the function body - and now you have to 
>>> call a method to get a usable value anyway?
>> 
>> I do not see any technical reason why mine would not be able to behave 
>> the same using the magic methods you were proposing such as 
>> __toString() and for other scalar types — since fundamentally the 
>> proposed union type would be a class anyway. When used that way it 
>> would nullify the benefit of the explicit typing, but if that is what 
>> the developer wanted who was using then why not?
>> 
>> In that context it would be almost the same as just passing in a scalar.
>> 
>>> The GUID example still confuses me in terms of how your example ‘helps’. If 
>>> $guid->getGuid returns null (signifying it’s a string?) presumably I still 
>>> want to do something with that string - otherwise I wouldn’t have accepted 
>>> it as a valid type - at which point I might as well just do a `instanceof` 
>>> or `is_string` call - but now I have to check if the value I was given is 
>>> null, even if I didn’t specify the parameter as being nullable?
>> 
>> It does not help that way. The main help is with $guid->type() which 
>> can be used in a switch. It's just cleaner code, though I can 
>> appreciate that some might see this as not really a benefit:
>> 
>> function processGuid(string|Guid $guid) {
>>  switch( $guid->type()) {
>>  case 'Guid':
>>  $guid->toGuid()->doSomething();
>>  break;
>>  case 'string':
>>  $g = new Guid($guid->toString());
>>  $g-> doSomething();
>>  break;
>>  }
>> }
>> 
>> The other benefit is that 

Re: [PHP-DEV] Changing fundamental language behaviors

[Matthew Brown]

>
> that don't fundamentally change the language


There's clearly a big disagreement about whether this is a fundamental
change or not.

Preventing something that the entire field of software engineering frowns
upon (and that most PHP developers avoid like the plague) doesn't seem like
a *fundamental* change.

Re: [PHP-DEV] Changing fundamental language behaviors

[Scott Arciszewski]

Apologies for my semantic imprecision. I hope the intent of my email
remains clear.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

On Thu, Sep 12, 2019 at 12:56 PM Chase Peeler  wrote:
>
>
>
> On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski  
> wrote:
>>
>> I'd like to weigh in as a voice of reason here.
>>
>> > There are no processes to make fundamental non-opt-in language changes in 
>> > PHP.
>>
>> This part might be reasonable.
>>
>> > There won't be such processes either. These behaviors are here to stay. We 
>> > can tweak them, we can augment them - we do not get to deprecate or 
>> > radically change them.
>>
>> This part is totally unreasonable.
>>
>> Let me explain:
>>
>> "We lack a process" opens a door. If the RFC process is inadequate to
>> address necessary deprecations and removals, then what process *would*
>> be adequate and appropriate?
>>
>> THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe
>> contrary to Zeev about whether the RFC process is adequate and
>> appropriate.
>>
>> "There won't be such processes either" shuts the just-opened door in
>> the rudest manner possible. This doesn't lead to a productive
>> conversation, this just ends it with Zeev's opinion being final.
>>
>> My thoughts:
>>
>> I think we should give Zeev precisely half of what he wants here:
>> Let's discuss whether a separate process should be created for
>> deprecations/removals... and if so, what it would look like. And then
>> if we come up with something new, in true Internals fashion, create an
>> RFC and vote on our new addition to the RFC process. (Even Zeev has to
>> acknowledge that additions are fine, with 2/3 majority.)
>>
>
> Don't use the term "deprecations and removals" - it's not the right term 
> here. There are many deprecations and removals that don't fundamentally 
> change the language. For example, deprecating create_function() after closure 
> support was added didn't fundamentally change the language.
>
>>
>> But we shouldn't accept his door-shutting terms just because he says so.
>>
>> Respectfully,
>>
>> Scott Arciszewski
>> Chief Development Officer
>> Paragon Initiative Enterprises 
>>
>> Scott Arciszewski
>> Chief Development Officer
>> Paragon Initiative Enterprises
>>
>>
>> On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski  wrote:
>> >
>> >
>> >
>> > > -Original Message-
>> > > From: Marco Pivetta 
>> > > Sent: Thursday, September 12, 2019 5:59 PM
>> > > To: Zeev Suraski 
>> > > Cc: PHP Internals List 
>> > > Subject: Re: [PHP-DEV] Changing fundamental language behaviors
>> > >
>> > > If you want to have an authoritative say on what the RFC process is for 
>> > > or not,
>> > > please start a new RFC about it: your mail is just straight out 
>> > > inappropriate.
>> >
>> > No Marco.  The RFC process wasn't meant to deal with who has authoritative 
>> > say any more than it was meant to deal with changing fundamental behaviors 
>> > in PHP.  The fact we got used to putting everything to a vote doesn't mean 
>> > that it can work for anything and everything.
>> >
>> > While I realize my email is unpleasant for many to read, it's in the 
>> > context of an RFC that attempts to do something that is strictly 
>> > inappropriate and out of the question.  Stating the fact, that the RFC 
>> > process was never meant to allow this to be done, is a statement of fact.
>> >
>> > I *hate* to be in the position to be the one who has to point it out and 
>> > stick to it.  I know how much fire that's going to draw and I know I'd 
>> > hate every second of it.  But it is what it is.
>> >
>> > There are no processes to make fundamental non-opt-in language changes in 
>> > PHP.  There won't be such processes either.  These behaviors are here to 
>> > stay.  We can tweak them, we can augment them - we do not get to deprecate 
>> > or radically change them.
>> >
>> > We can (and I believe should) augment them with alternative, stricter 
>> > opt-in behaviors.  But those who dream of simply changing PHP into a 
>> > stricter language step by step should understand that this is simply not 
>> > going to be happen.  Not now, not ever.
>> >
>> > Zeev
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 12:51 PM Scott Arciszewski 
wrote:

> I'd like to weigh in as a voice of reason here.
>
> > There are no processes to make fundamental non-opt-in language changes
> in PHP.
>
> This part might be reasonable.
>
> > There won't be such processes either. These behaviors are here to stay.
> We can tweak them, we can augment them - we do not get to deprecate or
> radically change them.
>
> This part is totally unreasonable.
>
> Let me explain:
>
> "We lack a process" opens a door. If the RFC process is inadequate to
> address necessary deprecations and removals, then what process *would*
> be adequate and appropriate?
>
> THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe
> contrary to Zeev about whether the RFC process is adequate and
> appropriate.
>
> "There won't be such processes either" shuts the just-opened door in
> the rudest manner possible. This doesn't lead to a productive
> conversation, this just ends it with Zeev's opinion being final.
>
> My thoughts:
>
> I think we should give Zeev precisely half of what he wants here:
> Let's discuss whether a separate process should be created for
> deprecations/removals... and if so, what it would look like. And then
> if we come up with something new, in true Internals fashion, create an
> RFC and vote on our new addition to the RFC process. (Even Zeev has to
> acknowledge that additions are fine, with 2/3 majority.)
>
>
Don't use the term "deprecations and removals" - it's not the right term
here. There are many deprecations and removals that don't fundamentally
change the language. For example, deprecating create_function() after
closure support was added didn't fundamentally change the language.


> But we shouldn't accept his door-shutting terms just because he says so.
>
> Respectfully,
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises
>
>
> On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Marco Pivetta 
> > > Sent: Thursday, September 12, 2019 5:59 PM
> > > To: Zeev Suraski 
> > > Cc: PHP Internals List 
> > > Subject: Re: [PHP-DEV] Changing fundamental language behaviors
> > >
> > > If you want to have an authoritative say on what the RFC process is
> for or not,
> > > please start a new RFC about it: your mail is just straight out
> inappropriate.
> >
> > No Marco.  The RFC process wasn't meant to deal with who has
> authoritative say any more than it was meant to deal with changing
> fundamental behaviors in PHP.  The fact we got used to putting everything
> to a vote doesn't mean that it can work for anything and everything.
> >
> > While I realize my email is unpleasant for many to read, it's in the
> context of an RFC that attempts to do something that is strictly
> inappropriate and out of the question.  Stating the fact, that the RFC
> process was never meant to allow this to be done, is a statement of fact.
> >
> > I *hate* to be in the position to be the one who has to point it out and
> stick to it.  I know how much fire that's going to draw and I know I'd hate
> every second of it.  But it is what it is.
> >
> > There are no processes to make fundamental non-opt-in language changes
> in PHP.  There won't be such processes either.  These behaviors are here to
> stay.  We can tweak them, we can augment them - we do not get to deprecate
> or radically change them.
> >
> > We can (and I believe should) augment them with alternative, stricter
> opt-in behaviors.  But those who dream of simply changing PHP into a
> stricter language step by step should understand that this is simply not
> going to be happen.  Not now, not ever.
> >
> > Zeev
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Changing fundamental language behaviors

[Scott Arciszewski]

I'd like to weigh in as a voice of reason here.

> There are no processes to make fundamental non-opt-in language changes in PHP.

This part might be reasonable.

> There won't be such processes either. These behaviors are here to stay. We 
> can tweak them, we can augment them - we do not get to deprecate or radically 
> change them.

This part is totally unreasonable.

Let me explain:

"We lack a process" opens a door. If the RFC process is inadequate to
address necessary deprecations and removals, then what process *would*
be adequate and appropriate?

THIS IS A GOOD CONVERSATION TO HAVE! Especially if you believe
contrary to Zeev about whether the RFC process is adequate and
appropriate.

"There won't be such processes either" shuts the just-opened door in
the rudest manner possible. This doesn't lead to a productive
conversation, this just ends it with Zeev's opinion being final.

My thoughts:

I think we should give Zeev precisely half of what he wants here:
Let's discuss whether a separate process should be created for
deprecations/removals... and if so, what it would look like. And then
if we come up with something new, in true Internals fashion, create an
RFC and vote on our new addition to the RFC process. (Even Zeev has to
acknowledge that additions are fine, with 2/3 majority.)

But we shouldn't accept his door-shutting terms just because he says so.

Respectfully,

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises


On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski  wrote:
>
>
>
> > -Original Message-
> > From: Marco Pivetta 
> > Sent: Thursday, September 12, 2019 5:59 PM
> > To: Zeev Suraski 
> > Cc: PHP Internals List 
> > Subject: Re: [PHP-DEV] Changing fundamental language behaviors
> >
> > If you want to have an authoritative say on what the RFC process is for or 
> > not,
> > please start a new RFC about it: your mail is just straight out 
> > inappropriate.
>
> No Marco.  The RFC process wasn't meant to deal with who has authoritative 
> say any more than it was meant to deal with changing fundamental behaviors in 
> PHP.  The fact we got used to putting everything to a vote doesn't mean that 
> it can work for anything and everything.
>
> While I realize my email is unpleasant for many to read, it's in the context 
> of an RFC that attempts to do something that is strictly inappropriate and 
> out of the question.  Stating the fact, that the RFC process was never meant 
> to allow this to be done, is a statement of fact.
>
> I *hate* to be in the position to be the one who has to point it out and 
> stick to it.  I know how much fire that's going to draw and I know I'd hate 
> every second of it.  But it is what it is.
>
> There are no processes to make fundamental non-opt-in language changes in 
> PHP.  There won't be such processes either.  These behaviors are here to 
> stay.  We can tweak them, we can augment them - we do not get to deprecate or 
> radically change them.
>
> We can (and I believe should) augment them with alternative, stricter opt-in 
> behaviors.  But those who dream of simply changing PHP into a stricter 
> language step by step should understand that this is simply not going to be 
> happen.  Not now, not ever.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Andreas Heigl]

Hey Zeev.

I'm not that deep into @internals and might not get the subtle subtext.
English is not my native tongue so I might phrase things in a way that
doesn't transport the whole meaning of my thoughts. But your Mail really
left me curious:

On Thu, 12 Sep 2019 at 10:44, Zeev Suraski  wrote:

> I was really really hoping that we will avert having to dive into this and
> instead go for the alternative solution that was proposed of changing
> default php.ini error levels.  But since the RFC went on to a vote - we
> need
> to make something clear.
>
>
>
> The RFC process was never, ever meant to handle fundamental changes to the
> language.  It was meant to deal predominantly with additions to the
> language, as can be inferred from numerous parts in the phrasing.  As I
> mentioned in the past - it wasn't even intended to deal with simpler
> deprecations, but it appears that the cat is out of the bag on this one.
> However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
> of the same bag.  Using the RFC to deprecate fundamental behaviors of the
> language - such as how the language deals with undefined variables - is
> simply off the table.

Given the fact that you have the authority to say so, what actually *is*
the process then to make "fundamental changes to the language"?
>
>
>
> You may be wondering, in that case, what processes do we have to deal with
> such changes then?  The answer is simple.  We don't.  We don't have to have
> them either - the fundamental language behaviors are here to stay.

But we still need processes to define which are the "fundamental
language behaviours". And as change is the only constant in
software-development, these "fundamental language behaviours" might, can
and probably should be changeable. I'm not saying they need to change,
but it has to be possible to change them. Otherwise we would still
program business-logic in C as that was Rasmus' fundamental idea IIRC
(Correct me if I'm wrong)

>
> Deprecating the ability to rely on the expected default value of
> uninitialized variables falls squarely in that category.
>
>
>
> Reclassifying a notice to a warning is a possibility - people's code will
> still run, and they'll be able to continue using these behaviors going
> forward as well if they want to (perhaps with minor tweaks to error
> reporting levels).  Turning a notice to an error isn't reclassifying an
> error level.  It's deprecating a behavior - and we're not talking about
> some
> esoteric extension, but a documented, well-defined, fundamental behavior of
> the language for over two decades.  The fact many of you think it's
> horrible
> does not change that.  Deprecating such fundamentals is simply outside of
> the mandate of internals@, regardless of whatever majority appears to
> exist
> in favor of it at a given time.
>
>
>
> Similarly - adding typed variables - is certainly a future option.
> Changing
> PHP to require typed variables (without opting in) - is well outside of the
> internals@ mandate.

So tell us, what is *insight* the @internals mandate. And who has the
mandate to change the things @internals does not have the mandate to.

From what i see you tell us (@internals) "You're not allowed to do so,
but I will not tell you who *is* allowed." So for me that raises two
main questions:

1. Who then has the mandate to do so?
2. By what authority are you making this statement?

I'm looking forward to your answers.

Cheers

Andreas
>
>
>
> For areas like that - our options are either doing nothing, or providing
> opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
> 2nd option, but there is no 3rd.
>
>
>
> Zeev

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Changing fundamental language behaviors

[Morgan Breden]

> While I realize my email is unpleasant for many to read, it's in the
context of an RFC that attempts to do something that is strictly
inappropriate and out of the question.  Stating the fact, that the RFC
process was never meant to allow this to be done, is a statement of fact.

[...]

> There won't be such processes either.  These behaviors are here to stay.
We can tweak them, we can augment them - we do not get to deprecate or
radically change them.

[...]

> But those who dream of simply changing PHP into a stricter language step
by step should understand that this is simply not going to be happen.  Not
now, not ever.

Zeev, "strictly inappropriate and out of the question" seems like a
statement of opinion to me. While I personally agree with your standpoint
on changing this fundamental behavior, your response here seems out of left
field.

Furthermore, statements like "we do not get to deprecate or radically
change them" and  "this is simply not going to happen" are a wholly
inappropriate response to *any* effort. I respect your vast contributions
to the language and your (usually) level-headed stances on this mailing
list, but you are not the grand czar of PHP and I don't believe that hard
line is yours to make. Declaring such a thing reads to me like a spit in
the face of everyone who contributes to the language and to the concept of
a community-driven open source project to begin with.

Over the past few years the movement to push PHP into more modern concepts
has explosively grown in popularity and your resistance to the more rapid
and drastic portions of it is understandable, if nothing else. However,
using your bully pulpit to insist that things you don't like can't be done
leaves a very sour taste in my mouth.

If such limits exist, they should be clear and codified - not something
that exists in the mind of you and whoever else only to be brought up when
someone wants to breach them.

On Thu, Sep 12, 2019 at 11:11 AM Zeev Suraski  wrote:

>
>
> > -Original Message-
> > From: Marco Pivetta 
> > Sent: Thursday, September 12, 2019 5:59 PM
> > To: Zeev Suraski 
> > Cc: PHP Internals List 
> > Subject: Re: [PHP-DEV] Changing fundamental language behaviors
> >
> > If you want to have an authoritative say on what the RFC process is for
> or not,
> > please start a new RFC about it: your mail is just straight out
> inappropriate.
>
> No Marco.  The RFC process wasn't meant to deal with who has authoritative
> say any more than it was meant to deal with changing fundamental behaviors
> in PHP.  The fact we got used to putting everything to a vote doesn't mean
> that it can work for anything and everything.
>
> While I realize my email is unpleasant for many to read, it's in the
> context of an RFC that attempts to do something that is strictly
> inappropriate and out of the question.  Stating the fact, that the RFC
> process was never meant to allow this to be done, is a statement of fact.
>
> I *hate* to be in the position to be the one who has to point it out and
> stick to it.  I know how much fire that's going to draw and I know I'd hate
> every second of it.  But it is what it is.
>
> There are no processes to make fundamental non-opt-in language changes in
> PHP.  There won't be such processes either.  These behaviors are here to
> stay.  We can tweak them, we can augment them - we do not get to deprecate
> or radically change them.
>
> We can (and I believe should) augment them with alternative, stricter
> opt-in behaviors.  But those who dream of simply changing PHP into a
> stricter language step by step should understand that this is simply not
> going to be happen.  Not now, not ever.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Matthew Brown]

Without your contributions in the early 2000s, PHP likely would not enjoy
the popularity it does today.

But I don't think that gives you veto power over the entire process. You
haven't made any significant contributions to the codebase in over a
decade, and yet the language has still gained many more users in that time
frame, with some fairly major backwards-incompatible changes along the way.

I think you have to come to terms with the fact that today you are a single
vote in this process — though you are, of course, free to write your own
RFCs.

Best wishes,

Matt

On Thu, 12 Sep 2019 at 10:44, Zeev Suraski  wrote:

> I was really really hoping that we will avert having to dive into this and
> instead go for the alternative solution that was proposed of changing
> default php.ini error levels.  But since the RFC went on to a vote - we
> need
> to make something clear.
>
>
>
> The RFC process was never, ever meant to handle fundamental changes to the
> language.  It was meant to deal predominantly with additions to the
> language, as can be inferred from numerous parts in the phrasing.  As I
> mentioned in the past - it wasn't even intended to deal with simpler
> deprecations, but it appears that the cat is out of the bag on this one.
> However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
> of the same bag.  Using the RFC to deprecate fundamental behaviors of the
> language - such as how the language deals with undefined variables - is
> simply off the table.
>
>
>
> You may be wondering, in that case, what processes do we have to deal with
> such changes then?  The answer is simple.  We don't.  We don't have to have
> them either - the fundamental language behaviors are here to stay.
>
> Deprecating the ability to rely on the expected default value of
> uninitialized variables falls squarely in that category.
>
>
>
> Reclassifying a notice to a warning is a possibility - people's code will
> still run, and they'll be able to continue using these behaviors going
> forward as well if they want to (perhaps with minor tweaks to error
> reporting levels).  Turning a notice to an error isn't reclassifying an
> error level.  It's deprecating a behavior - and we're not talking about
> some
> esoteric extension, but a documented, well-defined, fundamental behavior of
> the language for over two decades.  The fact many of you think it's
> horrible
> does not change that.  Deprecating such fundamentals is simply outside of
> the mandate of internals@, regardless of whatever majority appears to
> exist
> in favor of it at a given time.
>
>
>
> Similarly - adding typed variables - is certainly a future option.
> Changing
> PHP to require typed variables (without opting in) - is well outside of the
> internals@ mandate.
>
>
>
> For areas like that - our options are either doing nothing, or providing
> opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
> 2nd option, but there is no 3rd.
>
>
>
> Zeev
>
>
>
>

[PHP-DEV] Re: VCS Account Request: marandall

[PHP Group]

VCS Account Approved: marandall approved by kalle \o/

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

[PHP-DEV] VCS Account Request: marandall

[Mark Randall]

Registration recommended by participants of 11

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

RE: [PHP-DEV] Changing fundamental language behaviors

[Zeev Suraski]

> -Original Message-
> From: Olumide Samson 
> Sent: Thursday, September 12, 2019 6:03 PM
> To: Dan Ackroyd 
> Cc: Zeev Suraski ; PHP internals 
> Subject: Re: [PHP-DEV] Changing fundamental language behaviors
> 
> The RFC is Request for Comment on any changes, is there an explicit or 
> implicit
> mention about what kind of proposed changes can be made?

While the Voting RFC was probably one of my worst creations - because it's was 
so laconic and lacking (although it still probably did more good for PHP than 
bad) - yes - there's a strong implication as to what it's meant to deal with 
and what it isn't meant to deal with.

Here's what the Voting RFC said:
"Given that changes to languages (as opposed to changes to apps or even 
frameworks) are for the most part irreversible"

I understand this isn't written black-on-white that you can't deprecate a 
fundamental language behavior.  But it's clear that "having to win a 2/3 vote" 
isn't quite the definition of "irreversible".  The idea behind the 2/3 
requirement (a number that I came up with) was to ensure that the motivation to 
undo that addition/change will likely remain very low in the years following 
the vote on the RFC.  Why?  Because once it's in - it's in.  It cannot be taken 
out.  It's irreversible. 

So no, a 2/3 vote does not get us the mandate to deprecate a fundamental 
language behavior.  It's basically a reasonably high bar to add something to 
the language - given that we know that once we add it, we cannot take it away.  
Nothing more, nothing less.

Zeev

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Chase Peeler]

On Thu, Sep 12, 2019 at 11:01 AM Jordi Boggiano  wrote:

> On 12/09/2019 16:44, Zeev Suraski wrote:
> > Similarly - adding typed variables - is certainly a future option.
> Changing
> > PHP to require typed variables (without opting in) - is well outside of
> the
> > internals@ mandate.
> >
> >
> >
> > For areas like that - our options are either doing nothing, or providing
> > opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
> > 2nd option, but there is no 3rd.
>
>
> While I am not sure your tone will be well received by your target
> audience, I just wanted to say I tend to agree.
>
>
My thoughts as well.


> Breaking BC here does not seem to bring much. If there are cases where
> enforcing strictness might allow better JIT for example, then I could
> see the case being made. But simply turning working code into fatally
> failing code isn't progress.
>
>
Yes!


> I know I have a bunch of old stuff running which tends to litter the
> error logs with notices, and I don't have time to go fix them so I
> ignore because it's fine and it works.
>
>
Can't make that argument. Be prepared to be told how easy it should be for
you to fix it, or, how it's technical debt (ignoring the fact that it's not
technical debt currently, since there is nothing wrong with what was
written) and you're just making things worse by not taking care of it.


> For new projects, what I do, and what I am pretty sure 99% of the
> "strict camp" does is essentially boiling down to:
>
>  set_error_handler(function () { throw new \RuntimeException(); });
>
> That's our global strictness flag right there. It's been available for
> ages. I don't see why we need to take something away from others to make
> such an easy workaround a little less needed. Especially as I don't
> imagine we will drop the error handlers. I sure will keep mine around to
> keep failing warnings etc as hard fatals.
>
> So what do we gain exactly?
>
>
That's the argument I've been making all along. There are so many ways to
accomplish what has been proposed without forcing it on those that don't
want it. It's not required in order to add new features to the language. It
doesn't make the language perform better, either. It's also not taking away
something that is definitely a negative feature. It's taking away something
that many view as a positive feature of the language. If there was no way
to achieve the intended results without making the change, I might be more
sympathetic to making it. But there is. Whether it's an error handler like
you mentioned above, stricter code reviews, public shaming for anyone that
doesn't initialize their variables, or any of the myriad of other options.


> Best,
> Jordi
>
> --
>
> Jordi Boggiano
> @seldaek - https://seld.be
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

RE: [PHP-DEV] Changing fundamental language behaviors

[Zeev Suraski]

> -Original Message-
> From: Marco Pivetta 
> Sent: Thursday, September 12, 2019 5:59 PM
> To: Zeev Suraski 
> Cc: PHP Internals List 
> Subject: Re: [PHP-DEV] Changing fundamental language behaviors
> 
> If you want to have an authoritative say on what the RFC process is for or 
> not,
> please start a new RFC about it: your mail is just straight out inappropriate.

No Marco.  The RFC process wasn't meant to deal with who has authoritative say 
any more than it was meant to deal with changing fundamental behaviors in PHP.  
The fact we got used to putting everything to a vote doesn't mean that it can 
work for anything and everything.  

While I realize my email is unpleasant for many to read, it's in the context of 
an RFC that attempts to do something that is strictly inappropriate and out of 
the question.  Stating the fact, that the RFC process was never meant to allow 
this to be done, is a statement of fact. 

I *hate* to be in the position to be the one who has to point it out and stick 
to it.  I know how much fire that's going to draw and I know I'd hate every 
second of it.  But it is what it is.

There are no processes to make fundamental non-opt-in language changes in PHP.  
There won't be such processes either.  These behaviors are here to stay.  We 
can tweak them, we can augment them - we do not get to deprecate or radically 
change them.

We can (and I believe should) augment them with alternative, stricter opt-in 
behaviors.  But those who dream of simply changing PHP into a stricter language 
step by step should understand that this is simply not going to be happen.  Not 
now, not ever.

Zeev

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

Re: [PHP-DEV] [RFC] Object Initializer

[Olumide Samson]

The RFC is a beautiful feature suggestion, but something is telling me as
beautiful and straightforward the syntax is, what can the use case be?

I really love Constructor or Object initialization to be implemented in
PHP, but is there something I think you're missing in the RFC?

Thanks for the RFC.

On Thu, Sep 12, 2019, 4:02 PM Lynn  wrote:

> On Thu, Sep 12, 2019 at 4:00 PM Michał Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > Hi internals,
> >
> > I'd like to open discussion about RFC: Object Initializer.
> >
> > This proposal reduces boilerplate of object instantiation and properties
> > initialization in case of classes without required constructor arguments
> as
> > a single expression with initializer block.
> >
> > https://wiki.php.net/rfc/object-initializer
> >
> > I appreciate any feedback you all can provide.
> >
> > Thanks,
> > --
> > Michał Brzuchalski
> > brzuc...@php.net
> >
> >
> Heya,
>
> What's the added benefit of this compared to implementing a constructor?
>
> The part I like is that this can be used to replace stdClass/structured
> arrays. Perhaps something like this would nice to have in PHP:
>
> ```
> $people = [];
>
> foreach ($peopleFromDatabase as [$id, $username, $name]) {
> $people[] = {
> Uuid id => $id,
> string username => $username,
> string name => $name,
> };
> // and possible automatic assignment:
> $people[] = {Uuid $id, string $username, string $name};
> }
> ```
>
> Regards,
> Lynn van der Berg
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Olumide Samson]

You first me on that reply Dan, I guess I should just say "the naysayers
are back", I can see their footprint all around.

The RFC is Request for Comment on any changes, is there an explicit or
implicit mention about what kind of proposed changes can be made?

Mr/Mrs Zeev are you for PHP or against it?
I know you are one of the authors of Zend Engine, but please follow the
rules and don't make rules simply because something is going the way you
don't want it to.

That's why there's this called "vote".

On Thu, Sep 12, 2019, 3:52 PM Dan Ackroyd  wrote:

> On Thu, 12 Sep 2019 at 15:44, Zeev Suraski  wrote:
> >
> > The RFC process was never, ever meant to handle fundamental changes to
> the
> > language.
>
> The only appropriate response to this is "lolwat?".
>
> You keep making up rules...that don't exist. You can't expect people
> to suddenly stop using RFCs to change the language just because you
> say so.
>
> Please stop this behaviour. It's really not appropriate.
>
> sincerely
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Object Initializer

[Lynn]

On Thu, Sep 12, 2019 at 4:00 PM Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without required constructor arguments as
> a single expression with initializer block.
>
> https://wiki.php.net/rfc/object-initializer
>
> I appreciate any feedback you all can provide.
>
> Thanks,
> --
> Michał Brzuchalski
> brzuc...@php.net
>
>
Heya,

What's the added benefit of this compared to implementing a constructor?

The part I like is that this can be used to replace stdClass/structured
arrays. Perhaps something like this would nice to have in PHP:

```
$people = [];

foreach ($peopleFromDatabase as [$id, $username, $name]) {
$people[] = {
Uuid id => $id,
string username => $username,
string name => $name,
};
// and possible automatic assignment:
$people[] = {Uuid $id, string $username, string $name};
}
```

Regards,
Lynn van der Berg

Re: [PHP-DEV] Changing fundamental language behaviors

[Jordi Boggiano]

On 12/09/2019 16:44, Zeev Suraski wrote:

Similarly - adding typed variables - is certainly a future option.  Changing
PHP to require typed variables (without opting in) - is well outside of the
internals@ mandate.

  


For areas like that - our options are either doing nothing, or providing
opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
2nd option, but there is no 3rd.



While I am not sure your tone will be well received by your target 
audience, I just wanted to say I tend to agree.


Breaking BC here does not seem to bring much. If there are cases where 
enforcing strictness might allow better JIT for example, then I could 
see the case being made. But simply turning working code into fatally 
failing code isn't progress.


I know I have a bunch of old stuff running which tends to litter the 
error logs with notices, and I don't have time to go fix them so I 
ignore because it's fine and it works.


For new projects, what I do, and what I am pretty sure 99% of the 
"strict camp" does is essentially boiling down to:


    set_error_handler(function () { throw new \RuntimeException(); });

That's our global strictness flag right there. It's been available for 
ages. I don't see why we need to take something away from others to make 
such an easy workaround a little less needed. Especially as I don't 
imagine we will drop the error handlers. I sure will keep mine around to 
keep failing warnings etc as hard fatals.


So what do we gain exactly?

Best,
Jordi

--

Jordi Boggiano
@seldaek - https://seld.be

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Arvids Godjuks]

чт, 12 сент. 2019 г. в 16:53, Dan Ackroyd :

> On Thu, 12 Sep 2019 at 15:44, Zeev Suraski  wrote:
> >
> > The RFC process was never, ever meant to handle fundamental changes to
> the
> > language.
>
> The only appropriate response to this is "lolwat?".
>
> You keep making up rules...that don't exist. You can't expect people
> to suddenly stop using RFCs to change the language just because you
> say so.
>
> Please stop this behaviour. It's really not appropriate.
>
> sincerely
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Agree and support,

but I mostly want to convey this to everyone:

For once, let's not knee-jerk post reply.
Let's take a day to stew on this, formulate the though and express it.
I will do the same, cause I really want to knee-jerk here, but we know how
that ended in recent months and issues it caused.

So let's take the opportunity to voice our opinions in an orderly manner
since Zeev basically opened this can of worms and I honestly do not see
this going well.

-- 
Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] Changing fundamental language behaviors

[Marco Pivetta]

Hi Zeev,


On Thu, Sep 12, 2019 at 4:44 PM Zeev Suraski  wrote:

> I was really really hoping that we will avert having to dive into this and
> instead go for the alternative solution that was proposed of changing
> default php.ini error levels.  But since the RFC went on to a vote - we
> need
> to make something clear.
>
>
>
> The RFC process was never, ever meant to handle fundamental changes to the
> language.  It was meant to deal predominantly with additions to the
> language, as can be inferred from numerous parts in the phrasing.  As I
> mentioned in the past - it wasn't even intended to deal with simpler
> deprecations, but it appears that the cat is out of the bag on this one.
> However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
> of the same bag.  Using the RFC to deprecate fundamental behaviors of the
> language - such as how the language deals with undefined variables - is
> simply off the table.
>
>
>
> You may be wondering, in that case, what processes do we have to deal with
> such changes then?  The answer is simple.  We don't.  We don't have to have
> them either - the fundamental language behaviors are here to stay.
>
> Deprecating the ability to rely on the expected default value of
> uninitialized variables falls squarely in that category.
>
>
>
> Reclassifying a notice to a warning is a possibility - people's code will
> still run, and they'll be able to continue using these behaviors going
> forward as well if they want to (perhaps with minor tweaks to error
> reporting levels).  Turning a notice to an error isn't reclassifying an
> error level.  It's deprecating a behavior - and we're not talking about
> some
> esoteric extension, but a documented, well-defined, fundamental behavior of
> the language for over two decades.  The fact many of you think it's
> horrible
> does not change that.  Deprecating such fundamentals is simply outside of
> the mandate of internals@, regardless of whatever majority appears to
> exist
> in favor of it at a given time.
>
>
>
> Similarly - adding typed variables - is certainly a future option.
> Changing
> PHP to require typed variables (without opting in) - is well outside of the
> internals@ mandate.
>
>
>
> For areas like that - our options are either doing nothing, or providing
> opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
> 2nd option, but there is no 3rd.
>

If you want to have an authoritative say on what the RFC process is for or
not, please start a new RFC about it: your mail is just straight out
inappropriate.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Changing fundamental language behaviors

[Dan Ackroyd]

On Thu, 12 Sep 2019 at 15:44, Zeev Suraski  wrote:
>
> The RFC process was never, ever meant to handle fundamental changes to the
> language.

The only appropriate response to this is "lolwat?".

You keep making up rules...that don't exist. You can't expect people
to suddenly stop using RFCs to change the language just because you
say so.

Please stop this behaviour. It's really not appropriate.

sincerely
Dan
Ack

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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 10:43 AM Robert Korulczyk 
wrote:

> > But, if you're dealing with a counter, then, the intent is that you are
> > going to start counting at 0 and increase it.
>
> This is not that clear as you may think. Several questions may come to
> mind when you will see incrementation of non-existing variable/key. Is it a
> bug
> and this should be initialized with a different value than 0? Maybe a
> mistake on copy? Maybe a typo?
>
> One additional line will make your code much more obvious and easier to
> read and understand:
>
> $i ??= 0;
> $i++;
>

And I'm totally in favor of writing code that way. What I'm not in favor of
is breaking all of the existing code that doesn't do it that way and works
perfectly fine because some people want to FORCE everyone to write it that
way.


> Your code is not only for compiler/parser, but also for humans. Expressing
> your intentions clearly is important - the less ambiguity the better.
>
> Regards,
> Robert Korulczyk
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Robert Korulczyk]

> But, if you're dealing with a counter, then, the intent is that you are
> going to start counting at 0 and increase it. 

This is not that clear as you may think. Several questions may come to mind 
when you will see incrementation of non-existing variable/key. Is it a bug
and this should be initialized with a different value than 0? Maybe a mistake 
on copy? Maybe a typo?

One additional line will make your code much more obvious and easier to read 
and understand:

$i ??= 0;
$i++;

Your code is not only for compiler/parser, but also for humans. Expressing your 
intentions clearly is important - the less ambiguity the better.

Regards,
Robert Korulczyk

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

[PHP-DEV] Changing fundamental language behaviors

[Zeev Suraski]

I was really really hoping that we will avert having to dive into this and
instead go for the alternative solution that was proposed of changing
default php.ini error levels.  But since the RFC went on to a vote - we need
to make something clear.

 

The RFC process was never, ever meant to handle fundamental changes to the
language.  It was meant to deal predominantly with additions to the
language, as can be inferred from numerous parts in the phrasing.  As I
mentioned in the past - it wasn't even intended to deal with simpler
deprecations, but it appears that the cat is out of the bag on this one.
However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
of the same bag.  Using the RFC to deprecate fundamental behaviors of the
language - such as how the language deals with undefined variables - is
simply off the table.

 

You may be wondering, in that case, what processes do we have to deal with
such changes then?  The answer is simple.  We don't.  We don't have to have
them either - the fundamental language behaviors are here to stay.

Deprecating the ability to rely on the expected default value of
uninitialized variables falls squarely in that category.  

 

Reclassifying a notice to a warning is a possibility - people's code will
still run, and they'll be able to continue using these behaviors going
forward as well if they want to (perhaps with minor tweaks to error
reporting levels).  Turning a notice to an error isn't reclassifying an
error level.  It's deprecating a behavior - and we're not talking about some
esoteric extension, but a documented, well-defined, fundamental behavior of
the language for over two decades.  The fact many of you think it's horrible
does not change that.  Deprecating such fundamentals is simply outside of
the mandate of internals@, regardless of whatever majority appears to exist
in favor of it at a given time.

 

Similarly - adding typed variables - is certainly a future option.  Changing
PHP to require typed variables (without opting in) - is well outside of the
internals@ mandate.

 

For areas like that - our options are either doing nothing, or providing
opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
2nd option, but there is no 3rd.

 

Zeev

 

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 10:20 AM Reindl Harald (privat) 
wrote:

> see screenshot, you are the only guy on planet earth whose fukcing first
> line is part of the quote above
>

If you're going to reply to me off list, please at least be polite.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Marco Pivetta]

 


On Thu, Sep 12, 2019 at 4:02 PM Arvids Godjuks 
wrote:

>
>
> чт, 12 сент. 2019 г. в 15:33, Marco Pivetta :
>
>> Hey Rowan,
>> 
>>
>>
>> On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins 
>> wrote:
>>
>> > For instance, for undefined array keys, what if we had an operator for
>> > "initialise and retrieve", such as $foo[? 'bar']. Then we could simplify
>> > ugly code like this:
>> >
>> > if ( ! isset($foo[$key1]) {
>> >$foo[$key1] = [];
>> > }
>> > if ( ! isset($foo[$key1][$key2]) {
>> >$foo[$key1][$key2] = 0;
>> > }
>> > $foo[$key1][$key2]++;
>> >
>> >
>> > With something safe but succinct like this:
>> >
>> > $foo[? $key1][? $key2]++;
>> >
>>
>> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
>>
>>
>>
> This message contains a healthy dose of sarcasm.
>
>
No sarcasm intended: question is about the verbosity and length of a
*proper* (correct = no warnings/notices/errors, matches type expectations)
checked solution, and I provided a simple one-liner that is both readable
and correct.

You can make what you want out of this, but there was most certainly no
sarcasm.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 10:13 AM Olumide Samson 
wrote:

>
>
> On Thu, Sep 12, 2019, 2:59 PM Chase Peeler  wrote:
>
>>
>>
>> On Thu, Sep 12, 2019 at 8:33 AM Olumide Samson 
>> wrote:
>>
>>> Thanks to those who can vote, all in all I hope for a better language
>>> where
>>> we can proudly post jobs(even intern) for on our company's website
>>> without
>>> been looked down on as inferior.
>>>
>>> If you're so embarrassed by the language, then why not use something
>> else, instead of trying to force such massive changes on the entire user
>> base?
>>
> Anything considered through vote is opinion based, not the way you could
> call "force" and I think you can also ask those who are not embarrassed by
> the current language situation to stick to whatever is their current
> version. Upgrading can't be for everyone.
> Only those who like major features/changes  of a new version upgrade.
>
I do like new features. There are tons of new features that can be added
without such a massive and unnecessary BC break.


>
>> Also, if you really think this is going to change how non-PHP developers
>> view PHP, you're sorely mistaken. The few I've talked to about this, in
>> order to gauge how the languages they work in handle BC breaks, were
>> appalled that such a major breakage would be forced on users, even though
>> they personally don't like the fact that PHP supports uninitialized
>> variables.
>>
> I'm sure you are the one mistaken here, cos you don't speak for non-PHP
> developers likewise I don't.
>
> You can in all utmost speak for yourself like I did In my last email.
>
>>
>> I'm not claiming to speak for everyone. I did provide some anecdotal
evidence though.


> Again, I implore everyone to stop trying and make everyone else like us.
>> Our language is awesome because of the fact that it is different and
>> flexible. That flexibility allows you to be strict if you want. If we just
>> want to turn PHP into another language that is like everything else out
>> there, then what's the point of even using PHP to begin with?
>>
>>
> I'm sure you are insulting the Project through those written words. If the
> project still want to be what it has always been, then there's no want or
> need for anything called @internals cos the language can actually still
> stick to PHP 3 and become what it has always been without any updates or
> changes.
>
> Not an insult at all. PHP has made a lot of awesome improvements, and
continues to make more. We can add things like union types, enums, etc.,
without losing the flexibility that makes the language great. This RFC
takes away something that, in the opinion of many, makes PHP better than
the other options out there.


> Like I said, since I can't vote I can only hope for the best.
>
> Since I can't vote, I can only hope for the best.
>>>
>>> <3
>>>
>>> On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:
>>>
>>> > Hi internals,
>>> >
>>> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
>>> >
>>> > There are 4 votes, all of them independent. The first 3 are for
>>> specific
>>> > cases that were controversial during the discussion, the last one is
>>> for
>>> > the remainder of the proposal.
>>> >
>>> > Voting closes 2019-09-26.
>>> >
>>> > Regards,
>>> > Nikita
>>> >
>>>
>>
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 10:11 AM Rowan Tommins 
wrote:

> On Thu, 12 Sep 2019 at 14:55, Claude Pache  wrote:
>
> > Le 12 sept. 2019 à 15:33, Marco Pivetta  a écrit :
> >
> > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> >
> > Marco Pivetta
> >
> >
> > That violates blatantly DRY (twice the exact same lengthy expression
> > `$foo[$key1][$key2]`), so it is not a satisfactory solution.
> >
>
>
> Agreed; it's certainly neater than all the isset() checks, but it's
> definitely a bit ugly.
>
> To clarify my point, the reason why people write this:
>
> $foo[$key1][$key2]++;
>
> Is not because they're lazy, it's because *it expresses their intent*.
>
> The ?key syntax was one suggestion for how to express the intent safely in
> that particular scenario. Another way might be that the array is
> initialised a different way; completely off the top of my head, something
> like this:
>
> $foo = new Dictionary>;
>
> That could express the intent of "this variable is going to be used as an
> accumulator with these dimensions".
>
> The "if isset" lines, in my opinion, don't express any intent, and they
> don't protect against any real errors; they're just noise to work around a
> short-coming in the language.
>
> But, if you're dealing with a counter, then, the intent is that you are
going to start counting at 0 and increase it. In that case, if the variable
hasn't be initialized, or, the array key doesn't exist, it makes sense to
assume it's 0.

If you need to do something else besides assuming it's 0 and counting from
there, then put in the extra code to check for that.
I can do this already:
if(!isset($i)){
  return false;
}
$i++;

So, why should I start having to do
if(!isset($i)){
  $i = 0;
}
$i++;

when
$i++;

works just fine.


> Regards,
> --
> Rowan Tommins
> [IMSoP]
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Nikita Popov]

On Thu, Sep 12, 2019 at 4:11 PM Rowan Tommins 
wrote:

> On Thu, 12 Sep 2019 at 14:55, Claude Pache  wrote:
>
> > Le 12 sept. 2019 à 15:33, Marco Pivetta  a écrit :
> >
> > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> >
> > Marco Pivetta
> >
> >
> > That violates blatantly DRY (twice the exact same lengthy expression
> > `$foo[$key1][$key2]`), so it is not a satisfactory solution.
> >
>
>
> Agreed; it's certainly neater than all the isset() checks, but it's
> definitely a bit ugly.
>
> To clarify my point, the reason why people write this:
>
> $foo[$key1][$key2]++;
>
> Is not because they're lazy, it's because *it expresses their intent*.
>
> The ?key syntax was one suggestion for how to express the intent safely in
> that particular scenario. Another way might be that the array is
> initialised a different way; completely off the top of my head, something
> like this:
>
> $foo = new Dictionary>;
>
> That could express the intent of "this variable is going to be used as an
> accumulator with these dimensions".
>
> The "if isset" lines, in my opinion, don't express any intent, and they
> don't protect against any real errors; they're just noise to work around a
> short-coming in the language.


FTR this is basically what Python does via defaultdict:
https://docs.python.org/3/library/collections.html#collections.defaultdict

I think it is the "cleanest" solution to this problem overall. Though it
does need a separate structure, rather than our favorite PHP array.

Nikita

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Rowan Tommins]

On Thu, 12 Sep 2019 at 15:02, Arvids Godjuks 
wrote:

>
> This message contains a healthy dose of sarcasm.
>


I think we need less sarcasm on this thread, and more empathy. I'm doing my
best to discuss a real scenario, and how to improve the language for it,
and move away from oh-so-hilarious parodies of each other's positions.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

[Olumide Samson]

On Thu, Sep 12, 2019, 2:59 PM Chase Peeler  wrote:

>
>
> On Thu, Sep 12, 2019 at 8:33 AM Olumide Samson 
> wrote:
>
>> Thanks to those who can vote, all in all I hope for a better language
>> where
>> we can proudly post jobs(even intern) for on our company's website without
>> been looked down on as inferior.
>>
>> If you're so embarrassed by the language, then why not use something
> else, instead of trying to force such massive changes on the entire user
> base?
>
Anything considered through vote is opinion based, not the way you could
call "force" and I think you can also ask those who are not embarrassed by
the current language situation to stick to whatever is their current
version. Upgrading can't be for everyone.
Only those who like major features/changes  of a new version upgrade.

>
> Also, if you really think this is going to change how non-PHP developers
> view PHP, you're sorely mistaken. The few I've talked to about this, in
> order to gauge how the languages they work in handle BC breaks, were
> appalled that such a major breakage would be forced on users, even though
> they personally don't like the fact that PHP supports uninitialized
> variables.
>
I'm sure you are the one mistaken here, cos you don't speak for non-PHP
developers likewise I don't.

You can in all utmost speak for yourself like I did In my last email.

>
> Again, I implore everyone to stop trying and make everyone else like us.
> Our language is awesome because of the fact that it is different and
> flexible. That flexibility allows you to be strict if you want. If we just
> want to turn PHP into another language that is like everything else out
> there, then what's the point of even using PHP to begin with?
>
>
I'm sure you are insulting the Project through those written words. If the
project still want to be what it has always been, then there's no want or
need for anything called @internals cos the language can actually still
stick to PHP 3 and become what it has always been without any updates or
changes.

Like I said, since I can't vote I can only hope for the best.

Since I can't vote, I can only hope for the best.
>>
>> <3
>>
>> On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:
>>
>> > Hi internals,
>> >
>> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
>> >
>> > There are 4 votes, all of them independent. The first 3 are for specific
>> > cases that were controversial during the discussion, the last one is for
>> > the remainder of the proposal.
>> >
>> > Voting closes 2019-09-26.
>> >
>> > Regards,
>> > Nikita
>> >
>>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Benjamin Morel]

>> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> That violates blatantly DRY (twice the exact same lengthy expression
`$foo[$key1][$key2]`), so it is not a satisfactory solution.

$foo[$key1][$key2]??++ 

More seriously, yes as Marco suggested, yes we can already do it, and as
Claude pointed out, yes that's verbose.

What I had in mind with language support is some kind of code-level (per
line or block) switch that would allow uninitialized array keys to behave
in a certain way, *depending on the context* : we actually have not one,
but two good examples of this above, provided that $key1 and $key2 do not
exist:

- with [], an unitialized key would be initialized with an empty array
(already does that)
- with ++, an unitialized key would be initialized with 0

Without the proper code-level switch, we could safely have both cases above
throw an exception.

— Benjamin

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 10:06 AM Arvids Godjuks 
wrote:

>
>
> чт, 12 сент. 2019 г. в 16:02, Chase Peeler :
>
>> On Thu, Sep 12, 2019 at 9:55 AM Claude Pache 
>> wrote:
>>
>> >
>> >
>> > > Le 12 sept. 2019 à 15:33, Marco Pivetta  a écrit
>> :
>> > >
>> > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
>> > >
>> > > Marco Pivetta
>> >
>> > That violates blatantly DRY (twice the exact same lengthy expression
>> > `$foo[$key1][$key2]`), so it is not a satisfactory solution.
>> >
>> > And that's why PHP is so awesome. You don't have to do all these stupid
>> tricks just to do something simple like increment a counter. But, it looks
>> like we're going to throw that out of the window because some people think
>> that since they like doing it like the way above, everyone should have to.
>>
>> > —Claude
>> >
>> >
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>
> Easy, because experience shows that leads to bugs and lots of them.
> Security issues even.
> If you want to write predictable code - you have to init your
> variables/arrays. And check for existence/null. If fixed at least a few
> dozen bugs in my system I took over in the last few months specifically
> because of undefined variables or indexes.
>
> Never once have I advocated not initializing variables or arrays. I'm just
saying that we shouldn't force such behavior. Many of us can figure out
when we need the extra boilerplate and when we don't. Don't force us to
have to deal with the additional burden in every single case because
someone else can't.


> It works for small stuff, but when you have a codebase with 100+k LOC and
> more, you have to go strict or it starts to cost a lot of money and
> personnel to keep things running along.
>
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Rowan Tommins]

On Thu, 12 Sep 2019 at 14:55, Claude Pache  wrote:

> Le 12 sept. 2019 à 15:33, Marco Pivetta  a écrit :
>
> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
>
> Marco Pivetta
>
>
> That violates blatantly DRY (twice the exact same lengthy expression
> `$foo[$key1][$key2]`), so it is not a satisfactory solution.
>


Agreed; it's certainly neater than all the isset() checks, but it's
definitely a bit ugly.

To clarify my point, the reason why people write this:

$foo[$key1][$key2]++;

Is not because they're lazy, it's because *it expresses their intent*.

The ?key syntax was one suggestion for how to express the intent safely in
that particular scenario. Another way might be that the array is
initialised a different way; completely off the top of my head, something
like this:

$foo = new Dictionary>;

That could express the intent of "this variable is going to be used as an
accumulator with these dimensions".

The "if isset" lines, in my opinion, don't express any intent, and they
don't protect against any real errors; they're just noise to work around a
short-coming in the language.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 10:02 AM Arvids Godjuks 
wrote:

> чт, 12 сент. 2019 г. в 15:33, Marco Pivetta :
>
> > Hey Rowan,
> > 
> >
> >
> > On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins 
> > wrote:
> >
> > > For instance, for undefined array keys, what if we had an operator for
> > > "initialise and retrieve", such as $foo[? 'bar']. Then we could
> simplify
> > > ugly code like this:
> > >
> > > if ( ! isset($foo[$key1]) {
> > >$foo[$key1] = [];
> > > }
> > > if ( ! isset($foo[$key1][$key2]) {
> > >$foo[$key1][$key2] = 0;
> > > }
> > > $foo[$key1][$key2]++;
> > >
> > >
> > > With something safe but succinct like this:
> > >
> > > $foo[? $key1][? $key2]++;
> > >
> >
> > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> >
> > Marco Pivetta
> >
> > http://twitter.com/Ocramius
> >
> > http://ocramius.github.com/
> >
>
> This message contains a healthy dose of sarcasm.
>
> Hi Marko and Rowan :)
>
> *Me reviewing the PR with that code*
> *Clicks "Changes required"
> [ Please rewrite this statement into easy readable format with an if ]
> * Clicks send *
>
> Think what you must, but 6 months when you come back to code like this you
> have to stop, look at it hard and figure out what the hell actually happens
> there.
> Breaks reading flow.
>
> One thing I like PHP for is a distinct lack of huge amounts of syntax
> sugar.
> Take Ruby - it's a hell to read the code. Even Vagrantfile has tons of
> results about what syntax for arrays to use and things breaking because you
> end up mixing stuff and you get at least 4 different answers to the same
> question and it looks like all are correct. Confusing as hell :)
>
> What I'm trying to say is some of us choose PHP for it's "there is one
> syntax - use it". If people want syntax sugar - there are other languages
> that fit that much better. Leave us, peasants, in our peasant non-syntax
> sugar world alone :D
>
> Exactly. One common theme I've been seeing is "We already force our
developers to initialize variables, so, whats the big deal if you have to?"
or "We already force a no-notice environment, so what's the big deal if you
have to?"

If you're already doing it, then why do you feel the need to force others
to? You've proven that it can be done in the current system.

I'm making my prediction now - if this RFC passes, the adoption rate for
PHP 8 is going to be HORRIBLE.


> But many of us would also like the language engine to tighten up some of
> its extremely relaxed parts that do not fit in modern development
> environments and the lowest bar of the code quality rise a bit. Otherwise,
> the gap between high-end development and newbies is going to be even bigger
> than it is now.
> I hire people, that's part of my job. One of the criteria is the approach
> to errors/warning/notices. Imagine how that goes.
>
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Arvids Godjuks]

чт, 12 сент. 2019 г. в 16:02, Chase Peeler :

> On Thu, Sep 12, 2019 at 9:55 AM Claude Pache 
> wrote:
>
> >
> >
> > > Le 12 sept. 2019 à 15:33, Marco Pivetta  a écrit :
> > >
> > > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> > >
> > > Marco Pivetta
> >
> > That violates blatantly DRY (twice the exact same lengthy expression
> > `$foo[$key1][$key2]`), so it is not a satisfactory solution.
> >
> > And that's why PHP is so awesome. You don't have to do all these stupid
> tricks just to do something simple like increment a counter. But, it looks
> like we're going to throw that out of the window because some people think
> that since they like doing it like the way above, everyone should have to.
>
> > —Claude
> >
> >
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Easy, because experience shows that leads to bugs and lots of them.
Security issues even.
If you want to write predictable code - you have to init your
variables/arrays. And check for existence/null. If fixed at least a few
dozen bugs in my system I took over in the last few months specifically
because of undefined variables or indexes.

It works for small stuff, but when you have a codebase with 100+k LOC and
more, you have to go strict or it starts to cost a lot of money and
personnel to keep things running along.

-- 
Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Arvids Godjuks]

чт, 12 сент. 2019 г. в 15:33, Marco Pivetta :

> Hey Rowan,
> 
>
>
> On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins 
> wrote:
>
> > For instance, for undefined array keys, what if we had an operator for
> > "initialise and retrieve", such as $foo[? 'bar']. Then we could simplify
> > ugly code like this:
> >
> > if ( ! isset($foo[$key1]) {
> >$foo[$key1] = [];
> > }
> > if ( ! isset($foo[$key1][$key2]) {
> >$foo[$key1][$key2] = 0;
> > }
> > $foo[$key1][$key2]++;
> >
> >
> > With something safe but succinct like this:
> >
> > $foo[? $key1][? $key2]++;
> >
>
> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

This message contains a healthy dose of sarcasm.

Hi Marko and Rowan :)

*Me reviewing the PR with that code*
*Clicks "Changes required"
[ Please rewrite this statement into easy readable format with an if ]
* Clicks send *

Think what you must, but 6 months when you come back to code like this you
have to stop, look at it hard and figure out what the hell actually happens
there.
Breaks reading flow.

One thing I like PHP for is a distinct lack of huge amounts of syntax
sugar.
Take Ruby - it's a hell to read the code. Even Vagrantfile has tons of
results about what syntax for arrays to use and things breaking because you
end up mixing stuff and you get at least 4 different answers to the same
question and it looks like all are correct. Confusing as hell :)

What I'm trying to say is some of us choose PHP for it's "there is one
syntax - use it". If people want syntax sugar - there are other languages
that fit that much better. Leave us, peasants, in our peasant non-syntax
sugar world alone :D

But many of us would also like the language engine to tighten up some of
its extremely relaxed parts that do not fit in modern development
environments and the lowest bar of the code quality rise a bit. Otherwise,
the gap between high-end development and newbies is going to be even bigger
than it is now.
I hire people, that's part of my job. One of the criteria is the approach
to errors/warning/notices. Imagine how that goes.

-- 
Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 9:55 AM Claude Pache  wrote:

>
>
> > Le 12 sept. 2019 à 15:33, Marco Pivetta  a écrit :
> >
> > $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> >
> > Marco Pivetta
>
> That violates blatantly DRY (twice the exact same lengthy expression
> `$foo[$key1][$key2]`), so it is not a satisfactory solution.
>
> And that's why PHP is so awesome. You don't have to do all these stupid
tricks just to do something simple like increment a counter. But, it looks
like we're going to throw that out of the window because some people think
that since they like doing it like the way above, everyone should have to.

> —Claude
>
>

-- 
Chase Peeler
chasepee...@gmail.com

[PHP-DEV] [RFC] Object Initializer

[Michał Brzuchalski]

Hi internals,

I'd like to open discussion about RFC: Object Initializer.

This proposal reduces boilerplate of object instantiation and properties
initialization in case of classes without required constructor arguments as
a single expression with initializer block.

https://wiki.php.net/rfc/object-initializer

I appreciate any feedback you all can provide.

Thanks,
--
Michał Brzuchalski
brzuc...@php.net

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 8:33 AM Olumide Samson  wrote:

> Thanks to those who can vote, all in all I hope for a better language where
> we can proudly post jobs(even intern) for on our company's website without
> been looked down on as inferior.
>
> If you're so embarrassed by the language, then why not use something else,
instead of trying to force such massive changes on the entire user base?

Also, if you really think this is going to change how non-PHP developers
view PHP, you're sorely mistaken. The few I've talked to about this, in
order to gauge how the languages they work in handle BC breaks, were
appalled that such a major breakage would be forced on users, even though
they personally don't like the fact that PHP supports uninitialized
variables.

Again, I implore everyone to stop trying and make everyone else like us.
Our language is awesome because of the fact that it is different and
flexible. That flexibility allows you to be strict if you want. If we just
want to turn PHP into another language that is like everything else out
there, then what's the point of even using PHP to begin with?


> Since I can't vote, I can only hope for the best.
>
> <3
>
> On Thu, Sep 12, 2019, 1:17 PM Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I've opened the vote on //wiki.php.net/rfc/engine_warnings.
> >
> > There are 4 votes, all of them independent. The first 3 are for specific
> > cases that were controversial during the discussion, the last one is for
> > the remainder of the proposal.
> >
> > Voting closes 2019-09-26.
> >
> > Regards,
> > Nikita
> >
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Claude Pache]

> Le 12 sept. 2019 à 15:33, Marco Pivetta  a écrit :
> 
> $foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;
> 
> Marco Pivetta

That violates blatantly DRY (twice the exact same lengthy expression 
`$foo[$key1][$key2]`), so it is not a satisfactory solution.

—Claude

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Chase Peeler]

On Thu, Sep 12, 2019 at 5:41 AM Claude Pache  wrote:

>
>
> > Le 12 sept. 2019 à 10:17, Stephen Reay  a
> écrit :
> >
> >
> >
> > I’ve seen a number of people that have concerns about PHP throwing
> actual errors (as opposed to notices) because they try to use a
> variable/offset that doesn’t exist, and of course there is often a proposal
> to have a declare statement or something similar, to allow their “code
> style” to run without errors.
> >
> >
> > So, my proposal to the situation is to introduce a single declare that
> solves that problem, once and for all.
> >
> >
> >   declare(sloppy=1);
> >
> >
> > This would suppress any errors about undefined variables, array offsets,
> would reverse the “bare words" change when encountering an undefined
> constant, etc. Heck, for good measure this mode could even re-implement
> register_globals and magic_quotes, because why not?
> >

This still forces people to opt-in to something that has been supported for
20+ years, and there isn't even a consensus on it being "sloppy" to begin
with.

>

>
> >
> > If you want to write sloppy code, that is entirely your prerogative, but
> please just own it for what it is, and stop pretending that it’s some
> herculean task to either define variables/offsets first; or check if
> they’re defined; or use an appropriate method to access them that
> specifically allows for undefined variables/offsets (i.e. the ?? and ??=
> operators)
> >
> >
>
> Declare(sloppy=yeah) is not granular enough. To all: please, do understand
> that everything is not black or white; this remark is not directed
> specifically to that particular issue, this is an attitude I see regularly
> on that mailing list.
>
> There is no such thing as “one true strict coding standard” and “one
> legacy lax coding standard”. For instance:
>
> * As time passes, we learn by experience what features were plain blunders
> (magic_quotes?), what features should have been more strict for the sake of
> catching bugs without imposing too much burden on users, what features
> could have been more strict, although that would impose to write lot of
> boiler code, etc. This process does not belong exclusively to some past
> dark age of sloppy and unsecure coding practices.
>
> * The degree of wanted strictness vary depending on occasions. For example
> when I’m writing a throw-away script, some notices are okay to indicate
> possible problems, but I’m not going to write boilerplate code (or, worse,
> put a @ in front of everything) just for the sake of silencing them. (But I
> *certainly* do not want stupid things like mistyped constants converted to
> string literals.) On the other hand, when I’m writing a critical part of an
> application, I am careful to write down everything precisely, and having to
> write explicitly and once for all that, yes, this precise variable must
> have that default value, is a minimal part of the time passed to write,
> re-read and review the code.
>
> What??? You mean it's possible to write strict code even when the engine
doesn't force you to? But I got the feeling that wasn't possible and we
needed to force EVERYONE to code this way.


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

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Marco Pivetta]

Hey Rowan,



On Thu, Sep 12, 2019 at 3:30 PM Rowan Tommins 
wrote:

> For instance, for undefined array keys, what if we had an operator for
> "initialise and retrieve", such as $foo[? 'bar']. Then we could simplify
> ugly code like this:
>
> if ( ! isset($foo[$key1]) {
>$foo[$key1] = [];
> }
> if ( ! isset($foo[$key1][$key2]) {
>$foo[$key1][$key2] = 0;
> }
> $foo[$key1][$key2]++;
>
>
> With something safe but succinct like this:
>
> $foo[? $key1][? $key2]++;
>

$foo[$key1][$key2] = ($foo[$key1][$key2] ?? 0) + 1;

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Rowan Tommins]

On Thu, 12 Sep 2019 at 11:32, Benjamin Morel 
wrote:

> I don't think there are that many such *potentially *legitimate use cases,
> so maybe we could just list the use cases and think about a more elegant
> solution to solve them?
>


Yes, please. If we can focus less on vague anecdotes and opinions *on both
sides*, we can look at *making the language more pleasant to use*.


For instance, for undefined array keys, what if we had an operator for
"initialise and retrieve", such as $foo[? 'bar']. Then we could simplify
ugly code like this:

if ( ! isset($foo[$key1]) {
   $foo[$key1] = [];
}
if ( ! isset($foo[$key1][$key2]) {
   $foo[$key1][$key2] = 0;
}
$foo[$key1][$key2]++;


With something safe but succinct like this:

$foo[? $key1][? $key2]++;

Unlike the error suppression @ operator, this is not saying "I know I'm
doing something wrong, do it anyway"; it's saying "I want to do this
specific thing, I just want to do it in fewer lines of code".

The more helpers like this we have, the more I'd be amenable to
*eventually* raising things to Error - although I still think that should
be done over a longer period of time than a single release cycle.


Regards,
-- 
Rowan Tommins
[IMSoP]