[PHP-DEV] PHP7.1.19RC1 ready for testing
Morning all, PHP 7.1.19RC1 is ready for testing and can be downloaded from: https://downloads.php.net/~ab There is already one known problematic commit contained in this release which will be reverted before the final release, for reference it is: https://github.com/php/php-src/commit/d6e81f0bfd0cb90586dd83d4fd47a4302605261a This came to light after tagging and I was toying with the idea of retagging, but since there has now been a few days since the initial tag, some users may have already pulled in the tag and I decided to leave it until the final. Sorry about the delay. Cheers Joe
Re: [PHP-DEV] [VOTE] Fiber API
Replying to Joe's email because I didn't get the original. On Sun, Jun 10, 2018 at 1:09 PM Joe Watkins wrote: > > This is not ready for voting, please stop the vote. > > Bringing stuff to vote that is incomplete, where there is no clear > consensus, is dangerous. > > > On Sun, Jun 10, 2018 at 2:09 PM, Haitao Lv wrote: > > > Hello Internals, > > > > The RFC for fiber is now open for a vote. The RFC is available at > > https://wiki.php.net/rfc/fiber. > > > > Voting will be open until June 22th, 2018. > > > > Thank you. I don't think I've listed my complaints yet although I believe others already covered these: 1. I don't like `Fiber::` referring to the fiber running. I would prefer it being passed as a parameter. 2. As written and implemented this is not sufficiently different from generators. If fibers supported suspending/resuming C code as well then it may be powerful enough to justify it, however... 3. I don't feel this low-level building block is proven. Theoretically we should be able to build async/await functionality with it, which is I believe is the real goal. However, until I've seen it built, demonstrated, and critiqued I don't think we can claim the the low-level building block is sound. Sorry for not providing feedback sooner. Levi Morrison -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make compact function reports undefined passed variables
On 10/06/2018 19:41, Hoffman, Zachary Robert wrote:
Deprecating compact() would hurt workflows where you use the same variable names
several times in different contexts, even though they are only declared locally
for the purposes of compact() itself.
I am not convinced that building logic around variable names is ever a
good thing. Variable names are primarily a label used by the programmer
to write source code, and in my opinion that's all they should ever be.
Programmers should be free to rename them within their scope, and
compilers should be free to erase them when optimising a production build.
public function c()
{
$d = $this->d();
$a = pow($d, $d + 1);
$c = $a ^ 0b1100;
$b = $a - $d;
return new B(
compact(
$this->b()
)
);
}
Your two classes here are clearly collaborating on the processing of
some specific collection of values, which have something in common with
each other; they are not really passing 4 variables, but some structure
which has 4 fields. It might be nice in some cases if that could be a
by-value "struct" type, but the most appropriate in current PHP would be
to define a third class and pass an instance of that from class A to
class B.
foreach (A::b() as $b) {
echo $a->a($b) . PHP_EOL;
}
This is a poor example, because if this was really the end result, then
the two classes aren't even using the data with the same meaning, and
class A might as well return a plain array - if the keys are no longer
important, it could simply return [$a, $b, $c, $d].
The alternative would be manipulating array elements directly, like this:
public function c()
{
$e['d'] = $this->d();
$e['a'] = pow($e['d'], $e['d'] + 1);
$e['c'] = $e['a'] ^ 0b1100;
$e['b'] = $e['a'] - $e['d'];
return new B($e);
}
That is far more cumbersome.
I agree that this is slightly harder to read (and the version I would
prefer where $e was an object rather than an array would look similar).
However, this feels like an argument for some syntactic sugar, like the
"with" block found in some languages:
with($e) {
// Inside this block $a is actually compiled to mean $e->a
}
Not that this can be entirely de-sugared by a compiler or static
analysis tool, so can be completely ignored by optimisation, and
reliably processed by code inspection and refactoring aids. This isn't
true of compact(), variable-variables, etc, because by exchanging
strings and variable names you are writing fundamentally dynamic code.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make compact function reports undefined passed variables
>The existence of anything that internally relies on `get_defined_vars()` is a
>blocker for applying further optimisations to the engine (think stack frames),
>which is probably why Dmitry suggested its removal.
I did not know it was an optimization issue. I suppose I could substitute a
userland equivalent:
function compact_(array $compact, array $vars)
{
return array_intersect_key($vars, array_flip($compact));
}
which changes A::c() to
function c()
{
$d = $this->d();
$a = pow($d, $d + 1);
$c = $a ^ 0b1100;
$b = $a - $d;
return new B(
compact_(
$this->b(),
get_defined_vars()
)
);
}
That is not so bad. As far as I am concerned, deprecate away.
Re: [PHP-DEV] [VOTE] Fiber API
This is not ready for voting, please stop the vote. Bringing stuff to vote that is incomplete, where there is no clear consensus, is dangerous. On Sun, Jun 10, 2018 at 2:09 PM, Haitao Lv wrote: > Hello Internals, > > The RFC for fiber is now open for a vote. The RFC is available at > https://wiki.php.net/rfc/fiber. > > Voting will be open until June 22th, 2018. > > Thank you. > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [VOTE] Make compact function reports undefined passed variables
The existence of anything that internally relies on `get_defined_vars()` is
a blocker for applying further optimisations to the engine (think stack
frames), which is probably why Dmitry suggested its removal.
On Sun, 10 Jun 2018, 20:42 Hoffman, Zachary Robert,
wrote:
> >>
> >> Hi Gabriel,
> >>
> >>> compact(), extract(), parse_str() (with 1 argument) and
> >>> get_defined_vars() are bad functions, because they access local
> variables
> >>> indirectly.
> >>>
> >>> They might be considered to be removed in the next major PHP version,
> >>> despite of this fix.
> >>>
> >>>
> >>> Thanks. Dmitry.
> >>>
> >>>
> >>
> >> Hello Dmitry.
> >>
> >> Thanks for this feedback. When I decided to create this RFC adding a
> >> warning, many of friends actually suggested me creating an RFC
> depracting
> >> `compact`, and complaing with the same arguments as yours.
> >>
> >> Do you think we should do this already in PHP 7.3?
> >>
> >> Thanks.
> >>
> >--
> >Gabriel Caruso
>
> Deprecating compact() would hurt workflows where you use the same variable
> names
> several times in different contexts, even though they are only declared
> locally
> for the purposes of compact() itself.
>
> Below is an example of what I mean. The array used for compact() is the
> same one
> that is iterated over outside of class A. Further, we use the variables
> that are
> compacted earlier in A::c(), so it is convenient to use them as local
> variables.
>
> class A
> {
> private static $b = [
> 'a',
> 'b',
> 'c',
> 'd',
> ];
>
> public static function b()
> {
> return self::$b;
> }
>
> public function d()
> {
> return 2;
> }
>
> public function c()
> {
> $d = $this->d();
> $a = pow($d, $d + 1);
> $c = $a ^ 0b1100;
> $b = $a - $d;
>
> return new B(
> compact(
> $this->b()
> )
> );
> }
> }
>
> class B
> {
> private $a;
>
> public function __construct($a)
> {
> $this->a = $a;
> }
>
> public function a(string $name)
> {
> return $this->a[$name];
> }
> }
>
> $a = (new A())->c();
>
> foreach (A::b() as $b) {
> echo $a->a($b) . PHP_EOL;
> }
>
> The alternative would be manipulating array elements directly, like this:
>
> public function c()
> {
> $e['d'] = $this->d();
> $e['a'] = pow($e['d'], $e['d'] + 1);
> $e['c'] = $e['a'] ^ 0b1100;
> $e['b'] = $e['a'] - $e['d'];
>
> return new B($e);
> }
>
> That is far more cumbersome. So, compact() has legitimate uses sometimes.
>
> Cheers,
>
> --
> Zach Hoffman
>
> From: Gabriel Caruso
> Sent: Saturday, June 9, 2018 12:25
> To: Dmitry Stogov
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] [VOTE] Make compact function reports undefined
> passed variables
>
> >
> > Hi Gabriel,
> >
> >> compact(), extract(), parse_str() (with 1 argument) and
> >> get_defined_vars() are bad functions, because they access local
> variables
> >> indirectly.
> >>
> >> They might be considered to be removed in the next major PHP version,
> >> despite of this fix.
> >>
> >>
> >> Thanks. Dmitry.
> >>
> >>
> >
> > Hello Dmitry.
> >
> > Thanks for this feedback. When I decided to create this RFC adding a
> > warning, many of friends actually suggested me creating an RFC depracting
> > `compact`, and complaing with the same arguments as yours.
> >
> > Do you think we should do this already in PHP 7.3?
> >
> > Thanks.
> >
> --
> Gabriel Caruso
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [VOTE] Make compact function reports undefined passed variables
>>
>> Hi Gabriel,
>>
>>> compact(), extract(), parse_str() (with 1 argument) and
>>> get_defined_vars() are bad functions, because they access local variables
>>> indirectly.
>>>
>>> They might be considered to be removed in the next major PHP version,
>>> despite of this fix.
>>>
>>>
>>> Thanks. Dmitry.
>>>
>>>
>>
>> Hello Dmitry.
>>
>> Thanks for this feedback. When I decided to create this RFC adding a
>> warning, many of friends actually suggested me creating an RFC depracting
>> `compact`, and complaing with the same arguments as yours.
>>
>> Do you think we should do this already in PHP 7.3?
>>
>> Thanks.
>>
>--
>Gabriel Caruso
Deprecating compact() would hurt workflows where you use the same variable names
several times in different contexts, even though they are only declared locally
for the purposes of compact() itself.
Below is an example of what I mean. The array used for compact() is the same one
that is iterated over outside of class A. Further, we use the variables that are
compacted earlier in A::c(), so it is convenient to use them as local variables.
class A
{
private static $b = [
'a',
'b',
'c',
'd',
];
public static function b()
{
return self::$b;
}
public function d()
{
return 2;
}
public function c()
{
$d = $this->d();
$a = pow($d, $d + 1);
$c = $a ^ 0b1100;
$b = $a - $d;
return new B(
compact(
$this->b()
)
);
}
}
class B
{
private $a;
public function __construct($a)
{
$this->a = $a;
}
public function a(string $name)
{
return $this->a[$name];
}
}
$a = (new A())->c();
foreach (A::b() as $b) {
echo $a->a($b) . PHP_EOL;
}
The alternative would be manipulating array elements directly, like this:
public function c()
{
$e['d'] = $this->d();
$e['a'] = pow($e['d'], $e['d'] + 1);
$e['c'] = $e['a'] ^ 0b1100;
$e['b'] = $e['a'] - $e['d'];
return new B($e);
}
That is far more cumbersome. So, compact() has legitimate uses sometimes.
Cheers,
--
Zach Hoffman
From: Gabriel Caruso
Sent: Saturday, June 9, 2018 12:25
To: Dmitry Stogov
Cc: PHP Internals
Subject: Re: [PHP-DEV] [VOTE] Make compact function reports undefined passed
variables
>
> Hi Gabriel,
>
>> compact(), extract(), parse_str() (with 1 argument) and
>> get_defined_vars() are bad functions, because they access local variables
>> indirectly.
>>
>> They might be considered to be removed in the next major PHP version,
>> despite of this fix.
>>
>>
>> Thanks. Dmitry.
>>
>>
>
> Hello Dmitry.
>
> Thanks for this feedback. When I decided to create this RFC adding a
> warning, many of friends actually suggested me creating an RFC depracting
> `compact`, and complaing with the same arguments as yours.
>
> Do you think we should do this already in PHP 7.3?
>
> Thanks.
>
--
Gabriel Caruso
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Fiber API
Hey Haitao, there doesn't seem to be any voting snipped on that page, so there's no actual vote yet. Also, the open issues section should usually be empty when the vote starts. The implementation in its current state is very limited and not really useful to real-world applications. Written code can't even be tested with common testing tools such as PHPUnit, because PHPUnit relies on reflection, which is unsupported by the current RFC. Additionally, the "why not as extension" doesn't really have a good reasoning. In its current state, I think it's better suited as an external extension. I'd really like to get fibers into PHP, but not in that state, sorry. Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Fiber API
Hello Internals, The RFC for fiber is now open for a vote. The RFC is available at https://wiki.php.net/rfc/fiber. Voting will be open until June 22th, 2018. Thank you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A replacement for the Serializable interface
Please allow me to up vote for this proposal. I'm working on some serialization logic these days, and `Serializable` is totally broken: it breaks internal references in serialized data structures, and breaks custom serializers (e.g. igbinaryà from inspecting nested structures. The proposal here would just fix all these issues. +1000 from me for what it matters :) 2017-04-21 15:50 GMT+02:00 Nikita Popov : > On Fri, Apr 21, 2017 at 2:47 PM, Michał Brzuchalski < > michal.brzuchal...@gmail.com> wrote: > > > I know my voice is doesn't mean anything but IMHO interface with magic > > methods could bring more inconsistency. > > > > I know PHP is consistently inconsistent but I would prefer if it is > > posdible to fix an issue with present method naming. > > > > Cheers > > > Magic methods have a distinct backwards compatibility advantage. They allow > you to add __serialize/__unserialize to an existing class that currently > uses Serializable. Older PHP versions will then use the Serializable > implementation, while never versions will use __serialize/__unserialize. An > interface makes this a lot more complicated, because you either have to > bump your PHP version requirement (unlikely), or you have to provide a shim > interface for older PHP versions. This shim interface would then be part of > any library currently implementing Serializable, which seems sub-optimal to > me. That's why I think magic methods are better for this case (though I > don't strongly care). > > Also, to answer an OTR question: We cannot simply reuse the Serializable > interface by allowing an array return value from > Serializable::unserialize(). The array return value is only a means to an > end: the important part is that the new serialization mechanism does not > share serialization state -- using arrays instead of strings is just a > convenient way to achieve this. However, Serializable::unserialize() > currently shares the state and we cannot change this without breaking BC -- > so we cannot reuse this interface. > > Nikita > > > > > 21.04.2017 11:39 "Nikita Popov" napisał(a): > > > >> Hi internals, > >> > >> As you are surely aware, serialization in PHP is a big mess. Said mess > is > >> caused by some fundamental issues in the serialization format, and > >> exacerbated by the existence of the Serializable interface. Fixing the > >> serialization format is likely not possible at this point, but we can > >> replace Serializable with a better alternative and I'd like to start a > >> discussion on that. > >> > >> The problem is essentially that Serializable::serialize() is expected to > >> return a string, which is generally obtained by recursively calling > >> serialize() in the Serializable::serialize() implementation. This > >> serialize() call shares state information with the outer serialize(), to > >> ensure that two references to the same object (or the same reference) > will > >> continue referring to a single object/reference after serialization. > >> > >> This causes two big issues: > >> > >> First, the implementation is highly order-dependent. If > >> Serializable::serialize() contains multiple calls to serialize(), then > >> calls to unserialize() have to be repeated **in the same order** in > >> Serializable::unserialize(), otherwise unserialization may fail or be > >> corrupted. In particular this means that using parent::serialize() and > >> parent::unserialize() is unsafe. (See also > >> https://bugs.php.net/bug.php?id=66052 and linked bugs.) > >> > >> Second, the existence of Serializable introduces security issues that we > >> cannot fix. Allowing the execution of PHP code during unserialization is > >> unsafe, and even innocuous looking code is easily exploited. We have > >> recently mitigated __wakeup() based attacks by delaying __wakeup() calls > >> until the end of the unserialization. We cannot do the same for > >> Serializable::unserialize() calls, as their design strictly requires the > >> unserialization context to still be active during the call. Similarly, > >> Serializable prevents an up-front validation pass of the serialized > >> string, > >> as the format used for Serializable objects is user-defined. > >> > >> The delayed __wakeup() mitigation mentioned in the previous point also > >> interacts badly with Serializable, because we have to delay __wakeup() > >> calls to the end of the unserialization, which in particular also > implies > >> that Serializable::unserialize() sees objects prior to wakeup. (See also > >> https://bugs.php.net/bug.php?id=74436.) > >> > >> In the end, everything comes down to the fact that Serializable requires > >> nested serialization calls with context sharing. > >> > >> The alternative mechanism (__sleep + __wakeup) does not have these > issues > >> (anymore), but it is not sufficiently flexible for general use: Notably, > >> __sleep() allows you to limit which properties are serialized, but the > >> properties still have to actually exist on the object. > >> > >>
