Hi all,
On Sun, May 17, 2015 at 8:44 AM, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 16/05/2015 20:15, Levi Morrison wrote:
The difference is that as time goes on and I've written code for PHP 7
I was hit by this
Dan Ackroyd wrote on 18/05/2015 18:38:
On 18 May 2015 at 15:39, Levi Morrison le...@php.net wrote:
I wouldn't group
TypeException in the same subtree as ParseException, for instance. One
happens at compile time and the other at run time, which means the
intent in what you catch is probably
On Sun, May 17, 2015 at 11:44 AM, Rowan Collins rowan.coll...@gmail.com wrote:
On 17 May 2015 16:02:40 BST, Levi Morrison le...@php.net wrote:
In this specific case we have broken all code out there.
Yes, in the very specific case of people who both caught all exceptions and
handled all
On Sun, May 17, 2015 at 7:10 AM, Rowan Collins rowan.coll...@gmail.com wrote:
On 17 May 2015 00:44:03 BST, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
rowan.coll...@gmail.com wrote:
On 16/05/2015 20:15, Levi Morrison wrote:
The difference is that as time
On 17 May 2015 16:02:40 BST, Levi Morrison le...@php.net wrote:
In this specific case we have broken all code out there.
Yes, in the very specific case of people who both caught all exceptions and
handled all E_RECOVERABLE errors, the existence of Throwable introduces a
slightly worse BC break
On 17 May 2015 00:44:03 BST, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
rowan.coll...@gmail.com wrote:
On 16/05/2015 20:15, Levi Morrison wrote:
The difference is that as time goes on and I've written code for PHP
7
I was hit by this issue. It's an even
On Sat, May 16, 2015 at 11:51 AM, Levi Morrison le...@php.net wrote:
This was the subject of a separate vote in the RFC, which passed by 39 votes
to 19. https://wiki.php.net/rfc/engine_exceptions_for_php7 The subject of
discussion at present is the exact naming of the various
On 16/05/2015 20:15, Levi Morrison wrote:
The difference is that as time goes on and I've written code for PHP 7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people who voted on that issue have
played with the code from both scenarios? Few, I
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
smalys...@gmail.com wrote:
Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
That's a pretty big if, given that your only argument - that it is a BC
Hi!
You are incorrect. The set of exceptions that `catch (Exception)`
catches is all exceptions by its definition. By altering it to no
There's no such definition. It's invented to serve your point, which
makes it circular logic. catch(Exception) catches everything that
descends from
Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
That's a pretty big if, given that your only argument - that it is a BC
break - is incorrect, as in fact the set of exceptions caught before and
after
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
smalys...@gmail.com wrote:
Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
That's a pretty big if, given that your only argument - that it is a BC
I want to talk about the BC impact of what has been discussed.
Currently the meaning of this code is to catch all possible
exceptions, because all exceptions *must* extend `\Exception`:
} catch (Exception $e) {
By making some other root exception you just broke all the code that
is
On Sat, May 16, 2015 at 12:44 PM, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
smalys...@gmail.com wrote:
Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
On 16/05/2015 19:44, Levi Morrison wrote:
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
smalys...@gmail.com wrote:
Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
That's a pretty big if, given
On 16/05/2015 15:40, Levi Morrison wrote:
I want to talk about the BC impact of what has been discussed.
Currently the meaning of this code is to catch all possible
exceptions, because all exceptions *must* extend `\Exception`:
} catch (Exception $e) {
By making some other root exception
Hi!
The key is that I feel like the voting body wasn't well informed. It's
not because I lost; rather it's because I feel like the people voting
yes didn't actually understand the issues at play. There is a big
difference between that and revoting after a vote didn't go my way as
an effort
Hi!
The thrown object must be an instance of the Exception class or a subclass
of Exception.
This is still true for objects that are thrown from userspace, AFAIK. If
not, we can make it true, I have no objection to it. This however gives
your no guarantee catch(Exception) catches everything
This was the subject of a separate vote in the RFC, which passed by 39 votes
to 19. https://wiki.php.net/rfc/engine_exceptions_for_php7 The subject of
discussion at present is the exact naming of the various classes/interfaces,
not the general nature of the hierarchy.
There's nothing that
On Sat, May 16, 2015 at 1:13 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
The key is that I feel like the voting body wasn't well informed. It's
not because I lost; rather it's because I feel like the people voting
yes didn't actually understand the issues at play. There is a big
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins rowan.coll...@gmail.com wrote:
On 16/05/2015 20:15, Levi Morrison wrote:
The difference is that as time goes on and I've written code for PHP 7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people
On Sat, May 16, 2015 at 5:44 PM, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 16/05/2015 20:15, Levi Morrison wrote:
The difference is that as time goes on and I've written code for PHP 7
I was hit by this issue. It's an
On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann sebast...@php.net wrote:
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
Why don't you do it? You have access and you are a very good writer.
No big C knowledge required either in this case :)
There was/is consensus on what I proposed back in
On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann sebast...@php.net
wrote:
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
Why don't you do it? You have access and you are a very good writer.
No big C knowledge required either in this case :)
There was/is consensus on what I proposed back
On May 13, 2015 12:43 PM, Sebastian Bergmann sebast...@php.net wrote:
Am 13.05.2015 um 07:40 schrieb Stanislav Malyshev:
I can, except that I'm pretty busy right now. But probably will have
some time on the weekend, so I've put it on my todo list.
Thanks!
Why don't you do it? You have
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
Why don't you do it? You have access and you are a very good writer.
No big C knowledge required either in this case :)
TBH, until know I did not think I would be capable of doing it
myself. I'll look into it now.
--
PHP Internals - PHP Runtime
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
Why don't you do it? You have access and you are a very good writer.
No big C knowledge required either in this case :)
There was/is consensus on what I proposed back in February:
* Introduce a Throwable interface
* Let Exception implement the
Am 13.05.2015 um 07:40 schrieb Stanislav Malyshev:
I can, except that I'm pretty busy right now. But probably will have
some time on the weekend, so I've put it on my todo list.
Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi!
OK, if there's consensus we can go forward with this, then let's just do
that ASAP.
Can you implement this? Thanks!
I can, except that I'm pretty busy right now. But probably will have
some time on the weekend, so I've put it on my todo list.
--
Stas Malyshev
smalys...@gmail.com
--
I feel like this one is different though, because there already was consensus
that the current naming isn't the best, and there was support for Throwable,
while voting on the original RFC was still open.
To adhere to the RFC process, the open RFC wasn't changed accordingly, because
voting was
Am 09.05.2015 um 06:38 schrieb Stanislav Malyshev:
OK, if there's consensus we can go forward with this, then let's just do
that ASAP.
Can you implement this? Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
I feel like this one is different though, because there already was
consensus that the current naming isn't the best, and there was
support for Throwable, while voting on the original RFC was still
open.
OK, if there's consensus we can go forward with this, then let's just do
that ASAP.
Am 01.05.2015 um 07:08 schrieb Pierre Joye:
Let do a rfc to accept to post pone features freeze with a list or a single
RFC.
Do you volunteer to draft that RFC?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, May 1, 2015 at 1:04 PM, Sebastian Bergmann sebast...@php.net wrote:
Am 01.05.2015 um 07:08 schrieb Pierre Joye:
Let do a rfc to accept to post pone features freeze with a list or a single
RFC.
Do you volunteer to draft that RFC?
I could but no, I am not volunteering. For many
Am 30.04.2015 um 14:30 schrieb Julien Pauli:
On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann sebast...@php.net
wrote:
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for
On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann sebast...@php.net
wrote:
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for 7.1
That means introducing a change in
Am 30.04.2015 um 14:30 schrieb Julien Pauli:
We could make an exception (sic !) and add the Throwable interface to PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.
+1, couldn't agree more.
--
PHP
Hi!
We could make an exception (sic !) and add the Throwable interface to PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.
I'm OK with it but I fear this is opening a can of worms, since people
will start
Hi Stas,
2015-04-30 13:51 GMT-03:00 Stanislav Malyshev smalys...@gmail.com:
Hi!
We could make an exception (sic !) and add the Throwable interface to
PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.
On May 1, 2015 1:24 AM, Marcio Almada marcio.w...@gmail.com wrote:
Hi Stas,
2015-04-30 13:51 GMT-03:00 Stanislav Malyshev smalys...@gmail.com:
Hi!
We could make an exception (sic !) and add the Throwable interface to
PHP7,
even after feature freeze, because it is an easy pick and
Am 21.03.2015 um 18:05 schrieb Sebastian Bergmann:
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7 or not at all (at
least not for a long time) due to BC breaks.
Thoughts?
ping
--
PHP Internals - PHP Runtime
Hi!
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7 or not at all (at
least not for a long time) due to BC breaks.
Thoughts?
It's kind of hard to recover the context here, but I assume it's
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for 7.1
That means introducing a change in 7.0, changing it and deprecating
part of it in 7.1, and removing said part in
Hi Sebastian,
On Sun, Mar 22, 2015 at 2:05 AM, Sebastian Bergmann sebast...@php.net
wrote:
Am 15.03.2015 um 08:27 schrieb Sebastian Bergmann:
It was my idea, after all, only fair that I invest the time to make
it into an RFC: https://wiki.php.net/rfc/throwable
The vote for this missed
Am 15.03.2015 um 09:24 schrieb Pavel Kouřil:
why global namespace?
Because that is where, as of today, built-in classes, interfaces,
functions, etc. go.
The introduction of a PHP namespace, for instance, would be the topic
of a separate RFC.
--
PHP Internals - PHP Runtime Development
Am 15.03.2015 um 08:27 schrieb Sebastian Bergmann:
It was my idea, after all, only fair that I invest the time to make
it into an RFC: https://wiki.php.net/rfc/throwable
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7
Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann:
So who will draft the RFC for
* Introduce a Throwable interface
* Let Exception implement the Throwable interface
* Introduce an Error class that implements the Throwable interface
* Use Error class as base class for exceptions
Am 27.02.2015 um 15:47 schrieb Jordi Boggiano:
quickly draft another RFC to amend that part
So who will draft the RFC for
* Introduce a Throwable interface
* Let Exception implement the Throwable interface
* Introduce an Error class that implements the Throwable interface
* Use
On Sun, Mar 15, 2015 at 8:27 AM, Sebastian Bergmann sebast...@php.net wrote:
Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann:
So who will draft the RFC for
* Introduce a Throwable interface
* Let Exception implement the Throwable interface
* Introduce an Error class that
On 9 March 2015 at 11:04, David Zuelke d...@heroku.com wrote:
Why not wait with the merge until a consensus emerges regarding Throwable?
The patch for engine exceptions is large - the longer that it is left
unmerged, the more difficult it will be to do and people's time is
valuable. It also
Am 09.03.2015 um 12:04 schrieb David Zuelke d...@heroku.com:
Why not wait with the merge until a consensus emerges regarding Throwable?
On 09.03.2015, at 05:26, Nikita Popov nikita@gmail.com wrote:
On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov nikita@gmail.com wrote:
Hi
Am 09.03.2015 um 12:40 schrieb Dan Ackroyd:
So even though I hope we can clean up the exception hierarchy, merging
the engine exceptions is the right choice imo.
Sounds reasonable to me. I'm wondering, though, whether we really need
an additional RFC for the change I suggested as nobody spoke
Why not wait with the merge until a consensus emerges regarding Throwable?
On 09.03.2015, at 05:26, Nikita Popov nikita@gmail.com wrote:
On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Voting on the engine exceptions RFC, which proposes to
Le 23/02/2015 19:15, Nikita Popov a écrit :
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:
https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
Hi,
After discussing the main proposition of this
Hi!
Message-ID: 54f07fc7.8050...@php.net
Date: Fri, 27 Feb 2015 15:31:35 +0100
Guilherme volunteered to create a new RFC for the Throwable interface
immediately after this RFC is accepted. Sounds good to me :-)
I would say create the RFC :) Nothing says we should immediately rush
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting is open until 2015-03-08.
Voting ends today and it looks like the RFC will be accepted. How
should we proceed with regards to the comments I made in
Message-ID: 54f07fc7.8050...@php.net
Date: Fri, 27 Feb 2015 15:31:35 +0100
Guilherme
+1000 on this; so much better than the BaseException stuff!
On 27.02.2015, at 15:31, Sebastian Bergmann sebast...@php.net wrote:
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into
Please, write additional RFC if you are ready to work on it and provide
implementation.
The class hierarchy is definitely not the main part of this one.
The idea was just to make difference between Exception, EngineException and
ParseException.
Thanks. Dmirty.
On Fri, Feb 27, 2015 at 5:47
Am 28.02.2015 um 01:57 schrieb Larry Garfield:
The RFC is currently in voting, so editing it directly is a no-no. A new,
short RFC, please. (Exception implements Throwable, Error implements
Throwable sounds good to me. Should we ask about SomeUserspaceClass
implements Throwable, or will
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:
https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The primary vote requires a 2/3 majority, as
On 27/02/2015 14:31, Sebastian Bergmann wrote:
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:
https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The
+1 on Sebastian's suggestion. =)
I volunteer to either update the RFC or create a new one to resolve this
once Exceptions in the engine passes (which looks like a reality already
to me).
Just tell me which approach I should take and I'll happily write the RFC.
[]s,
On Fri, Feb 27, 2015 at 9:47
On 2/27/15 9:28 AM, guilhermebla...@gmail.com wrote:
+1 on Sebastian's suggestion. =)
I volunteer to either update the RFC or create a new one to resolve this
once Exceptions in the engine passes (which looks like a reality already
to me).
Just tell me which approach I should take and I'll
Sebastian Bergmann wrote:
I am sorry that I was unable to raise this concern earlier (did not
really become aware of the RFC before it was put to the vote), but I
would prefer the following:
* Introduce a Throwable interface
* Let Exception implement the Throwable interface
*
Hi all,
On Tue, Feb 24, 2015 at 4:28 PM, Pavel Kouřil pajou...@gmail.com wrote:
I personally find both BaseException and AbstractException ugly. The
Throwable is IMHO much better.
We definitely need coding(naming) standard :)
We may have coding standard before PHP7 release and cleanup all.
Hi all,
On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
A second vote will decide whether to use a BaseException based
inheritance
hierarchy. This vote uses a simple majority.
I like this RFC and hope it passes. I
2015-02-24 13:29 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Hi all,
On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz den...@birkholz.biz
wrote:
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
A second vote will decide whether to use a BaseException based
inheritance
hierarchy. This
Hi,
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.
I like this RFC and hope it passes. I am a little concerned about
littering the global namespace. It would be preferable to
Hi internals!
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:
https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The primary vote requires a 2/3 majority, as this is a language change.
A second
Hi Nikita,
On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov nikita@gmail.com wrote:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:
https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The
On Tue, Feb 24, 2015 at 12:03 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Nikita,
On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov nikita@gmail.com wrote:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has
71 matches
Mail list logo
