Re: [PHP-DEV] Raise E_NOTICE for null castings

2017-10-27 Thread li...@rhsoft.net 



Am 27.10.2017 um 11:49 schrieb Filippo Tessarotto:
Hi, I would like to propose an RFC to raise an E_NOTICE when a variable 
"initialized" to null is casted to other types:


$foo = null;
var_dump($foo['bar']);
var_dump($foo . 'bar');
var_dump($foo + 2);
var_dump($foo & 2);
// At the time being, this code produces no errors

The eventual vote may be split one for each case.

What do you think?


pleae don't break code like this which is a useful case for access 
directly a array field returned from a function and so makes this to a 
one-liner without check the result


public function GetMaxSort(): int
{
 return (int)mysqli_fetch_row($this->cl_api->db->query("select 
SQL_NO_CACHE max(hsort) from {$this->cl_api->sql_prefix}main", 1))[0];

}

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

[PHP-DEV] Raise E_NOTICE for null castings

2017-10-27 Thread Filippo Tessarotto 
Hi, I would like to propose an RFC to raise an E_NOTICE when a variable 
"initialized" to null is casted to other types:


$foo = null;
var_dump($foo['bar']);
var_dump($foo . 'bar');
var_dump($foo + 2);
var_dump($foo & 2);
// At the time being, this code produces no errors

The eventual vote may be split one for each case.

What do you think?

Best regards, Filippo

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

Re: [PHP-DEV] Raise E_NOTICE for null castings

2017-10-27 Thread Niklas Keller 
>
> Hi, I would like to propose an RFC to raise an E_NOTICE when a variable
>> "initialized" to null is casted to other types:
>>
>> $foo = null;
>> var_dump($foo['bar']);
>> var_dump($foo . 'bar');
>> var_dump($foo + 2);
>> var_dump($foo & 2);
>> // At the time being, this code produces no errors
>>
>> The eventual vote may be split one for each case.
>>
>> What do you think?
>>
>
> pleae don't break code like this which is a useful case for access
> directly a array field returned from a function and so makes this to a
> one-liner without check the result
>
> public function GetMaxSort(): int
> {
>  return (int)mysqli_fetch_row($this->cl_api->db->query("select
> SQL_NO_CACHE max(hsort) from {$this->cl_api->sql_prefix}main", 1))[0];
>
> }
>

Just use return (int) mysqli_fetch_row($this->cl_api->db->query("select
SQL_NO_CACHE max(hsort) from {$this->cl_api->sql_prefix}main", 1))[0] ?? 0;

Regards, Niklas

Re: [PHP-DEV] [RFC] [Discussion] Allow a trailing comma in function calls

2017-10-27 Thread Peter Cowburn 
On 24 October 2017 at 17:14, Sara Golemon  wrote:

> On Tue, Oct 24, 2017 at 11:37 AM, Peter Cowburn 
> wrote:
> > I know it's late in the game, but I have a quick question. This RFC
> > includes a couple of "Not really a function" functions (namely isset()
> and
> > unset()) that will also be able to have a trailing comma, but I'm failing
> > to find the discussion on including "not really a function" calls in this
> > RFC. Why were those specific non-functions choices included? Why only
> those?
> >
> I'd guess because those are the only constructs which appear
> function-like *and* exhibit variadic behavior.
> empty/die/exit/print/require/include/require_once/include_
> once/__HALT_COMPILER
> don't have a variadic mode so allowing trailing commas in them would
> be pointless.
>

That's a fair point, then maybe we should consider declare() too?  Also, I
know that "echo" is a "doesn't even look like a function" but can that be
considered as if we're changing any language constructs at all in this RFC,
then that might benefit too.  Note, I'm just saying "consider" on purpose,
rather than suggesting any change to the RFC actually be made.


>
> -Sara
>

Re: [PHP-DEV] Raise E_NOTICE for null castings

2017-10-27 Thread li...@rhsoft.net 


Am 27.10.2017 um 12:54 schrieb Niklas Keller:

pleae don't break code like this which is a useful case for access
directly a array field returned from a function and so makes this to
a one-liner without check the result

public function GetMaxSort(): int
{
  return (int)mysqli_fetch_row($this->cl_api->db->query("select
SQL_NO_CACHE max(hsort) from {$this->cl_api->sql_prefix}main", 1))[0];

}


Just use return (int) mysqli_fetch_row($this->cl_api->db->query("select 
SQL_NO_CACHE max(hsort) from {$this->cl_api->sql_prefix}main", 1))[0] ?? 0;


thanks - that's indeed the better solution and since i use 
MYSQLI_OPT_INT_AND_FLOAT_NATIVE in the database layer the complete 
type-casting can be removed too!


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

[PHP-DEV] Re: Raise E_NOTICE for null castings

2017-10-27 Thread Christoph M. Becker 
On 27.10.2017 at 11:49, Filippo Tessarotto wrote:

> Hi, I would like to propose an RFC to raise an E_NOTICE when a variable
> "initialized" to null is casted to other types:
> 
> $foo = null;
> var_dump($foo['bar']);
> var_dump($foo . 'bar');
> var_dump($foo + 2);
> var_dump($foo & 2);
> // At the time being, this code produces no errors
> 
> The eventual vote may be split one for each case.
> 
> What do you think?

Note that there is already an accepted RFC regarding rasing E_WARNING
for invalid container read array-access[1].  However, it has not been
implemented yet, due to difficulties, see the discussion on PR #2031[2].

[1] 
[2] 

-- 
Christoph M. Becker

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

[PHP-DEV] Re: Raise E_NOTICE for null castings

2017-10-27 Thread Filippo Tessarotto 

I am sorry for partial topic duplication regarding array-access.

Still, at least with `declare(strict_types=1);` auto-castings of 
non-numbers should raise an error:


var_dump(false + 2);
var_dump(null + 2);

Exactly like `"" + 2`.

WDYT? Filippo

Il 27/10/2017 13:47, Christoph M. Becker ha scritto:

On 27.10.2017 at 11:49, Filippo Tessarotto wrote:


Hi, I would like to propose an RFC to raise an E_NOTICE when a variable
"initialized" to null is casted to other types:

$foo = null;
var_dump($foo['bar']);
var_dump($foo . 'bar');
var_dump($foo + 2);
var_dump($foo & 2);
// At the time being, this code produces no errors

The eventual vote may be split one for each case.

What do you think?


Note that there is already an accepted RFC regarding rasing E_WARNING
for invalid container read array-access[1].  However, it has not been
implemented yet, due to difficulties, see the discussion on PR #2031[2].

[1] 
[2] 



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

[PHP-DEV] Apply substr() optimization to array_slice()

2017-10-27 Thread Benjamin Coutu 
Hello everyone,

Please consider these two statements:

substr($string, 0, $length);
array_slice($array, 0, $length, true);

Currently, with substr(), if $offset is zero and $length is smaller or equal to 
the original string length we just increase the reference count of the original 
string and return it via RETURN_STR_COPY.
In that case we completely save the allocation of a new string.

Now, array_slice() could be optimized similarly, but currently (unless the 
resulting array is expected to be empty) we always create a new array no matter 
if we actually have to.
The same mechanism as used with substr() could be applied to array_slice(), 
given that $offset is zero and of course only if $preserve_keys is true.

A patch would look like this:

if (length <= num_in && offset == 0 && preserve_keys) {
  /* Copy the original array */
  ZVAL_COPY(return_value, input);
  return;
}

I'd appreciate if someone could commit this. Thanks.

Cheers,

Benjamin

-- 

Bejamin Coutu
ben.co...@zeyos.com

ZeyOS, Inc.
http://www.zeyos.com


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

Re: [PHP-DEV] [RFC] [Discussion] Allow a trailing comma in function calls

2017-10-27 Thread Sara Golemon 
On Fri, Oct 27, 2017 at 7:17 AM, Peter Cowburn  wrote:
> On 24 October 2017 at 17:14, Sara Golemon  wrote:
>> I'd guess because those are the only constructs which appear
>> function-like *and* exhibit variadic behavior.
>>
>> empty/die/exit/print/require/include/require_once/include_once/__HALT_COMPILER
>> don't have a variadic mode so allowing trailing commas in them would
>> be pointless.
>
> That's a fair point, then maybe we should consider declare() too?
>
Perhaps, but since we've already entered voting, it'll have to be a
separate RFC at this point.  That, or we reset and I don't think it's
worthwhile for declare because it's only got three possible values,
all of which can easily fit a single line.

> Also, I
> know that "echo" is a "doesn't even look like a function" but can that be
> considered as if we're changing any language constructs at all in this RFC,
> then that might benefit too.  Note, I'm just saying "consider" on purpose,
> rather than suggesting any change to the RFC actually be made.
>
At a shot-from-the-hip guess, I'd assume that would introduce parser
ambiguity because of the lack of delimiting parenthesis.

-Sara

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

Re: [PHP-DEV] Apply substr() optimization to array_slice()

2017-10-27 Thread Sara Golemon 
On Fri, Oct 27, 2017 at 8:12 AM, Benjamin Coutu  wrote:
> Now, array_slice() could be optimized similarly, but currently
> (unless the resulting array is expected to be empty) we always
> create a new array no matter if we actually have to.
>
Pushed, with an additional escape hatch for vector-like arrays (which
are implicitly like preserve_keys).  In the future though, please use
the PR process. Thanks.

-Sara

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

Re: [PHP-DEV] Apply substr() optimization to array_slice()

2017-10-27 Thread Dennis Birkholz 
Hello Benjamin,

Am 27.10.2017 um 14:12 schrieb Benjamin Coutu:
> Hello everyone,
> 
> Please consider these two statements:
> 
> substr($string, 0, $length);
> array_slice($array, 0, $length, true);
> 
> Currently, with substr(), if $offset is zero and $length is smaller or equal 
> to the original string length we just increase the reference count of the 
> original string and return it via RETURN_STR_COPY.
> In that case we completely save the allocation of a new string.

the optimization actually only returns the same string if the supplied
length is the length of the string, see:
https://lxr.room11.org/xref/php-src%40master/ext/standard/string.c#2436

> Now, array_slice() could be optimized similarly, but currently (unless the 
> resulting array is expected to be empty) we always create a new array no 
> matter if we actually have to.
> The same mechanism as used with substr() could be applied to array_slice(), 
> given that $offset is zero and of course only if $preserve_keys is true.
> 
> A patch would look like this:
> 
> if (length <= num_in && offset == 0 && preserve_keys) {
>   /* Copy the original array */
>   ZVAL_COPY(return_value, input);
>   return;
> }

So the array_slice optimization should only do the some, otherwise the
returned array would be longer than desired.

Greets,
Dennis

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

Re: [PHP-DEV] RFC - Array Of for PHP 7

2017-10-27 Thread Rowan Collins 
On 25 October 2017 22:52:37 BST, Dan Ackroyd  wrote:
>Although 'array of' as well as full blown generics are popular ideas,
>I'm pretty certain the RFC failed due to the type check on the array
>happening every time the 'array of' was passed from one function to
>another, which would make it too slow to actually use.

The fundamental problem with extending PHP's type declarations - either to more 
complex types, or to other code elements such as properties - is that they are 
currently always checked at run-time, not with a separate static analyser. It's 
notable that in Go, the runtime type checks are considered a "development only" 
option, and strongly discouraged in production code due to performance impact.

I wrote about this a few months back here: http://rwec.co.uk/q/php-type-system

One possibility if we do want to keep the current run-time approach is to cache 
type information against values (zvals) so subsequent checks become quicker. 
The problem is working out exactly what to store and when to invalidate it - if 
you append 42 to an array that passed int[] on the last check, the ideal would 
be for us to know the type is still valid.

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Apply substr() optimization to array_slice()

2017-10-27 Thread Nikita Popov 
On Fri, Oct 27, 2017 at 4:16 PM, Sara Golemon  wrote:

> On Fri, Oct 27, 2017 at 8:12 AM, Benjamin Coutu 
> wrote:
> > Now, array_slice() could be optimized similarly, but currently
> > (unless the resulting array is expected to be empty) we always
> > create a new array no matter if we actually have to.
> >
> Pushed, with an additional escape hatch for vector-like arrays (which
> are implicitly like preserve_keys).  In the future though, please use
> the PR process. Thanks.
>

Unfortunately these optimizations are subtly incorrect in the current form,
because arrays have a bunch of additional hidden state. See
https://bugs.php.net/bug.php?id=75433 for a (not yet fixed) issue that
resulted from similar optimizations in 7.2. We'll have to review all the
places where we apply optimizations like these and make sure that we're not
introducing incorrect behavior wrt the next free element or internal array
pointer.

Nikita

Re: [PHP-DEV] Apply substr() optimization to array_slice()

2017-10-27 Thread Sara Golemon 
On Fri, Oct 27, 2017 at 12:10 PM, Nikita Popov  wrote:
> On Fri, Oct 27, 2017 at 4:16 PM, Sara Golemon  wrote:
>>
>> On Fri, Oct 27, 2017 at 8:12 AM, Benjamin Coutu 
>> wrote:
>> > Now, array_slice() could be optimized similarly, but currently
>> > (unless the resulting array is expected to be empty) we always
>> > create a new array no matter if we actually have to.
>> >
>> Pushed, with an additional escape hatch for vector-like arrays (which
>> are implicitly like preserve_keys).  In the future though, please use
>> the PR process. Thanks.
>
>
> Unfortunately these optimizations are subtly incorrect in the current form,
> because arrays have a bunch of additional hidden state. See
> https://bugs.php.net/bug.php?id=75433 for a (not yet fixed) issue that
> resulted from similar optimizations in 7.2. We'll have to review all the
> places where we apply optimizations like these and make sure that we're not
> introducing incorrect behavior wrt the next free element or internal array
> pointer.
>
It took awhile to unwind the repro case given in the bug report, but
this seems to be a simpler example:
https://3v4l.org/rqphD

Basically, that next insert index for the output of array_values()
should be reset, and with the optimization it's not.

For array_values() the quick and dirty fix is adding "&& nextIndex ==
num_elements" psuedocode.  In the case of array_slice, the same will
be true, so I agree we should be careful about applying such
optimizations.

I'll clean up these uses now, and would suggest something like:

zend_array* zend_hash_duplicate(zend_array* input, zend_bool
preserve_keys); type API which can be a certral place for making that
kind of short-circuit versus slow-copy decision when called from
places like array_values() and array_slice().

-Sara

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

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

2017-10-27 Thread Thomas Punt 
Hi,


> If developers accidentally add/subtract leading space from the closing token 
> then the whole string changes;


Yes, this is a feature of the chosen semantics. The indentation level of the 
body can be chosen based upon the current indentation level of the code (for 
which, the closing marker should be lined up to), not the indentation level 
from the start of the line (which may cause developers to indent the body text 
less to prevent leading whitespace, leading us back to the current situation of 
having indentation levels ruined by these syntaxes).


> this can lead to subtle bugs and annoyances.

I think this clause is a little too exaggerated. Once a developer understands 
that the closing token guides the indentation level of the body text, then the 
cause of the change in whitespace should be pretty obvious (if it's not already 
visually obvious from the fact that they must have broken the indentation level 
of their own code).

-Tom

[PHP-DEV] Constants and Access Modifiers

2017-10-27 Thread Fleshgrinder 
Hey Internals!

We currently have a couple of things that are broken about constants,
and I wanted to gauge if people are interested in a) fixing it as well
as b) to get to know the root causes of these things.

# 1

A constant defined in an interface cannot be overwritten in the class
that implements the interface, however, further subclasses can overwrite
the content of the constant at will.

- https://3v4l.org/DFB37
- https://3v4l.org/9LMci

A constant defined in a class can be overwritten by any subclass at will.

# 2

Constants can reference themselves, and subclasses can define the actual
value. Kind of like abstract constants. This works nicely while working
with an actual instance of the object, however, it breaks in the moment
that constant is accessed anywhere in the parent, or from any other
constant.

- https://3v4l.org/HUCTh
- https://3v4l.org/5aYB5

# 3

A constant that is defined with a visibility in a parent class, cannot
be references between subclasses, like it is possible with methods.
Instead we are presented with an access violation.

- https://3v4l.org/2lU3i

Note that this behavior is the same for static and instance properties
that are being redefined in a child class. Hence, access is defined by
location and not by modifier.

# What I think

I haven't thought very long about everything, but here are my initial
thoughts:

## 1

This issue could be resolved by changing the behavior to enable
overwriting of parent constant in any sublcass. This gives us a
consistent behavior.

Afterwards we should add support for the final modifier, so that people
can seal their constants and protect them from redefinition.

> Why not seal by default?

It would disallow some dynamic programming that is possible with the
late static binding of PHP, and I honestly see no reason why we should
disallow something that is already possible: BC!

## 2

Disallow self-referencing constants in any context, and instead add
support for the abstract keyword to constants. This raises the question
on how to deal with constants in interfaces. I would allow the
definition of both constants with and without a value there. Those
without are abstract, those with a value are like they are right now.
Directly referencing an abstract constant should result in an error.

Abstract constants are a great thing in combination with late static
binding, and the engine ensures that the value does not change over the
course of the runtime of the program. An attribute that is impossible
for methods. Dart for instance has support for the const keyword for
many elements, including methods.

## 3

This seems like a bigger construction site. I think that the behavior
should be that the access is determined by the modifier, and not the
location. Especially because doing anything else is to great of a BC.
The current behavior of allowing access to protected members of other
classes with the same parent also allows the creation of friend classes.
Although without the control that real friend classes have.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Apply substr() optimization to array_slice()

2017-10-27 Thread Benjamin Coutu 
Yes, abstracting such additional checks through something like 
zend_hash_duplicate() would make sense, but IMHO it should be named 
differently, e.g. zend_hash_copy_lazy. So to be analogous to 
zend_string_copy(), but not to be confused with the existing zend_hash_copy().

By the way: array_pad() in L4320, array_unique() in L4476 and array_diff() in 
L5415 also return the array without those kind of checks (analougous to what I 
have proposed for the array_slice() case). These existing bugs would have to be 
fixed as well.

- Ben -

== Original ==
From: Sara Golemon 
To: Nikita Popov 
Date: Fri, 27 Oct 2017 18:34:15 +0200
Subject: Re: [PHP-DEV] Apply substr() optimization to array_slice()

> 
> 
> On Fri, Oct 27, 2017 at 12:10 PM, Nikita Popov  wrote:
> > On Fri, Oct 27, 2017 at 4:16 PM, Sara Golemon  wrote:
> >>
> >> On Fri, Oct 27, 2017 at 8:12 AM, Benjamin Coutu 
> >> wrote:
> >> > Now, array_slice() could be optimized similarly, but currently
> >> > (unless the resulting array is expected to be empty) we always
> >> > create a new array no matter if we actually have to.
> >> >
> >> Pushed, with an additional escape hatch for vector-like arrays (which
> >> are implicitly like preserve_keys).  In the future though, please use
> >> the PR process. Thanks.
> >
> >
> > Unfortunately these optimizations are subtly incorrect in the current form,
> > because arrays have a bunch of additional hidden state. See
> > https://bugs.php.net/bug.php?id=75433 for a (not yet fixed) issue that
> > resulted from similar optimizations in 7.2. We'll have to review all the
> > places where we apply optimizations like these and make sure that we're not
> > introducing incorrect behavior wrt the next free element or internal array
> > pointer.
> >
> It took awhile to unwind the repro case given in the bug report, but
> this seems to be a simpler example:
> https://3v4l.org/rqphD
> 
> Basically, that next insert index for the output of array_values()
> should be reset, and with the optimization it's not.
> 
> For array_values() the quick and dirty fix is adding "&& nextIndex ==
> num_elements" psuedocode.  In the case of array_slice, the same will
> be true, so I agree we should be careful about applying such
> optimizations.
> 
> I'll clean up these uses now, and would suggest something like:
> 
> zend_array* zend_hash_duplicate(zend_array* input, zend_bool
> preserve_keys); type API which can be a certral place for making that
> kind of short-circuit versus slow-copy decision when called from
> places like array_values() and array_slice().
> 
> -Sara


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

Re: [PHP-DEV] Constants and Access Modifiers

2017-10-27 Thread Nikita Popov 
On Fri, Oct 27, 2017 at 10:51 PM, Fleshgrinder  wrote:

> Hey Internals!
>
> We currently have a couple of things that are broken about constants,
> and I wanted to gauge if people are interested in a) fixing it as well
> as b) to get to know the root causes of these things.
>
> # 1
>
> A constant defined in an interface cannot be overwritten in the class
> that implements the interface, however, further subclasses can overwrite
> the content of the constant at will.
>
> - https://3v4l.org/DFB37
> - https://3v4l.org/9LMci
>
> A constant defined in a class can be overwritten by any subclass at will.
>
> # 2
>
> Constants can reference themselves, and subclasses can define the actual
> value. Kind of like abstract constants. This works nicely while working
> with an actual instance of the object, however, it breaks in the moment
> that constant is accessed anywhere in the parent, or from any other
> constant.
>
> - https://3v4l.org/HUCTh
> - https://3v4l.org/5aYB5


PHP does not permit self-referencing constants.

However, this is only checked when the constant is first accessed. In your
first example the constant is never accessed, so no error is thrown. This
has nothing to do with subclasses defining the value -- you're using late
static binding, so you're accessing the constant of the child class
directly.

PHP cannot detect self-referencing constants during compilation, because
they may be formed through non-trivial cycles involving multiple constants,
across multiple files.

Nikita

# 3
>
> A constant that is defined with a visibility in a parent class, cannot
> be references between subclasses, like it is possible with methods.
> Instead we are presented with an access violation.
>
> - https://3v4l.org/2lU3i
>
> Note that this behavior is the same for static and instance properties
> that are being redefined in a child class. Hence, access is defined by
> location and not by modifier.
>
> # What I think
>
> I haven't thought very long about everything, but here are my initial
> thoughts:
>
> ## 1
>
> This issue could be resolved by changing the behavior to enable
> overwriting of parent constant in any sublcass. This gives us a
> consistent behavior.
>
> Afterwards we should add support for the final modifier, so that people
> can seal their constants and protect them from redefinition.
>
> > Why not seal by default?
>
> It would disallow some dynamic programming that is possible with the
> late static binding of PHP, and I honestly see no reason why we should
> disallow something that is already possible: BC!
>
> ## 2
>
> Disallow self-referencing constants in any context, and instead add
> support for the abstract keyword to constants. This raises the question
> on how to deal with constants in interfaces. I would allow the
> definition of both constants with and without a value there. Those
> without are abstract, those with a value are like they are right now.
> Directly referencing an abstract constant should result in an error.
>
> Abstract constants are a great thing in combination with late static
> binding, and the engine ensures that the value does not change over the
> course of the runtime of the program. An attribute that is impossible
> for methods. Dart for instance has support for the const keyword for
> many elements, including methods.
>
> ## 3
>
> This seems like a bigger construction site. I think that the behavior
> should be that the access is determined by the modifier, and not the
> location. Especially because doing anything else is to great of a BC.
> The current behavior of allowing access to protected members of other
> classes with the same parent also allows the creation of friend classes.
> Although without the control that real friend classes have.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>