[PHP-DEV] "Fighting about analogies"

[Mike Schinkel]

> On Oct 11, 2019, at 1:44 PM, Larry Garfield  wrote:
> 
> Could y'all please go fight about analogies in another thread, rather than 
> one that was explicitly trying to get away from that silliness?  Much obliged.

Done!  :-)

> On Oct 10, 2019, at 1:03 PM, Chase Peeler  wrote:
> 
> Mike - I have no issue with compromise when it makes sense. Sometimes, 
> though, it doesn't. I'll paraphrase an example given by Jonah Goldberg. One 
> side wants to build a 100 yard bridge to an island. The other side doesn't 
> think we need to build the bridge because we don't need to go to the island. 
> What's the compromise? Building a 50 yard bridge?

It is interesting — or perhaps ironic — that you choose to quote an individual 
known for staking out controversial no-compromise positions in governmental 
politics in order to attempt to justify the existence of a no-compromise 
approach to issues that affect a large number of people where many disagree 
with the solitary approach proposed but would be open to exploring ways  to 
meet their underlying objections. 

To him I would say that same thing; black-and-white approaches to issues ends 
up ensure that everyone is worse off. However ask "What is the underlying 
motivation here and can we find a way to address your legitimate 
needs/concernss while at the same time not trampling on my legitimate 
needs/concerns?"

Basically most all RFCs are great examples of X-Y problems.  Rather than have 
discussions to identify legitimate cases of "Y", someone proposes "X" and then 
people dig in based on their unstated/understated concerns rather than FIRST 
identify mutually agreed problems and THEN collaborate on a solution.


> On Oct 10, 2019, at 1:14 PM, Bishop Bettini  wrote:
> 
> No. The compromise is funding a ferry system. Or laying Internet between 
> them. Or a passenger pigeon mail route.
> Sometimes compromise requires deep discussion about the motivations for each 
> side and coming to a lateral, mutually acceptable, solution.

Bishops response perfect illustrates the fallacy in binary thinking given 
Goldberg's example.


> But we'd rather not discuss motivations and just bicker about the surface 
> results. I.e., argue the X, rather than the Y, of these little XY problems 
> we're solving.

Yes!  Basically most all RFCs are great examples of X-Y problems.  

Rather than have discussions to identify legitimate cases of "Y", someone 
proposes "X" and then people dig in based on their unstated/understated 
concerns rather than FIRST identify mutually agreed problems and THEN 
collaborate on a solution.

Maybe we should create a pre-requisite for RFCs, to first require an "Issue 
Identification Statement" be drafted first and signed by a minimum number of 
people — including non-voters — before an RFC can be submitted? (IIS for short 
— yes, pun intended. :). We could also allow dissenters to write up a response 
that would be group with the statement on the wiki. Doing this might help 
ensure that the problem is one that people have agreed need to be solved before 
debating solutions ad-nauseum?


> On Oct 10, 2019, at 1:03 PM, Chase Peeler  wrote:
> 
> The fact is, when there is a compromise that makes sense, people usually 
> suggest it. 

That has not been what I have witnessed. Reading this list for ~3 months now, I 
have rarely seen people suggest compromises, and when they do it is just one or 
two people in a discussion with 10 or more people.  What I am suggesting is 
that we consider as possibly part of a future CoC that "How can we compromise 
on this?" Is a question everyone is expected to ask and everyone is expected to 
offer what they view would be a compromise.

Of course, saying that I am expecting that more than one person will say this 
would not be workable because they do not see how (are unwilling?) to 
compromise on many issues.

> To the side that says "There is absolutely no reason we need to go to, or 
> communicate with, the island in the first place," a ferry project isn't a 
> compromise. The position of the "anti-bridge" builders isn't because they are 
> against building bridges - it's because they are against spending resources 
> on attempts to get to the island in the first place. The other side might 
> have valid arguments on why we need to get to the island, but, just proposing 
> different ways to get there isn't compromising with the side that doesn't 
> want to go there.

And that is a perfect example of the type of approach that cause problems in 
all communities; someone who is intransigent on a topic and unwilling to 
consider the wants and needs of others, thinking that the only solution is one 
that addresses their own wants and needs, others wants and needs be damned.

So the question I pose is, in a community when one contingent says "Lets find a 
compromise" and the other says "My way or the highway," who should prevail?  Is 
the ones willing to find a workable solution, or the ones who are dug-in and 
not willing to 

Re: [PHP-DEV] Warning for "confusable" types

[Larry Garfield]

On Fri, Oct 11, 2019, at 1:46 PM, Bishop Bettini wrote:
> On Fri, Oct 11, 2019 at 1:47 PM Larry Garfield 
> wrote:
> 
> > On Fri, Oct 11, 2019, at 8:54 AM, Nikita Popov wrote:
> > > Hi internals,
> > >
> > > Something I've seen play out a couple of times: Newbies try to use
> > > something like "integer" or "resource" as a type, and then get a
> > confusing
> > > error message along the lines of "must be an instance of resource,
> > resource
> > > given".
> > >
> > > I would like to throw a compiler warning in this case, that looks as one
> > of
> > > the following:
> > >
> > > > Warning: "integer" will be interpreted as a class type. Did you mean
> > > "int"? Use qualified name or "use" to suppress this warning
> > >
> > > > Warning: "resource" is not a supported builtin type and will be
> > > interpreted as a class type. Use qualified name or "use" to suppress this
> > > warning
> > >
> > > This warning only triggers if the type is lowercase (integer but not
> > > Integer), is unqualified (integer but not \integer) and is not imported
> > > (there is no "use integer"). This provides multiple ways to avoid the
> > > warning for code that does legitimately want to use lowercase "integer"
> > as
> > > a class type.
> > >
> > > Implementation: https://github.com/php/php-src/pull/4815
> > >
> > > Thoughts?
> > >
> > > Nikita
> >
> > Can you clarify where exactly "compiler warning" would be displayed?  Is
> > that an E_WARNING?  How would I as a user see a message when I write
> >
> > function foo(integer $a) { ... }
> >
> 
> It's an E_COMPILE_WARNING, and arises when the compiler sees you're type
> hinting for a class, but no such class loaded. This checks that given class
> against a known list of "probable mistakes" and provides guidance. Eg, I
> typed "integer $a" when I mean "int $a", and don't understand the current
> compiler warning: "Argument 1 passed to foo must be an instance of integer,
> int given"
> 
> See also https://stackoverflow.com/a/40638544/2908724

OK, so it's just taking an existing error message and customizing it in cases 
where we have a good idea of what the user got wrong?  That's a very +1 in my 
book.

--Larry Garfield

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

Re: [PHP-DEV] Warning for "confusable" types

[Stanislav Malyshev]

Hi!

> Something I've seen play out a couple of times: Newbies try to use
> something like "integer" or "resource" as a type, and then get a confusing
> error message along the lines of "must be an instance of resource, resource
> given".

Maybe we should just change the error message to this?

must be an instance of the class "resource", but resource type is given

OTOH, since there are actually no resource type hints, and naming your
class "resource" is an extremely bad idea, having a warning there
wouldn't hurt too.

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

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

Re: [PHP-DEV] exit() via exception

[Stanislav Malyshev]

Hi!

> For me, one of the most annoying things about this is that we can't perform
> proper leak checks on code using PhpUnit, because it will always exit() at
> the end, which will result in "expected" memory leaks.

Is that something that might be fixed in phpunit? I am not familiar with
this specific issue but I'm not sure why unit test code can't use some
other way to end whatever it's doing than exit() if that's the issue. Is
it about the exit codes? If so, this probably can be fixed by other means?

> I think it would be good to switch exit() to work by throwing a magic
> exception, similar to what Python does. This would allow us to properly
> unwind the stack, executing finally blocks (which are currently skipped)
> and perform a clean engine shutdown.

True, but that means exit() would become a) significantly slower b) may
change semantics, which may or may not be a good thing. Also there's a
possibility of exit() failing then which is not something we've had before.

> Depending on the implementation, we could also allow code to actually catch
> this exception, which may be useful for testing scenarios, as well as
> long-running daemons.

I don't think this is a particularly good idea - first of all, using
exception for flow control is wrong. Second of all, if you _want_ to use
exceptions for flow control, you already can. If the code uses exit(),
it usually means exit, as in drop everything and get the heck out. It
may not expect that lots of code will run after that (yes, I know,
shutdown handlers, but they have to be clearly installed as such) that
may still do a lot of stuff - while the state of the app is potentially
broken. If we make exit catchable, then the next request would be to
implement real, un-catchable, exit that actually implements the old
semantics. Sometimes people don't care about memory leaks checking but
want to just abandon the boat and let the memory manager to clean up the
mess (or even not that, just kill the process and be done).

> I'm mainly wondering how exactly we'd go about integrating this in the
> existing exception hierarchy. Assuming that it is desirable to allow people
> to actually catch this exception, my first thought would be along these
> lines:

I don't think it should be Throwable, since you a) can't and shouldn't
actually throw it and b) code that catches Throwable does not expect to
catch exits, so it would break its semantics. Granted, there's almost
never is the reason to catch Throwable, but if you already do, you'd be
in for a nasty surprise.

> Throwable (convert to abstract class)
> \-> Exception
> \-> Error
> \-> ExitThrowable
> 
> This does mean though that existing code using catch(Throwable) is going to
> catch exit()s as well. This can be avoided by introducing *yet another*
> super-class/interface above Throwable, which is something I'd rather avoid.

If you want to do weird things - like have exception that it's really
not an exception - you'd have weird hierarchy. Either that, or you make
existing hierarchy weird, which existing code (and virtually everybody
writing new code) does not expect. I think theoretical weirdness is
better than nasty surprise for the practical users - which would either
have to insert instanceof checks into their catches, or deal with exit()
behaving wrongly.

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

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

Re: [PHP-DEV] Warning for "confusable" types

[Bishop Bettini]

On Fri, Oct 11, 2019 at 1:47 PM Larry Garfield 
wrote:

> On Fri, Oct 11, 2019, at 8:54 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > Something I've seen play out a couple of times: Newbies try to use
> > something like "integer" or "resource" as a type, and then get a
> confusing
> > error message along the lines of "must be an instance of resource,
> resource
> > given".
> >
> > I would like to throw a compiler warning in this case, that looks as one
> of
> > the following:
> >
> > > Warning: "integer" will be interpreted as a class type. Did you mean
> > "int"? Use qualified name or "use" to suppress this warning
> >
> > > Warning: "resource" is not a supported builtin type and will be
> > interpreted as a class type. Use qualified name or "use" to suppress this
> > warning
> >
> > This warning only triggers if the type is lowercase (integer but not
> > Integer), is unqualified (integer but not \integer) and is not imported
> > (there is no "use integer"). This provides multiple ways to avoid the
> > warning for code that does legitimately want to use lowercase "integer"
> as
> > a class type.
> >
> > Implementation: https://github.com/php/php-src/pull/4815
> >
> > Thoughts?
> >
> > Nikita
>
> Can you clarify where exactly "compiler warning" would be displayed?  Is
> that an E_WARNING?  How would I as a user see a message when I write
>
> function foo(integer $a) { ... }
>

It's an E_COMPILE_WARNING, and arises when the compiler sees you're type
hinting for a class, but no such class loaded. This checks that given class
against a known list of "probable mistakes" and provides guidance. Eg, I
typed "integer $a" when I mean "int $a", and don't understand the current
compiler warning: "Argument 1 passed to foo must be an instance of integer,
int given"

See also https://stackoverflow.com/a/40638544/2908724

Re: [PHP-DEV] exit() via exception

[Olumide Samson]

I'm thinking exit() shouldn't be catchable to maintain status quo, and it
should be focused on the reason it was suggested(Unwinding stacks and
cleaning up memories instead of longjmp'ing to shutdown).

If there's any need to catch it's exception, that can be handled later
through maybe a RFC discussion.

This can be implemented directly without having any user land interaction
since the throwing and catching can't be caught by any user land
code(top-most hierarchy without possibility to be caught, which might
result in compile time error).

All the best

Re: [PHP-DEV] exit() via exception

[Bishop Bettini]

On Fri, Oct 11, 2019 at 10:11 AM Nikita Popov  wrote:

> On Fri, Oct 11, 2019 at 3:47 PM Marcio Almada 
> wrote:
>
> > Em sex, 11 de out de 2019 às 08:05, Nikita Popov
> >  escreveu:
> >
> > > Currently exit() is implemented using bailout and unclean shutdown,
> which
> > > means that we're going to perform a longjmp back to the top-level scope
> > and
> > > let the memory manager clean up all the memory it knows about. Anything
> > not
> > > allocated using ZMM is going to leak persistently.
> > >
> > > For me, one of the most annoying things about this is that we can't
> > perform
> > > proper leak checks on code using PhpUnit, because it will always exit()
> > at
> > > the end, which will result in "expected" memory leaks.
> > >
> > > I think it would be good to switch exit() to work by throwing a magic
> > > exception, similar to what Python does. This would allow us to properly
> > > unwind the stack, executing finally blocks (which are currently
> skipped)
> > > and perform a clean engine shutdown.
> > >
> > > Depending on the implementation, we could also allow code to actually
> > catch
> > > this exception, which may be useful for testing scenarios, as well as
> > > long-running daemons.
> > >
> > > I'm mainly wondering how exactly we'd go about integrating this in the
> > > existing exception hierarchy.
> >
> > > Assuming that it is desirable to allow people
> > > to actually catch this exception
> > > my first thought would be along these
> > > lines:
> > >
> > > Throwable (convert to abstract class)
> > > \-> Exception
> > > \-> Error
> > > \-> ExitThrowable
> > >
> > > This does mean though that existing code using catch(Throwable) is
> going
> > to
> > > catch exit()s as well. This can be avoided by introducing *yet another*
> > > super-class/interface above Throwable, which is something I'd rather
> > avoid.
> > >
> >
> > Since you brought python as inspiration, I believe the hierarchy goes
> > like this on their land:
> >
> > BaseException
> >  +-- SystemExit
> >  +-- KeyboardInterrupt
> >  +-- GeneratorExit
> >  +-- Exception
> >  +-- [kitchen sink]
> >
> > Being `BaseException` the base class for all built-in exceptions. It
> > is not meant to be directly
> > inherited by user-defined classes. It 's the equivalent to our
> > `Throwable` situation. In this context
> > `ExitThrowable -> Throwable ` appears legit.
> >
> > >
> > > Anyone have thoughts on this matter?
> > >
> >
> > Yes. There is an obvious can of worms if I've got this right: `exit()`
> > and `die()` would no longer guarantee a
> > program to actually terminate in case catching `ExitThrowable` is
> > allowed. Python solves this by actually
> > having two patterns:
> >
> > 1. `quit()`, `exit()`, `sys.exit()` are the equivalent to `raise
> > SystemExit`, can be caught / interrupted
> > 2. `os._exit()`, can't be caught but has a callback mechanism like our
> > `register_shutdown_function`,
> > see https://docs.python.org/3/library/atexit.html
>
>
> I don't believe atexit applies to os._exit(). In any case, I agree that
> this is something we're currently missing -- we should probably add a
> pcntl_exit() for this purpose. It should be noted though that this is
> really very different from exit(), which is still quite graceful and usable
> in a webserver context, while a hypothetical pcntl_exit() would bring down
> the server process. As the Python docs mention, the primary use-case would
> be exiting from forked processes without going through shutdown, which has
> also recently come up in https://github.com/php/php-src/pull/4712.
>
>
> > If we bind `exit()` and `die()` to a catchable exception how would we
> > still have the scenario 2 available
> > on PHP land without a BCB? :)
> >
>
> > I have one simple suggestion: Introduce `EngineShutdown -> Throwable`,
> > bind `exit|die` to it but disallow
> > `catch(\EngineShutdown $e)` at compile time. This would allow keeping
> > backwards compatibility to
> > scenario 2 without messing with our current exception hierarchy.
> >
>
> I think the options are basically:
>
> 1. Making EngineShutdown implement Throwable, which would make existing
> catch(Throwable) catch it -- probably a no-go.
>
> 2. Making EngineShutdown not implement Throwable, which means that not all
> "exceptions" implement the interface, which is rather odd. It still allows
> explicitly catching the exit.
>
> 3. Introducing a function like catch_exit(function() { ... }). This would
> still allow catching exits (for phpunit + daemon use cases), but the fact
> that this is actually implemented based on an exception would be hidden and
> the only way to catch the exit is through this function.
>
> 4. Don't allow catching exits at all. In this case the exception is just an
> implementation detail.
>

5. A new branch in the try...catch...finally model, which signals your
willingness to handle a fatal pathway:

 printf("...shutdown"));
try {
exit(13);
} catch (Throwable $t) {
printf("caught %d at %s:%d", 

Re: [PHP-DEV] Warning for "confusable" types

[Olumide Samson]

On Fri, Oct 11, 2019, 6:47 PM Larry Garfield  wrote:

> On Fri, Oct 11, 2019, at 8:54 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > Something I've seen play out a couple of times: Newbies try to use
> > something like "integer" or "resource" as a type, and then get a
> confusing
> > error message along the lines of "must be an instance of resource,
> resource
> > given".
> >
> > I would like to throw a compiler warning in this case, that looks as one
> of
> > the following:
> >
> > > Warning: "integer" will be interpreted as a class type. Did you mean
> > "int"? Use qualified name or "use" to suppress this warning
> >
> > > Warning: "resource" is not a supported builtin type and will be
> > interpreted as a class type. Use qualified name or "use" to suppress this
> > warning
> >
> > This warning only triggers if the type is lowercase (integer but not
> > Integer), is unqualified (integer but not \integer) and is not imported
> > (there is no "use integer"). This provides multiple ways to avoid the
> > warning for code that does legitimately want to use lowercase "integer"
> as
> > a class type.
> >
> > Implementation: https://github.com/php/php-src/pull/4815
> >
> > Thoughts?
> >
> > Nikita
>
> Can you clarify where exactly "compiler warning" would be displayed?  Is
> that an E_WARNING?  How would I as a user see a message when I write
>
> function foo(integer $a) { ... }
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


As a warning I think, seems I've encountered those errors many times ago.

The solution Nikita propose is good, it doesn't deal with too much.

These errors are there already, only just giving it a properly meaningful
description.

+1 for the proposed description.

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

Sure, sorry about that. I'm done with the silliness as we at an impasse.


Walter

On Fri, Oct 11, 2019 at 10:45 AM Larry Garfield 
wrote:

>
> On Fri, Oct 11, 2019, at 1:53 AM, Stephen Reay wrote:
> >
> >
> > > On 11 Oct 2019, at 13:42, Walter Parker  wrote:
> > >
> > >
> > >
> > > On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay 
> wrote:
> > >
> > >
> > > > On 11 Oct 2019, at 12:40, Walter Parker  wrote:
> > > >
> > > > G
> > > >
> > > > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay <
> step...@koalephant.com>
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >>> On 11 Oct 2019, at 02:59, Walter Parker  wrote:
> > > >>>
> > > >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <
> chasepee...@gmail.com>
>
> You know, I specifically pulled my comment out to a new subject line to
> respond very specifically to Zeev's "the other side" comment.  I
> specifically tried to separate it from everyone talking past each other
> about a nitpicky issue that is only a topic of major discussion because
> it's being used as a proxy war for larger issues.
>
> Could y'all please go fight about analogies in another thread, rather than
> one that was explicitly trying to get away from that silliness?  Much
> obliged.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] Warning for "confusable" types

[Larry Garfield]

On Fri, Oct 11, 2019, at 8:54 AM, Nikita Popov wrote:
> Hi internals,
> 
> Something I've seen play out a couple of times: Newbies try to use
> something like "integer" or "resource" as a type, and then get a confusing
> error message along the lines of "must be an instance of resource, resource
> given".
> 
> I would like to throw a compiler warning in this case, that looks as one of
> the following:
> 
> > Warning: "integer" will be interpreted as a class type. Did you mean
> "int"? Use qualified name or "use" to suppress this warning
> 
> > Warning: "resource" is not a supported builtin type and will be
> interpreted as a class type. Use qualified name or "use" to suppress this
> warning
> 
> This warning only triggers if the type is lowercase (integer but not
> Integer), is unqualified (integer but not \integer) and is not imported
> (there is no "use integer"). This provides multiple ways to avoid the
> warning for code that does legitimately want to use lowercase "integer" as
> a class type.
> 
> Implementation: https://github.com/php/php-src/pull/4815
> 
> Thoughts?
> 
> Nikita

Can you clarify where exactly "compiler warning" would be displayed?  Is that 
an E_WARNING?  How would I as a user see a message when I write

function foo(integer $a) { ... }

--Larry Garfield

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

Re: [PHP-DEV] Internals "camps"

[Larry Garfield]

On Fri, Oct 11, 2019, at 1:53 AM, Stephen Reay wrote:
> 
> 
> > On 11 Oct 2019, at 13:42, Walter Parker  wrote:
> > 
> > 
> > 
> > On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay  
> > wrote:
> > 
> > 
> > > On 11 Oct 2019, at 12:40, Walter Parker  wrote:
> > > 
> > > G
> > > 
> > > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay 
> > > wrote:
> > > 
> > >> 
> > >> 
> > >>> On 11 Oct 2019, at 02:59, Walter Parker  wrote:
> > >>> 
> > >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler 

You know, I specifically pulled my comment out to a new subject line to respond 
very specifically to Zeev's "the other side" comment.  I specifically tried to 
separate it from everyone talking past each other about a nitpicky issue that 
is only a topic of major discussion because it's being used as a proxy war for 
larger issues.

Could y'all please go fight about analogies in another thread, rather than one 
that was explicitly trying to get away from that silliness?  Much obliged.

--Larry Garfield

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

Re: [PHP-DEV] exit() via exception

[Aaron Piotrowski]

> On Oct 11, 2019, at 10:21 AM, Nikita Popov  > wrote:
> 
>> Hi!
>> 
>> So maybe it narrows down to:
>> 
>> Is there an essencial attempt to improve `exit()` handling from the
>> userland perspective or should the focus be solely on solving the
>> memory management issue pointed out in the beginning of the thread?
>> 
>> If the scope is to also improve userland, option 3 could be the way to
>> go indeed but I confess to do not be a fan of another callback
>> registering thing... it feels hard to predict when you consider:
>> 
>> ```
>> catch_exit(function(){
>>exit(); // what happens here? We still have to guarantee `exit` to
>> halt at some point.
>> });
>> ```
>> 
>> And what are the interactions with `register_shutdown_function`? I
>> suppose the `catch_exit` stack has to be run before the
>> `register_shutdown_function` stack? Considering the behavior in the
>> docs.
>> 
> 
> I think I was a bit unclear in how the catch_exit() function is intended to
> work: It's not an atexit handler, it's basically a try/catch block for
> exits.
> 
> $exitExceptionOrNull = catch_exit(function() {
>// Run code that may contain exit() here
> });
> 
> or possibly even more explicitly as:
> 
> catch_exit(function() {
>// Run code that may contain exit() here
> }, function($exitCode, $exitMessage) {
>// This is called if an exit() occurred
> });

The second option seems better, as it's a lot more obvious what code will be 
executed if exit() is called and what will not be.

Would a set_exit_handler function be possible, similar to set_exception_handler?

> 
> I like option 4 much more for now. It allows tackling the root issue
>> and still leaves possibilities open regarding how the exception
>> hierarchy could be and how the handling of `exit` could happen
>> (through a catch at userspace or callback registering).
>> 
> 
> I guess we should do that as the first step in any case ... everything else
> would be extensions on top of that, but this would be the main technical
> groundwork.
> 
> Nikita

Option 4 of course would be fine for now. Once that's done, we can decide how 
exits could be "caught" in the future.


> On Fri, Oct 11, 2019 at 5:13 PM Marcio Almada  > wrote:
> 
>>> 
>>> EngineShutdown could be a special exception to the engine, being handled
>> like an exception internally, but not implement Throwable and therefore not
>> an exception from user-land's point-of-view.
>>> 
>>> EngineShutdown could be added to the list of "throwables", but forbid
>> instigation in user-land.
>>> 
>> https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
>>  
>> 
>>> 
>>> No catch block would catch it, because it wouldn't implement Throwable
>> nor extend Exception or Error.
>>> 
>> 
>> Very elegant solution!
>> 
>> PS: Naming things is hard, but `Throwable` could not have been a
>> better choice in retrospect. Ty ;)

Thanks! Every once-in-a-while I manage to name something correctly!

>> 
>>> Aaron Piotrowski
>>> 
>> 
>> Márcio

Aaron Piotrowski

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

[Claude Pache]

> Le 11 oct. 2019 à 11:12, Olumide Samson  a écrit :
> 
> On Fri, Oct 11, 2019, 9:29 AM Benjamin Morel 
> wrote:
> 
>>> 
>>> As people have expressed interest in hearing about direct technical
>>> benefits that these kinds of changes have ... let me give you an example
>>> that came up yesterday.
>> 
>> 
>> 
>> Too bad this example comes after the vote has been made, and failed.
>> This would be a very strong argument in favour of using exceptions
>> everywhere in the next major version: codebase cleanup, room for more
>> optimization.
>> 
>> Nikita, please fork PHP, we'll follow you ;-)
>> 
>> — Benjamin
>> 
> 
> I think I'm always available to contribute to a fork of a better PHP, coz I
> love the syntax not the garbages included in the current one.

If you’re seeking a fork of PHP that wilfully breaks BC for the sake of cleanup 
and optimisation, you should seriously consider Hack. Although I don’t know 
whether they’ve already removed support of the appalling implicit 
initialisation of  variables to `null`, or of the dreadful backtick operator, 
you’ll be delighted to learn that they’re on the process of removing 
references, PHP arrays (in favour of Hack arrays and collections), and even 
that little pesky `https://hhvm.com/blog/2019/02/11/hhvm-4.0.0.html 


Enjoy. (But not with me: our company does not have the budget to migrate 30 Mo 
of code without counting external libraries.)

—Claude

Re: [PHP-DEV] exit() via exception

[Bruce Weirdan]

On Fri, Oct 11, 2019 at 2:43 PM Andreas Hennings  wrote:

> What other use cases exist for exit()?

Setting exit code for cli scripts.

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

Re: [PHP-DEV] exit() via exception

[Nikita Popov]

On Fri, Oct 11, 2019 at 5:13 PM Marcio Almada  wrote:

> Hi!
>
> > > I don't believe atexit applies to os._exit(). In any case, I agree that
> > > this is something we're currently missing -- we should probably add a
> > > pcntl_exit() for this purpose. It should be noted though that this is
> > > really very different from exit(), which is still quite graceful and
> usable
> > > in a webserver context, while a hypothetical pcntl_exit() would bring
> down
> > > the server process. As the Python docs mention, the primary use-case
> would
> > > be exiting from forked processes without going through shutdown, which
> has
> > > also recently come up in https://github.com/php/php-src/pull/4712.
> > >
> > >
> > >> If we bind `exit()` and `die()` to a catchable exception how would we
> > >> still have the scenario 2 available
> > >> on PHP land without a BCB? :)
> > >>
> > >
> > >> I have one simple suggestion: Introduce `EngineShutdown -> Throwable`,
> > >> bind `exit|die` to it but disallow
> > >> `catch(\EngineShutdown $e)` at compile time. This would allow keeping
> > >> backwards compatibility to
> > >> scenario 2 without messing with our current exception hierarchy.
> > >>
> > >
> > > I think the options are basically:
> > >
> > > 1. Making EngineShutdown implement Throwable, which would make existing
> > > catch(Throwable) catch it -- probably a no-go.
> > >
> > > 2. Making EngineShutdown not implement Throwable, which means that not
> all
> > > "exceptions" implement the interface, which is rather odd. It still
> allows
> > > explicitly catching the exit.
> > >
> > > 3. Introducing a function like catch_exit(function() { ... }). This
> would
> > > still allow catching exits (for phpunit + daemon use cases), but the
> fact
> > > that this is actually implemented based on an exception would be
> hidden and
> > > the only way to catch the exit is through this function.
> > >
> > > 4. Don't allow catching exits at all. In this case the exception is
> just an
> > > implementation detail.
> > >
> > > Nikita
> >
> > +1 for option 3.
>
> So maybe it narrows down to:
>
> Is there an essencial attempt to improve `exit()` handling from the
> userland perspective or should the focus be solely on solving the
> memory management issue pointed out in the beginning of the thread?
>
> If the scope is to also improve userland, option 3 could be the way to
> go indeed but I confess to do not be a fan of another callback
> registering thing... it feels hard to predict when you consider:
>
> ```
> catch_exit(function(){
> exit(); // what happens here? We still have to guarantee `exit` to
> halt at some point.
> });
> ```
>
> And what are the interactions with `register_shutdown_function`? I
> suppose the `catch_exit` stack has to be run before the
> `register_shutdown_function` stack? Considering the behavior in the
> docs.
>

I think I was a bit unclear in how the catch_exit() function is intended to
work: It's not an atexit handler, it's basically a try/catch block for
exits.

$exitExceptionOrNull = catch_exit(function() {
// Run code that may contain exit() here
});

or possibly even more explicitly as:

catch_exit(function() {
// Run code that may contain exit() here
}, function($exitCode, $exitMessage) {
// This is called if an exit() occurred
});

I like option 4 much more for now. It allows tackling the root issue
> and still leaves possibilities open regarding how the exception
> hierarchy could be and how the handling of `exit` could happen
> (through a catch at userspace or callback registering).
>

I guess we should do that as the first step in any case ... everything else
would be extensions on top of that, but this would be the main technical
groundwork.

Nikita


> >
> > EngineShutdown could be a special exception to the engine, being handled
> like an exception internally, but not implement Throwable and therefore not
> an exception from user-land's point-of-view.
> >
> > EngineShutdown could be added to the list of "throwables", but forbid
> instigation in user-land.
> >
> https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
> >
> > No catch block would catch it, because it wouldn't implement Throwable
> nor extend Exception or Error.
> >
>
> Very elegant solution!
>
> PS: Naming things is hard, but `Throwable` could not have been a
> better choice in retrospect. Ty ;)
>
> > Aaron Piotrowski
> >
>
> Márcio
>

[PHP-DEV] Re: Migration tooling and the cumulative cost of purely syntactical deprecations

[Mark Randall]

On 11/10/2019 11:25, Nikita Popov wrote:

Purely syntactical deprecations, such as the recently discussed case of
backticks, but also the already accepted deprecations of the "alternative
array access syntax" and the (real) cast, can be performed automatically
and with perfect reliability.


I imagine it would allow immediately crossing off a few points of 
confusion such as these casts:


(unset)
(integer)
(boolean)
(double)
(real)


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

Re: [PHP-DEV] exit() via exception

[Marcio Almada]

Hi!

> > I don't believe atexit applies to os._exit(). In any case, I agree that
> > this is something we're currently missing -- we should probably add a
> > pcntl_exit() for this purpose. It should be noted though that this is
> > really very different from exit(), which is still quite graceful and usable
> > in a webserver context, while a hypothetical pcntl_exit() would bring down
> > the server process. As the Python docs mention, the primary use-case would
> > be exiting from forked processes without going through shutdown, which has
> > also recently come up in https://github.com/php/php-src/pull/4712.
> >
> >
> >> If we bind `exit()` and `die()` to a catchable exception how would we
> >> still have the scenario 2 available
> >> on PHP land without a BCB? :)
> >>
> >
> >> I have one simple suggestion: Introduce `EngineShutdown -> Throwable`,
> >> bind `exit|die` to it but disallow
> >> `catch(\EngineShutdown $e)` at compile time. This would allow keeping
> >> backwards compatibility to
> >> scenario 2 without messing with our current exception hierarchy.
> >>
> >
> > I think the options are basically:
> >
> > 1. Making EngineShutdown implement Throwable, which would make existing
> > catch(Throwable) catch it -- probably a no-go.
> >
> > 2. Making EngineShutdown not implement Throwable, which means that not all
> > "exceptions" implement the interface, which is rather odd. It still allows
> > explicitly catching the exit.
> >
> > 3. Introducing a function like catch_exit(function() { ... }). This would
> > still allow catching exits (for phpunit + daemon use cases), but the fact
> > that this is actually implemented based on an exception would be hidden and
> > the only way to catch the exit is through this function.
> >
> > 4. Don't allow catching exits at all. In this case the exception is just an
> > implementation detail.
> >
> > Nikita
>
> +1 for option 3.

So maybe it narrows down to:

Is there an essencial attempt to improve `exit()` handling from the
userland perspective or should the focus be solely on solving the
memory management issue pointed out in the beginning of the thread?

If the scope is to also improve userland, option 3 could be the way to
go indeed but I confess to do not be a fan of another callback
registering thing... it feels hard to predict when you consider:

```
catch_exit(function(){
exit(); // what happens here? We still have to guarantee `exit` to
halt at some point.
});
```

And what are the interactions with `register_shutdown_function`? I
suppose the `catch_exit` stack has to be run before the
`register_shutdown_function` stack? Considering the behavior in the
docs.

I like option 4 much more for now. It allows tackling the root issue
and still leaves possibilities open regarding how the exception
hierarchy could be and how the handling of `exit` could happen
(through a catch at userspace or callback registering).

>
> EngineShutdown could be a special exception to the engine, being handled like 
> an exception internally, but not implement Throwable and therefore not an 
> exception from user-land's point-of-view.
>
> EngineShutdown could be added to the list of "throwables", but forbid 
> instigation in user-land.
> https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
>
> No catch block would catch it, because it wouldn't implement Throwable nor 
> extend Exception or Error.
>

Very elegant solution!

PS: Naming things is hard, but `Throwable` could not have been a
better choice in retrospect. Ty ;)

> Aaron Piotrowski
>

Márcio

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

Re: [PHP-DEV] exit() via exception

[Aaron Piotrowski]

> On Oct 11, 2019, at 9:11 AM, Nikita Popov  wrote:
> 
> On Fri, Oct 11, 2019 at 3:47 PM Marcio Almada  wrote:
> 
>> Em sex, 11 de out de 2019 às 08:05, Nikita Popov
>>  escreveu:
>>> 
>>> Hi,
>>> 
>> 
>> Hello :)
>> 
>>> Currently exit() is implemented using bailout and unclean shutdown, which
>>> means that we're going to perform a longjmp back to the top-level scope
>> and
>>> let the memory manager clean up all the memory it knows about. Anything
>> not
>>> allocated using ZMM is going to leak persistently.
>>> 
>>> For me, one of the most annoying things about this is that we can't
>> perform
>>> proper leak checks on code using PhpUnit, because it will always exit()
>> at
>>> the end, which will result in "expected" memory leaks.
>>> 
>>> I think it would be good to switch exit() to work by throwing a magic
>>> exception, similar to what Python does. This would allow us to properly
>>> unwind the stack, executing finally blocks (which are currently skipped)
>>> and perform a clean engine shutdown.
>>> 
>>> Depending on the implementation, we could also allow code to actually
>> catch
>>> this exception, which may be useful for testing scenarios, as well as
>>> long-running daemons.
>>> 
>>> I'm mainly wondering how exactly we'd go about integrating this in the
>>> existing exception hierarchy.
>> 
>>> Assuming that it is desirable to allow people
>>> to actually catch this exception
>>> my first thought would be along these
>>> lines:
>>> 
>>> Throwable (convert to abstract class)
>>> \-> Exception
>>> \-> Error
>>> \-> ExitThrowable
>>> 
>>> This does mean though that existing code using catch(Throwable) is going
>> to
>>> catch exit()s as well. This can be avoided by introducing *yet another*
>>> super-class/interface above Throwable, which is something I'd rather
>> avoid.
>>> 
>> 
>> Since you brought python as inspiration, I believe the hierarchy goes
>> like this on their land:
>> 
>> BaseException
>> +-- SystemExit
>> +-- KeyboardInterrupt
>> +-- GeneratorExit
>> +-- Exception
>> +-- [kitchen sink]
>> 
>> Being `BaseException` the base class for all built-in exceptions. It
>> is not meant to be directly
>> inherited by user-defined classes. It 's the equivalent to our
>> `Throwable` situation. In this context
>> `ExitThrowable -> Throwable ` appears legit.
>> 
>>> 
>>> Anyone have thoughts on this matter?
>>> 
>> 
>> Yes. There is an obvious can of worms if I've got this right: `exit()`
>> and `die()` would no longer guarantee a
>> program to actually terminate in case catching `ExitThrowable` is
>> allowed. Python solves this by actually
>> having two patterns:
>> 
>> 1. `quit()`, `exit()`, `sys.exit()` are the equivalent to `raise
>> SystemExit`, can be caught / interrupted
>> 2. `os._exit()`, can't be caught but has a callback mechanism like our
>> `register_shutdown_function`,
>> see https://docs.python.org/3/library/atexit.html
> 
> 
> I don't believe atexit applies to os._exit(). In any case, I agree that
> this is something we're currently missing -- we should probably add a
> pcntl_exit() for this purpose. It should be noted though that this is
> really very different from exit(), which is still quite graceful and usable
> in a webserver context, while a hypothetical pcntl_exit() would bring down
> the server process. As the Python docs mention, the primary use-case would
> be exiting from forked processes without going through shutdown, which has
> also recently come up in https://github.com/php/php-src/pull/4712.
> 
> 
>> If we bind `exit()` and `die()` to a catchable exception how would we
>> still have the scenario 2 available
>> on PHP land without a BCB? :)
>> 
> 
>> I have one simple suggestion: Introduce `EngineShutdown -> Throwable`,
>> bind `exit|die` to it but disallow
>> `catch(\EngineShutdown $e)` at compile time. This would allow keeping
>> backwards compatibility to
>> scenario 2 without messing with our current exception hierarchy.
>> 
> 
> I think the options are basically:
> 
> 1. Making EngineShutdown implement Throwable, which would make existing
> catch(Throwable) catch it -- probably a no-go.
> 
> 2. Making EngineShutdown not implement Throwable, which means that not all
> "exceptions" implement the interface, which is rather odd. It still allows
> explicitly catching the exit.
> 
> 3. Introducing a function like catch_exit(function() { ... }). This would
> still allow catching exits (for phpunit + daemon use cases), but the fact
> that this is actually implemented based on an exception would be hidden and
> the only way to catch the exit is through this function.
> 
> 4. Don't allow catching exits at all. In this case the exception is just an
> implementation detail.
> 
> Nikita

+1 for option 3.

EngineShutdown could be a special exception to the engine, being handled like 
an exception internally, but not implement Throwable and therefore not an 
exception from user-land's point-of-view.

EngineShutdown could be added to the list of "throwables", but 

Re: [PHP-DEV] exit() via exception

[Nikita Popov]

On Fri, Oct 11, 2019 at 3:47 PM Marcio Almada  wrote:

> Em sex, 11 de out de 2019 às 08:05, Nikita Popov
>  escreveu:
> >
> > Hi,
> >
>
> Hello :)
>
> > Currently exit() is implemented using bailout and unclean shutdown, which
> > means that we're going to perform a longjmp back to the top-level scope
> and
> > let the memory manager clean up all the memory it knows about. Anything
> not
> > allocated using ZMM is going to leak persistently.
> >
> > For me, one of the most annoying things about this is that we can't
> perform
> > proper leak checks on code using PhpUnit, because it will always exit()
> at
> > the end, which will result in "expected" memory leaks.
> >
> > I think it would be good to switch exit() to work by throwing a magic
> > exception, similar to what Python does. This would allow us to properly
> > unwind the stack, executing finally blocks (which are currently skipped)
> > and perform a clean engine shutdown.
> >
> > Depending on the implementation, we could also allow code to actually
> catch
> > this exception, which may be useful for testing scenarios, as well as
> > long-running daemons.
> >
> > I'm mainly wondering how exactly we'd go about integrating this in the
> > existing exception hierarchy.
>
> > Assuming that it is desirable to allow people
> > to actually catch this exception
> > my first thought would be along these
> > lines:
> >
> > Throwable (convert to abstract class)
> > \-> Exception
> > \-> Error
> > \-> ExitThrowable
> >
> > This does mean though that existing code using catch(Throwable) is going
> to
> > catch exit()s as well. This can be avoided by introducing *yet another*
> > super-class/interface above Throwable, which is something I'd rather
> avoid.
> >
>
> Since you brought python as inspiration, I believe the hierarchy goes
> like this on their land:
>
> BaseException
>  +-- SystemExit
>  +-- KeyboardInterrupt
>  +-- GeneratorExit
>  +-- Exception
>  +-- [kitchen sink]
>
> Being `BaseException` the base class for all built-in exceptions. It
> is not meant to be directly
> inherited by user-defined classes. It 's the equivalent to our
> `Throwable` situation. In this context
> `ExitThrowable -> Throwable ` appears legit.
>
> >
> > Anyone have thoughts on this matter?
> >
>
> Yes. There is an obvious can of worms if I've got this right: `exit()`
> and `die()` would no longer guarantee a
> program to actually terminate in case catching `ExitThrowable` is
> allowed. Python solves this by actually
> having two patterns:
>
> 1. `quit()`, `exit()`, `sys.exit()` are the equivalent to `raise
> SystemExit`, can be caught / interrupted
> 2. `os._exit()`, can't be caught but has a callback mechanism like our
> `register_shutdown_function`,
> see https://docs.python.org/3/library/atexit.html


I don't believe atexit applies to os._exit(). In any case, I agree that
this is something we're currently missing -- we should probably add a
pcntl_exit() for this purpose. It should be noted though that this is
really very different from exit(), which is still quite graceful and usable
in a webserver context, while a hypothetical pcntl_exit() would bring down
the server process. As the Python docs mention, the primary use-case would
be exiting from forked processes without going through shutdown, which has
also recently come up in https://github.com/php/php-src/pull/4712.


> If we bind `exit()` and `die()` to a catchable exception how would we
> still have the scenario 2 available
> on PHP land without a BCB? :)
>

> I have one simple suggestion: Introduce `EngineShutdown -> Throwable`,
> bind `exit|die` to it but disallow
> `catch(\EngineShutdown $e)` at compile time. This would allow keeping
> backwards compatibility to
> scenario 2 without messing with our current exception hierarchy.
>

I think the options are basically:

1. Making EngineShutdown implement Throwable, which would make existing
catch(Throwable) catch it -- probably a no-go.

2. Making EngineShutdown not implement Throwable, which means that not all
"exceptions" implement the interface, which is rather odd. It still allows
explicitly catching the exit.

3. Introducing a function like catch_exit(function() { ... }). This would
still allow catching exits (for phpunit + daemon use cases), but the fact
that this is actually implemented based on an exception would be hidden and
the only way to catch the exit is through this function.

4. Don't allow catching exits at all. In this case the exception is just an
implementation detail.

Nikita

Re: [PHP-DEV] exit() via exception

[Marcio Almada]

> I have one simple suggestion: Introduce `EngineShutdown -> Throwable`,
> bind `exit|die` to it but disallow
> `catch(\EngineShutdown $e)` at compile time. This would allow keeping
> backwards compatibility to
> scenario 2 without messing with our current exception hierarchy.
>
> > Nikita
>

Sorry, in the latest message I meant introducing `EngineShutdown` without
extending `Throwable`:

> Thanks,
> Márcio

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

[PHP-DEV] Warning for "confusable" types

[Nikita Popov]

Hi internals,

Something I've seen play out a couple of times: Newbies try to use
something like "integer" or "resource" as a type, and then get a confusing
error message along the lines of "must be an instance of resource, resource
given".

I would like to throw a compiler warning in this case, that looks as one of
the following:

> Warning: "integer" will be interpreted as a class type. Did you mean
"int"? Use qualified name or "use" to suppress this warning

> Warning: "resource" is not a supported builtin type and will be
interpreted as a class type. Use qualified name or "use" to suppress this
warning

This warning only triggers if the type is lowercase (integer but not
Integer), is unqualified (integer but not \integer) and is not imported
(there is no "use integer"). This provides multiple ways to avoid the
warning for code that does legitimately want to use lowercase "integer" as
a class type.

Implementation: https://github.com/php/php-src/pull/4815

Thoughts?

Nikita

Re: [PHP-DEV] exit() via exception

[Marcio Almada]

Em sex, 11 de out de 2019 às 08:05, Nikita Popov
 escreveu:
>
> Hi,
>

Hello :)

> Currently exit() is implemented using bailout and unclean shutdown, which
> means that we're going to perform a longjmp back to the top-level scope and
> let the memory manager clean up all the memory it knows about. Anything not
> allocated using ZMM is going to leak persistently.
>
> For me, one of the most annoying things about this is that we can't perform
> proper leak checks on code using PhpUnit, because it will always exit() at
> the end, which will result in "expected" memory leaks.
>
> I think it would be good to switch exit() to work by throwing a magic
> exception, similar to what Python does. This would allow us to properly
> unwind the stack, executing finally blocks (which are currently skipped)
> and perform a clean engine shutdown.
>
> Depending on the implementation, we could also allow code to actually catch
> this exception, which may be useful for testing scenarios, as well as
> long-running daemons.
>
> I'm mainly wondering how exactly we'd go about integrating this in the
> existing exception hierarchy.

> Assuming that it is desirable to allow people
> to actually catch this exception
> my first thought would be along these
> lines:
>
> Throwable (convert to abstract class)
> \-> Exception
> \-> Error
> \-> ExitThrowable
>
> This does mean though that existing code using catch(Throwable) is going to
> catch exit()s as well. This can be avoided by introducing *yet another*
> super-class/interface above Throwable, which is something I'd rather avoid.
>

Since you brought python as inspiration, I believe the hierarchy goes
like this on their land:

BaseException
 +-- SystemExit
 +-- KeyboardInterrupt
 +-- GeneratorExit
 +-- Exception
 +-- [kitchen sink]

Being `BaseException` the base class for all built-in exceptions. It
is not meant to be directly
inherited by user-defined classes. It 's the equivalent to our
`Throwable` situation. In this context
`ExitThrowable -> Throwable ` appears legit.

>
> Anyone have thoughts on this matter?
>

Yes. There is an obvious can of worms if I've got this right: `exit()`
and `die()` would no longer guarantee a
program to actually terminate in case catching `ExitThrowable` is
allowed. Python solves this by actually
having two patterns:

1. `quit()`, `exit()`, `sys.exit()` are the equivalent to `raise
SystemExit`, can be caught / interrupted
2. `os._exit()`, can't be caught but has a callback mechanism like our
`register_shutdown_function`,
see https://docs.python.org/3/library/atexit.html

If we bind `exit()` and `die()` to a catchable exception how would we
still have the scenario 2 available
on PHP land without a BCB? :)

I have one simple suggestion: Introduce `EngineShutdown -> Throwable`,
bind `exit|die` to it but disallow
`catch(\EngineShutdown $e)` at compile time. This would allow keeping
backwards compatibility to
scenario 2 without messing with our current exception hierarchy.

> Nikita

Thanks,
Márcio

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

Re: [PHP-DEV] exit() via exception

[Claude Pache]

> Le 11 oct. 2019 à 13:05, Nikita Popov  a écrit :
> 
> I'm mainly wondering how exactly we'd go about integrating this in the
> existing exception hierarchy. Assuming that it is desirable to allow people
> to actually catch this exception, my first thought would be along these
> lines:
> 
> Throwable (convert to abstract class)
> \-> Exception
> \-> Error
> \-> ExitThrowable
> 
> This does mean though that existing code using catch(Throwable) is going to
> catch exit()s as well. This can be avoided by introducing *yet another*
> super-class/interface above Throwable, which is something I'd rather avoid.


We should keep the semantics of `exit`, which is quite akin an early `return` 
in a function. Therefore:

* Executing finally blocks (as does an early `return`) would be an improvement.

* But intercepting it in a `catch` block or in an exception handler, is usually 
unwanted, contrarily to everything that currently implements `Throwable`.

But if you do want to allow exit signals to be caught in catch blocks, there is 
no absolute necessity to introduce yet another superclass or superinterface, 
because you can write (since PHP 7.1): 

catch (\Throwable | \ExitSignal $e)

—Claude

Re: [PHP-DEV] exit() via exception

[Sebastian Bergmann]

Am 11.10.2019 um 13:05 schrieb Nikita Popov:

Depending on the implementation, we could also allow code to actually catch
this exception, which may be useful for testing scenarios, as well as
long-running daemons.


This sounds interesting :)


Anyone have thoughts on this matter?


I think \Throwable should always include all objects that can be used with 
throw and catch.


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

Re: [PHP-DEV] Re: exit() via exception

[Andreas Hennings]

What about a new keyword in addition to "catch"?
(exact keyword would be up for discussion)

try {
}
catchExit ($exit) {

}

Or, how far would we get if we do not make this catchable, and
(perhaps) not run any "finally" block?
Could this already solve some of the technical problems, without
breaking existing expectations?

On Fri, 11 Oct 2019 at 14:32, Mark Randall  wrote:
>
> On 11/10/2019 12:05, Nikita Popov wrote:
> > This does mean though that existing code using catch(Throwable) is going to
> > catch exit()s as well. This can be avoided by introducing *yet another*
> > super-class/interface above Throwable, which is something I'd rather avoid.
>
> If it is caught, could the exit() potentially be cancelled by not
> re-throwing it?
>
> What about a hidden catch block that is inserted at compiler level?
>
> try {
>exit();
> }
> catch (\Throwable) {
>...
> }
>
> Would become:
>
> try {
>exit();
> }
> catch (\ExitThrowable $ex) {
>throw $ex;
> }
> catch (\Throwable) {
>...
> }
>
> The hidden catch block would be overwritten with a user catch block if
> one existed that caught \ExitThrowable, and it would be *required* to
> re-throw it, otherwise it would be done automatically at the end of the
> code segment or upon encountering a return etc.
>
> It's obscure though, it hides things, and I don't think I like it.
>
> Adding another level of throwable is fugly, but it's by far the most
> initiative IMO. But take the initiative and prohibit it from being used
> by itself so we don't end up in the same position a few years down the line.
>
> try {
>
> }
> catch (\TopLevelThrowableForSureThisTime $ex) {
>
> }
>
> ^^ Compiler Error.
>
> Mark Randall
>
> --
> 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

[PHP-DEV] Re: exit() via exception

[Mark Randall]

On 11/10/2019 12:05, Nikita Popov wrote:

This does mean though that existing code using catch(Throwable) is going to
catch exit()s as well. This can be avoided by introducing *yet another*
super-class/interface above Throwable, which is something I'd rather avoid.


If it is caught, could the exit() potentially be cancelled by not 
re-throwing it?


What about a hidden catch block that is inserted at compiler level?

try {
  exit();
}
catch (\Throwable) {
  ...
}

Would become:

try {
  exit();
}
catch (\ExitThrowable $ex) {
  throw $ex;
}
catch (\Throwable) {
  ...
}

The hidden catch block would be overwritten with a user catch block if 
one existed that caught \ExitThrowable, and it would be *required* to 
re-throw it, otherwise it would be done automatically at the end of the 
code segment or upon encountering a return etc.


It's obscure though, it hides things, and I don't think I like it.

Adding another level of throwable is fugly, but it's by far the most 
initiative IMO. But take the initiative and prohibit it from being used 
by itself so we don't end up in the same position a few years down the line.


try {

}
catch (\TopLevelThrowableForSureThisTime $ex) {

}

^^ Compiler Error.

Mark Randall

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

Re: [PHP-DEV] Migration tooling and the cumulative cost of purely syntactical deprecations

[Andreas Hennings]

On Fri, 11 Oct 2019 at 12:25, Nikita Popov  wrote:
>
> Hi internals,
>
> One thing that I feel gets lost when discussion is spread over multiple
> proposals is the following fact:
>
> Purely syntactical deprecations, such as the recently discussed case of
> backticks, but also the already accepted deprecations of the "alternative
> array access syntax" and the (real) cast, can be performed automatically
> and with perfect reliability.
>
> Given a high-quality migration tool, the cost is running "php-migrate.phar
> dir/" and importantly (and this is the point I want to make) this cost is
> constant regardless of how many different things get deprecated. For this
> kind of tooling, it makes no difference whether it only has to replace the
> alternative array access syntax, or whether it also needs to replace
> backticks, some obscure variable interpolation syntax, or whatever else we
> want it to.
>
> As long as the deprecation is purely syntactical, this kind of migration
> tooling is reliable -- this certainly does not apply to all deprecations!
> For example, the also recently discussed case of undefined variables is not
> something that can be reliably migrated in an automated way (at least not
> while producing idiomatic code).
>
> Rather than starting a holy war over every single RFC that contains the
> word "deprecation", I think we should take a look at our migration story
> and possibly invest some effort into creating a "blessed" tool for this
> purpose: One that only performs migrations that are completely safe and
> should be runnable without fear of breaking code.
>
> I do realize that there is already quite a bit of existing tooling, things
> like Rector, various CS fixers and compatibility scanners, but I don't
> think that we have anything that just works out of the box to do what is
> safe and no more.
>
> If we provide this kind of tooling, I think that the cost/benefit
> calculation on deprecation changes: If we have any syntactic deprecations
> at all, then it basically doesn't matter how many different (syntactical)
> things get deprecated in one release, the migration cost is always going to
> be the same. (This is of course a slightly simplified view, but close
> enough.)

This does not really take 3rd party code into account.
(composer packages, wordpress plugins..)

What I could imagine is to let the package manager (e.g. composer) or
the package distribution portal (e.g. packagist) apply these automated
fixes to legacy packages and provide cleaned-up variations.
An "application developer" should not run clean-up scripts on 3rd
party code, unless this is automated and happens each time the 3rd
party code is updated.
And we should not assume that every 3rd party package author will take
the time to update their package.

>
> Nikita

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

Re: [PHP-DEV] exit() via exception

[Andreas Hennings]

I would think that whichever code currently calls exit() is already
expecting and accepting all the consequences, and assumes that this
won't ever be caught.

So, would it be an option to keep exit() as it is, and introduce a new
syntax construction?

Places where I have seen exit() were not really about exceptional
emergency situations, but rather a "finished" or "done".
E.g. "send headers, print ajax response, exit".
This may or may not be good practice, but it is something being done.

What other use cases exist for exit()?

> introducing *yet another* super-class/interface above Throwable, which is 
> something I'd rather avoid.

I don't see a way to avoid it ..
But if we are going to do this, we should think about whether we
really covered all cases, or if we need another layer in the future.

interface Throwable extends Catchable {}


On Fri, 11 Oct 2019 at 13:05, Nikita Popov  wrote:
>
> Hi,
>
> Currently exit() is implemented using bailout and unclean shutdown, which
> means that we're going to perform a longjmp back to the top-level scope and
> let the memory manager clean up all the memory it knows about. Anything not
> allocated using ZMM is going to leak persistently.
>
> For me, one of the most annoying things about this is that we can't perform
> proper leak checks on code using PhpUnit, because it will always exit() at
> the end, which will result in "expected" memory leaks.
>
> I think it would be good to switch exit() to work by throwing a magic
> exception, similar to what Python does. This would allow us to properly
> unwind the stack, executing finally blocks (which are currently skipped)
> and perform a clean engine shutdown.
>
> Depending on the implementation, we could also allow code to actually catch
> this exception, which may be useful for testing scenarios, as well as
> long-running daemons.
>
> I'm mainly wondering how exactly we'd go about integrating this in the
> existing exception hierarchy. Assuming that it is desirable to allow people
> to actually catch this exception, my first thought would be along these
> lines:
>
> Throwable (convert to abstract class)
> \-> Exception
> \-> Error
> \-> ExitThrowable
>
> This does mean though that existing code using catch(Throwable) is going to
> catch exit()s as well. This can be avoided by introducing *yet another*
> super-class/interface above Throwable, which is something I'd rather avoid.
>
> Anyone have thoughts on this matter?
>
> Nikita

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

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

[Andreas Hennings]

On Fri, 11 Oct 2019 at 10:18, Nikita Popov  wrote:
>
> On Thu, Sep 12, 2019 at 2: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
> >
>
> As people have expressed interest in hearing about direct technical
> benefits that these kinds of changes have ... let me give you an example
> that came up yesterday.
>
> Opcache performs a bunch of optimizations, and one class of optimizations
> it does are subsequent jumps on the same operand. For example:
>
> if ($x) { A; }
> if ($x) { B; }
>
> Currently, opcache will optimize the first if($x) condition to jump
> directly until after the second if($x) if the value is false, on the
> expectation that it is redundant to check the same condition twice in a
> row: The result is going to be the same. Basically the result is something
> like this:
>
> if ($x) { A; } else { goto end; }
> if ($x) { B; }
> end:
>
> Now, it turns out that this entire class of optimizations is technically
> illegal. Why? Because $x might be an undefined variable! That means that
> this optimization at the least loses an "undefined variable" notice, and at
> worse changes control flow:
>
> set_error_handler(function() {
> $GLOBALS['x'] = true;
> });
> if ($x) echo "foo\n";
> if ($x) echo "bar\n";

To be fair, the same problem would still apply for other code that
emits notices in an if condition, right?
Or does the opcache only optimize this for simple variables?

The "correct" behavior would be to analyse the code before the if(),
and only optimize if we are sure that $x will always be defined..

Otherwise, we would need to convert it to if ($x) {..} elseif
(variable_exists($x)) {goto end;}
Sadly there is currently no variable_exists() in php, and the above
code would probably lose the optimization benefit with the extra
logic.



>
> Because it's been around for years and doesn't seem to have caused any
> active issues, we're likely going to keep this, but nonetheless, it
> illustrates the kind of issue we see with these notices. Either an
> exception or nothing at all are fine, but notices caused problems.
>
> Of course there are also other problems, such as
> https://bugs.php.net/bug.php?id=78598, which is one of multiple
> use-after-free issues related to notices thrown during write operations.
> The root cause is that under the PHP memory model, it is not legal to run
> arbitrary user code while holding writable references into structures -- an
> invariant that is violated by some notices, such as the undefined array key
> one, because those notices may invoke error handlers. Again, either
> throwing nothing or throwing an exception would be unproblematic.
>
> Generally notices thrown by the engine are a pretty big pain to deal with,
> as well as something of a correctness and safety hazard. We have quite a
> few bugs in this area, though most of them are thankfully not likely to be
> hit by accident.
>
> Nikita

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

[PHP-DEV] exit() via exception

[Nikita Popov]

Hi,

Currently exit() is implemented using bailout and unclean shutdown, which
means that we're going to perform a longjmp back to the top-level scope and
let the memory manager clean up all the memory it knows about. Anything not
allocated using ZMM is going to leak persistently.

For me, one of the most annoying things about this is that we can't perform
proper leak checks on code using PhpUnit, because it will always exit() at
the end, which will result in "expected" memory leaks.

I think it would be good to switch exit() to work by throwing a magic
exception, similar to what Python does. This would allow us to properly
unwind the stack, executing finally blocks (which are currently skipped)
and perform a clean engine shutdown.

Depending on the implementation, we could also allow code to actually catch
this exception, which may be useful for testing scenarios, as well as
long-running daemons.

I'm mainly wondering how exactly we'd go about integrating this in the
existing exception hierarchy. Assuming that it is desirable to allow people
to actually catch this exception, my first thought would be along these
lines:

Throwable (convert to abstract class)
\-> Exception
\-> Error
\-> ExitThrowable

This does mean though that existing code using catch(Throwable) is going to
catch exit()s as well. This can be avoided by introducing *yet another*
super-class/interface above Throwable, which is something I'd rather avoid.

Anyone have thoughts on this matter?

Nikita

Re: [PHP-DEV] Migration tooling and the cumulative cost of purely syntactical deprecations

[Lester Caine]

On 11/10/2019 11:25, Nikita Popov wrote:

If we provide this kind of tooling, I think that the cost/benefit
calculation on deprecation changes: If we have any syntactic deprecations
at all, then it basically doesn't matter how many different (syntactical)
things get deprecated in one release, the migration cost is always going to
be the same. (This is of course a slightly simplified view, but close
enough.)


A practical example ...

I've just sorted out access to a new clients web hosting and fixed 
things so I can actually log into the wordpress admin panel. Since there 
has been no access since the previous support person who set up the site 
went awall there are a lot of messages to deal with. The first one being 
that PHP is out of date so wordpress can't upgrade. THAT is good to see 
since I already know that the site will be broken if it HAD simply 
updated as has happened on other sites! The question now is just what 
process to follow to update without taking the site off-line. This is 
not something the sites owner would ever be able to handle hence the 
request to help out ...


In the case of wordpress, the next problem is working out just what 
plugins are currently active, which ones will work if wordpress is 
updated, and which may need to be replaced. But the starting point is 
what will happen if I start by switching PHP5.5 to PHP5.6 so that 
wordpress can be updated at all. Should I simply move direct to 7.2 
which I have other wordpress sites running on and crib sheets to help 
fixing the problems I have already tracked.


None of this can be sorted by using tools that fix the raw code. The 
only route is via third party upgrades which relate to which version of 
PHP is running. *IF* php was a lot more stable when RUNNING older code 
then one COULD simply update the version and then play catch-up with 
other updates, but with the current situation, one often has to fix raw 
code problems to get the older stable site into a state that the upgrade 
process will actually work.


Bottom line ... can I justify a decent price for the time sorting all of 
this will take when there is no indication just how long it WILL take, 
and then what work will be required in addition to simply removing the 
nannying messages from wordpress ...


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

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

Re: [PHP-DEV] Migration tooling and the cumulative cost of purely syntactical deprecations

[Alain D D Williams]

On Fri, Oct 11, 2019 at 12:25:11PM +0200, Nikita Popov wrote:

> Rather than starting a holy war over every single RFC that contains the
> word "deprecation", I think we should take a look at our migration story
> and possibly invest some effort into creating a "blessed" tool for this
> purpose: One that only performs migrations that are completely safe and
> should be runnable without fear of breaking code.
> 
> I do realize that there is already quite a bit of existing tooling, things
> like Rector, various CS fixers and compatibility scanners, but I don't
> think that we have anything that just works out of the box to do what is
> safe and no more.

Could I suggest an option for it to point out where other (unsafe) migrations
could/should be done so that we know where to look.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

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

[PHP-DEV] Migration tooling and the cumulative cost of purely syntactical deprecations

[Nikita Popov]

Hi internals,

One thing that I feel gets lost when discussion is spread over multiple
proposals is the following fact:

Purely syntactical deprecations, such as the recently discussed case of
backticks, but also the already accepted deprecations of the "alternative
array access syntax" and the (real) cast, can be performed automatically
and with perfect reliability.

Given a high-quality migration tool, the cost is running "php-migrate.phar
dir/" and importantly (and this is the point I want to make) this cost is
constant regardless of how many different things get deprecated. For this
kind of tooling, it makes no difference whether it only has to replace the
alternative array access syntax, or whether it also needs to replace
backticks, some obscure variable interpolation syntax, or whatever else we
want it to.

As long as the deprecation is purely syntactical, this kind of migration
tooling is reliable -- this certainly does not apply to all deprecations!
For example, the also recently discussed case of undefined variables is not
something that can be reliably migrated in an automated way (at least not
while producing idiomatic code).

Rather than starting a holy war over every single RFC that contains the
word "deprecation", I think we should take a look at our migration story
and possibly invest some effort into creating a "blessed" tool for this
purpose: One that only performs migrations that are completely safe and
should be runnable without fear of breaking code.

I do realize that there is already quite a bit of existing tooling, things
like Rector, various CS fixers and compatibility scanners, but I don't
think that we have anything that just works out of the box to do what is
safe and no more.

If we provide this kind of tooling, I think that the cost/benefit
calculation on deprecation changes: If we have any syntactic deprecations
at all, then it basically doesn't matter how many different (syntactical)
things get deprecated in one release, the migration cost is always going to
be the same. (This is of course a slightly simplified view, but close
enough.)

Nikita

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

[Olumide Samson]

On Fri, Oct 11, 2019, 9:29 AM Benjamin Morel 
wrote:

> >
> > As people have expressed interest in hearing about direct technical
> > benefits that these kinds of changes have ... let me give you an example
> > that came up yesterday.
>
>
>
> Too bad this example comes after the vote has been made, and failed.
> This would be a very strong argument in favour of using exceptions
> everywhere in the next major version: codebase cleanup, room for more
> optimization.
>
> Nikita, please fork PHP, we'll follow you ;-)
>
> — Benjamin
>

I think I'm always available to contribute to a fork of a better PHP, coz I
love the syntax not the garbages included in the current one.

>

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

[Benjamin Morel]

>
> As people have expressed interest in hearing about direct technical
> benefits that these kinds of changes have ... let me give you an example
> that came up yesterday.



Too bad this example comes after the vote has been made, and failed.
This would be a very strong argument in favour of using exceptions
everywhere in the next major version: codebase cleanup, room for more
optimization.

Nikita, please fork PHP, we'll follow you ;-)

— Benjamin

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

[Nikita Popov]

On Thu, Sep 12, 2019 at 2: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
>

As people have expressed interest in hearing about direct technical
benefits that these kinds of changes have ... let me give you an example
that came up yesterday.

Opcache performs a bunch of optimizations, and one class of optimizations
it does are subsequent jumps on the same operand. For example:

if ($x) { A; }
if ($x) { B; }

Currently, opcache will optimize the first if($x) condition to jump
directly until after the second if($x) if the value is false, on the
expectation that it is redundant to check the same condition twice in a
row: The result is going to be the same. Basically the result is something
like this:

if ($x) { A; } else { goto end; }
if ($x) { B; }
end:

Now, it turns out that this entire class of optimizations is technically
illegal. Why? Because $x might be an undefined variable! That means that
this optimization at the least loses an "undefined variable" notice, and at
worse changes control flow:

set_error_handler(function() {
$GLOBALS['x'] = true;
});
if ($x) echo "foo\n";
if ($x) echo "bar\n";

Because it's been around for years and doesn't seem to have caused any
active issues, we're likely going to keep this, but nonetheless, it
illustrates the kind of issue we see with these notices. Either an
exception or nothing at all are fine, but notices caused problems.

Of course there are also other problems, such as
https://bugs.php.net/bug.php?id=78598, which is one of multiple
use-after-free issues related to notices thrown during write operations.
The root cause is that under the PHP memory model, it is not legal to run
arbitrary user code while holding writable references into structures -- an
invariant that is violated by some notices, such as the undefined array key
one, because those notices may invoke error handlers. Again, either
throwing nothing or throwing an exception would be unproblematic.

Generally notices thrown by the engine are a pretty big pain to deal with,
as well as something of a correctness and safety hazard. We have quite a
few bugs in this area, though most of them are thankfully not likely to be
hit by accident.

Nikita

Re: [PHP-DEV] Internals "camps"

[Stephen Reay]

> On 11 Oct 2019, at 13:42, Walter Parker  wrote:
> 
> 
> 
> On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay  wrote:
> 
> 
> > On 11 Oct 2019, at 12:40, Walter Parker  wrote:
> > 
> > G
> > 
> > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay 
> > wrote:
> > 
> >> 
> >> 
> >>> On 11 Oct 2019, at 02:59, Walter Parker  wrote:
> >>> 
> >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler 
> >> wrote:
> >>> 
>  
>  
>  On Thu, Oct 10, 2019 at 1:30 PM Walter Parker 
> >> wrote:
>  
> >> 
> >> 
> >> No. The compromise is funding a ferry system. Or laying Internet
> >> between
> >> them. Or a passenger pigeon mail route.
> >> 
> >> Sometimes compromise requires deep discussion about the motivations
> >> for
> >> each side and coming to a lateral, mutually acceptable, solution.
> >> 
> >> But we'd rather not discuss motivations and just bicker about the
> > surface
> >> results. I.e., argue the X, rather than the Y, of these little XY
> > problems
> >> we're solving.
> >> 
> >> 
> >> 
> > Build a ferry system is alternative to building bridge. I can see that
> >> as
> > a
> > compromise, I can also see that as a separate project created to serve
> > demand after the the bridge project is rejected. Where a ferry system
> >> is
> > started because there is still demand for transit, just not enough
> >> demand
> > to pay for a bridge.
> > 
> > With respect to the backtick proposal, what is the "ferry" project? Do
> >> we
> > have to come up with one before we can cancel the "bridge" project or
> >> can
> > we cancel the "bridge" project on its own merits and then discuss a
> >> future
> > project that solves the actual underlying problem?
> > 
> > "Ferry" projects might be: more/better training on PHP, better
> > documentation so that the backtick is no longer an "obscure" feature to
> > those that don't have a shell/Unix/Perl background, tooling to warn
> >> people
> > when they misuse this feature.
> > 
> > 
> > 
>  To the side that says "There is absolutely no reason we need to go to,
> >> or
>  communicate with, the island in the first place," a ferry project isn't
> >> a
>  compromise. The position of the "anti-bridge" builders isn't because
> >> they
>  are against building bridges - it's because they are against spending
>  resources on attempts to get to the island in the first place. The other
>  side might have valid arguments on why we need to get to the island,
> >> but,
>  just proposing different ways to get there isn't compromising with the
> >> side
>  that doesn't want to go there.
>  
> >>> 
> >>> I think you may have just created a strawman for the anti-bridge
> >> position.
> >>> There are famous anti-bridge cases, like the Bridge to Nowhere in Alaska
> >>> (if you don't remember, there was an island in Alaska that had 50 people
> >>> and Senator Stevens wanted to replace the existing ferry system with a
> >> $398
> >>> million bridge). People complained about the bridge not because they
> >> wanted
> >>> the islanders to to isolated, but because it was poor use of money when
> >>> there where bigger and more urgent problems.
> >>> 
> >>> To bring this back to PHP, is the backtick really a urgent problem of
> >>> enough magnitude that it justifies the cost of a BC break in unknown
> >> amount
> >>> of PHP code that has been functional for years. If this proposal passes
> >>> (and the follow up to remove it which I'm certain will be proposed), then
> >>> this is one that leaves people on the island as they will either be stuck
> >>> on an old version of PHP or have to pay to update the code. This pushes
> >> the
> >>> costs on them to solve a an existing issue that 20 years after it was
> >>> created and is now an issue because a new generation of coders, unaware
> >> of
> >>> history, find the existing syntax not to there taste/a poor design. Why
> >> are
> >>> we giving priority to people that haven't taken the time to educate
> >>> themselves over people that did and used programming style that used to
> >>> common?
> >>> 
> >>> 
>  
>  
> > Walter
> > 
> > --
> > The greatest dangers to liberty lurk in insidious encroachment by men
> >> of
> > zeal, well-meaning but without understanding.   -- Justice Louis D.
> > Brandeis
> > 
>  
>  
>  --
>  Chase Peeler
>  chasepee...@gmail.com
>  
> >>> 
> >>> 
> >>> --
> >>> The greatest dangers to liberty lurk in insidious encroachment by men of
> >>> zeal, well-meaning but without understanding.   -- Justice Louis D.
> >> Brandeis
> >> 
> >> 
> >> Hi Walter,
> >> 
> >> The RFC at the centre of this ridiculous string of analogies is about one
> >> thing: deprecate (i.e. show a deprecation message) about the backtick
> >> operator.
> >> 
> >> The RFC specifically doesn’t lay out a timeline for actual removal, 

Re: [PHP-DEV] Internals "camps"

[Walter Parker]

On Thu, Oct 10, 2019 at 11:11 PM Stephen Reay 
wrote:

>
>
> > On 11 Oct 2019, at 12:40, Walter Parker  wrote:
> >
> > G
> >
> > On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay 
> > wrote:
> >
> >>
> >>
> >>> On 11 Oct 2019, at 02:59, Walter Parker  wrote:
> >>>
> >>> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler 
> >> wrote:
> >>>
> 
> 
>  On Thu, Oct 10, 2019 at 1:30 PM Walter Parker 
> >> wrote:
> 
> >>
> >>
> >> No. The compromise is funding a ferry system. Or laying Internet
> >> between
> >> them. Or a passenger pigeon mail route.
> >>
> >> Sometimes compromise requires deep discussion about the motivations
> >> for
> >> each side and coming to a lateral, mutually acceptable, solution.
> >>
> >> But we'd rather not discuss motivations and just bicker about the
> > surface
> >> results. I.e., argue the X, rather than the Y, of these little XY
> > problems
> >> we're solving.
> >>
> >>
> >>
> > Build a ferry system is alternative to building bridge. I can see
> that
> >> as
> > a
> > compromise, I can also see that as a separate project created to
> serve
> > demand after the the bridge project is rejected. Where a ferry system
> >> is
> > started because there is still demand for transit, just not enough
> >> demand
> > to pay for a bridge.
> >
> > With respect to the backtick proposal, what is the "ferry" project?
> Do
> >> we
> > have to come up with one before we can cancel the "bridge" project or
> >> can
> > we cancel the "bridge" project on its own merits and then discuss a
> >> future
> > project that solves the actual underlying problem?
> >
> > "Ferry" projects might be: more/better training on PHP, better
> > documentation so that the backtick is no longer an "obscure" feature
> to
> > those that don't have a shell/Unix/Perl background, tooling to warn
> >> people
> > when they misuse this feature.
> >
> >
> >
>  To the side that says "There is absolutely no reason we need to go to,
> >> or
>  communicate with, the island in the first place," a ferry project
> isn't
> >> a
>  compromise. The position of the "anti-bridge" builders isn't because
> >> they
>  are against building bridges - it's because they are against spending
>  resources on attempts to get to the island in the first place. The
> other
>  side might have valid arguments on why we need to get to the island,
> >> but,
>  just proposing different ways to get there isn't compromising with the
> >> side
>  that doesn't want to go there.
> 
> >>>
> >>> I think you may have just created a strawman for the anti-bridge
> >> position.
> >>> There are famous anti-bridge cases, like the Bridge to Nowhere in
> Alaska
> >>> (if you don't remember, there was an island in Alaska that had 50
> people
> >>> and Senator Stevens wanted to replace the existing ferry system with a
> >> $398
> >>> million bridge). People complained about the bridge not because they
> >> wanted
> >>> the islanders to to isolated, but because it was poor use of money when
> >>> there where bigger and more urgent problems.
> >>>
> >>> To bring this back to PHP, is the backtick really a urgent problem of
> >>> enough magnitude that it justifies the cost of a BC break in unknown
> >> amount
> >>> of PHP code that has been functional for years. If this proposal passes
> >>> (and the follow up to remove it which I'm certain will be proposed),
> then
> >>> this is one that leaves people on the island as they will either be
> stuck
> >>> on an old version of PHP or have to pay to update the code. This pushes
> >> the
> >>> costs on them to solve a an existing issue that 20 years after it was
> >>> created and is now an issue because a new generation of coders, unaware
> >> of
> >>> history, find the existing syntax not to there taste/a poor design. Why
> >> are
> >>> we giving priority to people that haven't taken the time to educate
> >>> themselves over people that did and used programming style that used to
> >>> common?
> >>>
> >>>
> 
> 
> > Walter
> >
> > --
> > The greatest dangers to liberty lurk in insidious encroachment by men
> >> of
> > zeal, well-meaning but without understanding.   -- Justice Louis D.
> > Brandeis
> >
> 
> 
>  --
>  Chase Peeler
>  chasepee...@gmail.com
> 
> >>>
> >>>
> >>> --
> >>> The greatest dangers to liberty lurk in insidious encroachment by men
> of
> >>> zeal, well-meaning but without understanding.   -- Justice Louis D.
> >> Brandeis
> >>
> >>
> >> Hi Walter,
> >>
> >> The RFC at the centre of this ridiculous string of analogies is about
> one
> >> thing: deprecate (i.e. show a deprecation message) about the backtick
> >> operator.
> >>
> >> The RFC specifically doesn’t lay out a timeline for actual removal, it
> >> doesn’t even hint at “well it’ll just be automatically removed”.
> >>
> >