Hi all,
On Sun, May 17, 2015 at 8:44 AM, Levi Morrison wrote:
> On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
> 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 bigge
Dan Ackroyd wrote on 18/05/2015 18:38:
On 18 May 2015 at 15:39, Levi Morrison 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 quite different.
On 18 May 2015 at 15:39, Levi Morrison 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 quite different.
TypeException is also different
On Sun, May 17, 2015 at 11:44 AM, Rowan Collins wrote:
> On 17 May 2015 16:02:40 BST, Levi Morrison 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
On 17 May 2015 16:02:40 BST, Levi Morrison 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 than without
On Sun, May 17, 2015 at 7:10 AM, Rowan Collins wrote:
> On 17 May 2015 00:44:03 BST, Levi Morrison wrote:
>>On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
>> 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
>>>
On 17 May 2015 00:48:07 BST, Levi Morrison wrote:
>It's also the principle of least astonishment: why isn't TypeException
>caught by `catch (Exception $e)`?
This is probably a good argument in favour of "Error" as naming for engine
exceptions. If you say "TypeError is not caught by catch (Except
On 17 May 2015 00:44:03 BST, Levi Morrison wrote:
>On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
> 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
On Sat, May 16, 2015 at 5:44 PM, Levi Morrison wrote:
> On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
> 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
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins 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 who voted on t
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 can
On 16/05/2015 19:44, Levi Morrison wrote:
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
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 argume
On Sat, May 16, 2015 at 1:13 PM, Stanislav Malyshev 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
>> difference b
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 everythin
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 effo
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 Excepti
On Sat, May 16, 2015 at 12:44 PM, Levi Morrison wrote:
> On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
> 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
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
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
> break - is
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
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
> break - is
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 cha
On Sat, May 16, 2015 at 11:51 AM, Levi Morrison 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 classes/interfaces,
>> not
> 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 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
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 *appropri
On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann 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 February:
>
On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann
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 February:
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 th
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 D
On May 13, 2015 12:43 PM, "Sebastian Bergmann" 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 access and
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: http://www.php.net/unsub.p
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
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 A
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
On Fri, May 1, 2015 at 1:04 PM, Sebastian Bergmann 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 reasons but the m
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 May 1, 2015 1:24 AM, "Marcio Almada" wrote:
>
> Hi Stas,
>
> 2015-04-30 13:51 GMT-03:00 Stanislav Malyshev :
>
> > 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
> > > E
Hi Stas,
2015-04-30 13:51 GMT-03:00 Stanislav Malyshev :
> 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 w
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
Am 30.04.2015 um 14:30 schrieb Julien Pauli:
On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann
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
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 Intern
On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann
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 7.0, changing
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 7.2/8
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
https://wiki.php.ne
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 Dev
Hi Sebastian,
On Sun, Mar 22, 2015 at 2:05 AM, Sebastian Bergmann
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 the boat f
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 or
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 Mai
On Sun, Mar 15, 2015 at 8:27 AM, Sebastian Bergmann 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 implements the
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 excep
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 Err
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 spok
On 9 March 2015 at 11:04, David Zuelke 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 delays finding bugs
> Am 09.03.2015 um 12:04 schrieb David Zuelke :
>
> Why not wait with the merge until a consensus emerges regarding Throwable?
>
>
>> On 09.03.2015, at 05:26, Nikita Popov wrote:
>>
>> On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov wrote:
>>
>>> Hi internals!
>>>
>>> Voting on the engine exc
Why not wait with the merge until a consensus emerges regarding Throwable?
> On 09.03.2015, at 05:26, Nikita Popov wrote:
>
> On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov wrote:
>
>> Hi internals!
>>
>> Voting on the engine exceptions RFC, which proposes to convert existing
>> fatal and rec
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
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
Guilher
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 R
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 PM,
+1000 on this; so much better than the BaseException stuff!
> On 27.02.2015, at 15: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
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
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
>
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 ha
+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:4
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
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, a
2015-02-24 13:29 GMT+01:00 Yasuo Ohgaki :
> Hi all,
>
> On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz
> 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 majori
Hi all,
On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz
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 am a little c
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 all,
On Tue, Feb 24, 2015 at 4:28 PM, Pavel Kouřil 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.
For people dis
On Tue, Feb 24, 2015 at 12:03 AM, Yasuo Ohgaki wrote:
> Hi Nikita,
>
> On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov wrote:
>
>> Voting on the engine exceptions RFC, which proposes to convert existing
>> fatal and recoverable fatal errors into exceptions, has opened:
>>
>> https://wiki.php.ne
Hi Nikita,
On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov 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 primary vote requir
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 vot
73 matches
Mail list logo
