Hello :-),
At Hoa, we are totally in favor or this RFC. We tried to make our
exception hierarchy compatible with PHP7 with success but it was very
difficult to make it backward compatible. With this proposal, all our
problems are going to be solved, so +1 for us!
On 23/05/15 22:12, Aaron Pio
Hi!
>$foo = 42;
> $foo['bar']; // => NULL
> $v = NULL;
> $v[0][1][2][3][4][5][6][7][8][9]; // NULL
>
> this code is semantically wrong and I would like to have error/exception
> for such
> erroneous codes. It's inconsistent with array object, too.
Why it's wrong? You try to get that's s
On Wed, Jun 10, 2015 at 3:32 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Tue, Jun 9, 2015 at 10:49 PM, Ferenc Kovacs wrote:
>
>> On Tue, Jun 9, 2015 at 3:36 PM, Lior Kaplan wrote:
>>
>> > On Tue, Jun 9, 2015 at 4:29 PM, Ferenc Kovacs wrote:
>> >
>> >>
>> >> On Tue, Jun 9, 2015 at 3:23 PM, Lior Ka
Hi!
On 6/9/15 10:40 AM, Aaron Piotrowski wrote:
> Does anyone have any questions, comments, or concerns about the Throwable
> Interface RFC?
>
> http://wiki.php.net/rfc/throwable-interface
>
> The proposed exception hierarchy:
>
> interface Throwable
> ⊢ Exception implements Throwable
>
Hi all,
On Tue, Jun 9, 2015 at 10:49 PM, Ferenc Kovacs wrote:
> On Tue, Jun 9, 2015 at 3:36 PM, Lior Kaplan wrote:
>
> > On Tue, Jun 9, 2015 at 4:29 PM, Ferenc Kovacs wrote:
> >
> >>
> >> On Tue, Jun 9, 2015 at 3:23 PM, Lior Kaplan
> wrote:
> >>
> >>> Hi Guys,
> >>>
> >>> A quick question - I
Hi all,
On Tue, May 26, 2015 at 3:02 AM, Rowan Collins
wrote:
> On 24/05/2015 22:32, Yasuo Ohgaki wrote:
>
>> Does this include internal function type errors?
>> e.g.
>>
>> $ php -r 'var_dump(mt_srand("999"));'
>> PHP Warning: mt_srand() expects parameter 1 to be
Rowan Collins wrote:
> Christoph Becker wrote on 09/06/2015 14:09:
>> I wonder where these coercion rules are described. The manual has a
>> section about "Converting to array"[1] which actually describes casting,
>> and is obviously not what is happening when the subscript operator (as
>> the la
> On Jun 9, 2015, at 1:13 PM, Levi Morrison wrote:
>
> My only objections have already been raised, but I'll reiterate them briefly:
>
> 1. Having both Error and Exception makes little sense, especially
> since we have historically used error to refer to an error that wasn't
> an exception (so
Hi,
The voting is now open:
https://wiki.php.net/rfc/json_numeric_as_string#voting
Cheers
Jakub
On Tue, Jun 9, 2015 at 11:40 AM, Aaron Piotrowski wrote:
> Does anyone have any questions, comments, or concerns about the Throwable
> Interface RFC?
>
> http://wiki.php.net/rfc/throwable-interface
>
> The proposed exception hierarchy:
>
> interface Throwable
> ⊢ Exception implements Thro
Does anyone have any questions, comments, or concerns about the Throwable
Interface RFC?
http://wiki.php.net/rfc/throwable-interface
The proposed exception hierarchy:
interface Throwable
⊢ Exception implements Throwable
∟ Error implements Throwable (replaces EngineException)
I don't see a big problem changing this for few opcodes in PHP-7 VM, and
make behavior "more defined".
On the other hand I don't think we shouldn't "define" the order of operand
evaluation.
This may prevent us performing optimisations in the future.
Fixing this in PHP-5.* doesn't cost the effort f
Christoph Becker wrote on 09/06/2015 14:09:
I wonder where these coercion rules are described. The manual has a
section about "Converting to array"[1] which actually describes casting,
and is obviously not what is happening when the subscript operator (as
the langspec calls it[2]) is applied to
On Tue, Jun 9, 2015 at 3:36 PM, Lior Kaplan wrote:
> On Tue, Jun 9, 2015 at 4:29 PM, Ferenc Kovacs wrote:
>
>>
>> On Tue, Jun 9, 2015 at 3:23 PM, Lior Kaplan wrote:
>>
>>> Hi Guys,
>>>
>>> A quick question - I saw PHP-7.0.0 branch, should it be PHP-7.0 branch
>>> (while master continues to 7.1)
On Tue, Jun 9, 2015 at 4:29 PM, Ferenc Kovacs wrote:
>
> On Tue, Jun 9, 2015 at 3:23 PM, Lior Kaplan wrote:
>
>> Hi Guys,
>>
>> A quick question - I saw PHP-7.0.0 branch, should it be PHP-7.0 branch
>> (while master continues to 7.1).
>>
>> The PHP-7.0.0 should probably be for the RCs (while che
On Tue, Jun 9, 2015 at 3:23 PM, Lior Kaplan wrote:
> Hi Guys,
>
> A quick question - I saw PHP-7.0.0 branch, should it be PHP-7.0 branch
> (while master continues to 7.1).
>
> The PHP-7.0.0 should probably be for the RCs (while cherry picking from
> PHP-7.0 as needed). If we have this branch too
Rowan Collins wrote:
> Yasuo Ohgaki wrote on 09/06/2015 11:44:
>> $v = NULL;
>> $v[0][1][2][3][4][5][6][7][8][9]; // NULL
>>
>> this code is semantically wrong and I would like to have error/exception
>> for such
>> erroneous codes.
>
> PHP considers an uninitialised variable to have the valu
Hi all,
- Original Message -
From: "Sara Golemon"
Sent: Monday, May 11, 2015
On Mon, May 11, 2015 at 5:12 PM, Matt Wilmas
wrote:
- Original Message -
From: "Stanislav Malyshev"
Sent: Monday, May 11, 2015
argument. I'd like to propose making the order of evaluation defined
b
Christoph Becker wrote on 09/06/2015 13:35:
Current behavior:
foo->bar;
?>
Notice: Trying to get property of non-object in %s on line %d
Notice: Trying to get property of non-object in %s on line %d
So trying to access a property on NULL gives a notice, but trying to
access an eleme
Christoph Becker wrote on 08/06/2015 22:11:
The behavior of dereferencing scalars as if they were arrays or strings
is arguable:
NULL
A few things to note here:
- accessing a *numeric* offset of a *string* is valid (selects a single
character)
- accessing a *string* offset of another str
Matt Wilmas wrote:
> Forgetting the NULL case for a sec... With:
>
> $v = [];
> $v[0][1][2][3][4][5][6][7][8][9];
>
> How/why are we going from 1 Notice to 10?!
>
> With:
>
> unset($v);
> $v[0];
>
> Why from 1 Notice about the undefined variable, to 2? That's totally
> new, and it really do
Yasuo Ohgaki wrote on 09/06/2015 11:44:
$v = NULL;
$v[0][1][2][3][4][5][6][7][8][9]; // NULL
this code is semantically wrong and I would like to have error/exception
for such
erroneous codes.
PHP considers an uninitialised variable to have the value NULL, and a
NULL value to be coercable
Hi all,
- Original Message -
From: "Christoph Becker"
Sent: Tuesday, June 09, 2015
Yasuo Ohgaki wrote:
I fully agree that current behavior could be used meaningful ways.
However,
NULL
$v = NULL;
$v[0][1][2][3][4][5][6][7][8][9]; // NULL
this code is semantically wrong and I wou
Yasuo Ohgaki wrote:
> I fully agree that current behavior could be used meaningful ways. However,
>
>$foo = 42;
> $foo['bar']; // => NULL
> $v = NULL;
> $v[0][1][2][3][4][5][6][7][8][9]; // NULL
>
> this code is semantically wrong and I would like to have error/exception
> for such
> erro
Hi Matt,
On Tue, Jun 9, 2015 at 7:04 PM, Matt Wilmas wrote:
> Hi all,
>
>
> - Original Message -
> From: "Yasuo Ohgaki"
> Sent: Tuesday, June 09, 2015
>
> Hi all,
>>
>> On Tue, Jun 9, 2015 at 6:21 AM, Stanislav Malyshev
>> wrote:
>>
>> > Would throwing a notice or a warning on array d
Hi all,
- Original Message -
From: "Yasuo Ohgaki"
Sent: Tuesday, June 09, 2015
Hi all,
On Tue, Jun 9, 2015 at 6:21 AM, Stanislav Malyshev
wrote:
> Would throwing a notice or a warning on array deferencing scalars
> be acceptable for PHP 7.0, or does this need an RFC?
I think this d
Hi all,
On Tue, Jun 9, 2015 at 6:21 AM, Stanislav Malyshev
wrote:
> > Would throwing a notice or a warning on array deferencing scalars
> > be acceptable for PHP 7.0, or does this need an RFC?
>
> I think this does need an RFC, and for 7.0, pretty much no new language
> changes are acceptable an
27 matches
Mail list logo
