[PHP-DEV] PHP 7.1.7 Released

[Joe Watkins]

Morning,

The PHP development team announces the immediate availability of PHP 7.1.7.

This is a security release with several fixes included, all users of PHP
7.1 are encouraged to upgrade.

For source downloads of PHP 7.1.7 please visit the downloads page:

http://php.net/downloads.php

Windows binaries can be found on:

http://windows.php.net/download

For a list of changes included in this release, see the ChangeLog:

http://www.php.net/ChangeLog-7.php#7.1.7

Follows is verification information:

php-7.1.7.tar.bz2
SHA256 hash:
079b6792987f38dc485f92258c04f9e02dedd593f9d260ebe725343f812d1ff8
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABCAAGBQJZXx2KAAoJEPm6Ctoxy9ieKuAH/2mvJ27OJ/bSCWvrAn/XGTFJ
9gJP3o/2Z8+DlHO8IFTmMzeZ6lw2fwwkauAIygPQmrvzMcw3Io0Y18RuCAWtJM8h
FpFvkDHKSVAMkA3mAhesUok1czuAX9o/SUAj1puHzpU6vNH4y/PMJvOFWwIquqdi
PXdhozEHh3VIpspzMojuB0BQxgNZKDqKwwKW5xNVP0Z/nA74diKUE6C+g2JFgM//
FQTVRH969If6c6hfNrcDS5ULmovQZ2qlYSsbhOCzq3eqkTzg0kgxZQjXylzagWAW
8oBoHx972aUKlL4z/8AOvRIvFVH/A2OSa2oudSqb1viq4AikzLq4jFippSdy+3Y=
=rGzS
-END PGP SIGNATURE-


php-7.1.7.tar.gz
SHA256 hash:
e0dbab8da601ee5119368d6f93dc1a86ad53b799d2f8c1209d6b827a2b259f92
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABCAAGBQJZXx2QAAoJEPm6Ctoxy9iejusH/107RTapsRAr/CXIVOLxLnCK
JMbxTi8iS/qUECIn4UI30FAvHDyMAnC8kfcJDCteO/5R9/S0zzmc+lEOeHBVWOrf
tkN8Zd8Pw6NhVN8yNpc9ROPHyFh1dq/MDD06dvPxZw+Nka8+V3NH2BoQ0VFpdnFW
VpFKWMUumR3LU0ropg5/FDWM8rb60dAR1f4Nf8b17XI0b7hqh1y+6Pwl/t/kzg3C
SZGuhv/cn5uRE113VUwHbqu600QJYwdaz4n3IDNYbZORGI2Ck+KnUCG019BYP+oO
mErL7JvP97JAZ53wfTETv66B2fSGWPlRzFmIs+U2l5JX3a91Wc+Pl77q1gdLCYg=
=9K3J
-END PGP SIGNATURE-


php-7.1.7.tar.xz
SHA256 hash:
0d42089729be7b2bb0308cbe189c2782f9cb4b07078c8a235495be5874fff729
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABCAAGBQJZXx2UAAoJEPm6Ctoxy9ieneIH+wSRaLAtR0W85sc+zbeU7iIV
GoQbsKK7O2/vUaHyi9bw65fFzOF3IaIcn/EG5rR7fQ062V/W1R2aKge+uLrzBQ6S
TUhL0/VgjY+Fxw2iV6W6Bh+jrtjBAXMavMX4psNAwrvSfxd8FGxvskXkREL3xSmv
oIbGuFPaa4Zix3oxUoR3yMXJ4+3GVcC8oqQELp0uk4WoCIKimh8R2fFslRlxyfaV
Cw0IAxuD6m7gFBZVq6fodze9n1ExrLeau0S4ZhJYnQwbP9pSWEl3BV1IpfIXnN7L
OyGduOSF3hH91i2nztJ712wUdnHIT9SwgGvLsZbS4u0ufqYwgX1ARvh+U/BGwMw=
=LHGy
-END PGP SIGNATURE-

Cheers
Joe

Re: [PHP-DEV] "Reader" as alternative to Iterator

[Davey Shafik]

I believe the correct solution to this is an OuterIterator — an
OuterIterator contains the logic to constrain the loop, for example, we
have the LimitIterator, FilterIterator, RegexIterator, etc.

See this example:
http://php.net/manual/en/class.limititerator.php#example-4473

You can build your own OuterIterators, which implements whatever logic your
Reader should have.

OuterIterators are also compose-able, you can stack them, though of course
there are performance considerations here.

I would say that any alternative to OuterIterator's should have a clear and
demonstrable benefit in both developer experience, and performance before
it should be considered.

- Davey

On Wed, Jul 5, 2017 at 3:51 AM, Rowan Collins 
wrote:

> On 3 July 2017 16:58:16 BST, Andreas Hennings  wrote:
> >My motivation was to be able to use iterators and readers
> >interchangeably.
> >Readers are easier to implement as classes.
> >Iterators have the benefit of the generator syntax.
> >The idea is to have a library where some stuff is implemented as
> >reader classes, and some other things are implemented as iterator
> >classes.
> >
> >Then for the actual operational code, I need to choose to use either
> >iterator syntax or reader syntax. So either I need adapters for all
> >iterators, or I need adapters for all readers.
>
> An alternative to adapters in this case might be a Trait that allows you
> to write the class as a Reader, but turn it into a fully-functioning
> Iterator with one line of code. If you always call your read method read()
> you only need a single adapter which calls that at the appropriate times
> and buffers the value to know if it's reached the end. That adapter could
> be "pasted" by a Trait into each class where read() is defined, and read()
> could even be private.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

[PHP-DEV] PHP 5.6.31 is available

[Ferenc Kovacs]

Hello!

The PHP development team announces the immediate availability of PHP 5.6.31.
This is a security release. Several security bugs were fixed in this
release. All PHP 5.6 users are encouraged to upgrade to this version.

For source downloads of PHP 5.6.31 please visit our downloads page:
http://www.php.net/downloads.php

 Windows binaries can be found on http://windows.php.net/download/.

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-5.php#5.6.31

To verify the downloads, you can use the following information:

php-5.6.31.tar.bz2
SHA256 hash:
8f397169cb65f0539f3bcb04060f97770d73e19074a37bd2c58b98ebf6ecb10f
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZXX4+AAoJEMK/C8Qzz8iz2LsIAJ8zQLVLtAod1AJpsE71Ik6Y
XbVY8oglQq584d6NkHpImdEAZnK++W11mFxMYNAA8CI9keF44llKyZrBi/OM7XPV
bDt0rt/MeLCNr6uohx1ZgGQI28UIgKCc8H3H0fEvIFxxp0pEqQ900SS9ZZMU0cJS
QWHvcp00S2truxezDVGVOO63r+BTcg2AX87DpaYNcb10OYWgsGzdE4Ud8uqxI40+
0sPt77ulCG74Dznu5YH4BhVBLCHqwEjn2pGB/qxs6xDfoCyzjQO8U6oQ5VbFDkVk
W5tpRoKrCGbIMZes9DW+FU5Bpunr6so7JGm/8TqfzMX4M7/qVlrVrErdUrvyiYg=
=yP79
-END PGP SIGNATURE-


php-5.6.31.tar.gz
SHA256 hash:
6687ed2f09150b2ad6b3780ff89715891f83a9c331e69c90241ef699dec4c43f
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZXX5FAAoJEMK/C8Qzz8izX0cH/2L5ysDRhlcqoCImyYUmwb1D
n6slSSVNYr6maYKwYk3NQlT5QvKjnUKEg+Z7EiLq+phyuf86ngaO8O/4UT3moJtk
Kmi2awG5NEhMw/BYjFGZtGYvf2gAjMuprn/zbVW2QXLiC1GY2qokn2C/TOEghduo
Vnj625XH7jc1SLmN9HVsOLL990KSdvpMz+wo/iPGyFlS9EEZn5qs3ohrP1jt4qfI
Jx4zjqSrCUwp5cA5cjjhRr36qBwwd6PqiAMuEeuzRkrzNAX9xqxwqMldP+njyhpM
EMwJbpdjKmdSbtLpm6X+/0fDgSGYaouR9bX6jaiTE5Tccd+RSUgXqMjBswsWyww=
=Yu+9
-END PGP SIGNATURE-


php-5.6.31.tar.xz
SHA256 hash:
c464af61240a9b7729fabe0314cdbdd5a000a4f0c9bd201f89f8628732fe4ae4
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABAgAGBQJZXX5LAAoJEMK/C8Qzz8izt/QIAK27a0HrT19p9lpmRKc41rm4
W9nQ6i4eQU/VtPef5F6ZG0bheJWQz/k6XHOvQZ7aqhCW3ggwbr8Vfs0VKpGamIrV
TT/WH9bEYWdQiG0Jcf9I7XLGZs0GbqZw4qXYtJ7gG2NAqODsEpLkPRFgoLaH0sS1
sMdb74qUtjir4AVtCrhRpp9XpL2DDamXV6OpyAgZPM0NTsX4JTlrJh5HgOpr2mR1
/T9KI5R6jT7ndbX1X/1JWVnhqjLoG+WRijxzHTq1S7c68n5oj0LmQPHhfRn6jhkV
8Cuc96TPttwvKJ7Y+7z5DOiA3fHt9py/zQvgp9xT7TpV83OQ9MmdBbDT541MtLY=
=7uPl
-END PGP SIGNATURE-

Julien Pauli & Ferenc Kovacs

[PHP-DEV] BAD Benchmark Results for PHP Master 2017-07-06

[lp_benchmark_robot]

Results for project PHP master, build date 2017-07-06 14:00:37-07:00
commit: fc336c7
previous commit:8e0ddc8
revision date:  2017-07-06 23:06:11+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.09% -0.19%  2.84%  
  8.90%
:-|   Drupal 7.36 cgi -T1  0.18%  0.20%  1.97%  
  4.78%
:-|   MediaWiki 1.23.9 cgi -T5000  0.08%  0.00%  3.27%  
  3.63%
:-(   bench.php cgi -T100  0.02% -1.51% 45.90%  
  4.86%
:-(  micro_bench.php cgi -T10  0.01% -2.52% 20.42%  
  4.45%
:-(  mandelbrot.php cgi -T100  0.02% -2.13% 43.31%  
  5.40%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2017-07-06/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] Extensions License

[Sara Golemon]

On Thu, Jul 6, 2017 at 4:17 PM, Scott Arciszewski  wrote:
> I haven't received any direction for what to do here, so I opened this
> issue on the libsodium-php repo:
>
> https://github.com/jedisct1/libsodium-php/issues/127
>
> If we get a full checklist of consent from every contributor, including
> Frank, that should be enough to unblock this pull request, no?
>
If the extension is relicensed to the PHP license and Copyright
assigned to The PHP Group, then every problem goes away in the
simplest and least uncertain way possible.

If the above can't be done, we still have options.  The BSD license
currently on the extension is not, in and of itself, super
problematic.  The only issue which needs resolving in my mind is
addressing the frontier between ext/sodium and the rest of php-src.
Code migrating (in either direction) muddies the waters between these
parts of the repo and I just don't know what the consequences of that
are.  Maybe they're nothing.

I wanted to move that part of the discussion here in the interest of
getting other stakeholders to comment.  Particularly those who are
formally members of "The PHP Group". Rasmus? Ze'ev? Andi? I think you
three are the only ones in that category still active.

-Sara

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

Re: [PHP-DEV] Extensions License

[Scott Arciszewski]

On Sun, Jul 2, 2017 at 12:51 PM, Scott Arciszewski 
wrote:

>
> ​Hi all,
>
> Towards the end (currently, anyway) of the pull request discussion, a
> possible resolution emerges for ext/sodium: https://github.com/php/php-
> src/pull/2560#issuecomment-312452732
>
> I've never dealt with licensing issues before, so I'm not sure what the
> process is myself.
>
> However, feel free to treat my contributions as CC0/WTFPL/Unlicense so
> that everyone can freely just relicense my contributions as whatever
> license without complication. You don't even need me to sign off on it.
> Just, have at it.
>
> Would it make sense to post an issue on the libsodium-php Github to ask
> the contributors if they consent to a relicense? Or should we track them
> down and email them individually?
>
> This is new territory for me, so I apologize if anything I said sounds
> stupid.
>
> Regards,
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises ​
>
>
​Hi again,

I haven't received any direction for what to do here, so I opened this
issue on the libsodium-php repo:

https://github.com/jedisct1/libsodium-php/issues/127

If we get a full checklist of consent from every contributor, including
Frank, that should be enough to unblock this pull request, no?​

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises ​

Re: [PHP-DEV] Getting fd from stream

[Niklas Keller]

>
> On Thu, Jul 6, 2017 at 10:53 AM, Kalle Sommer Nielsen 
> wrote:
> > 2017-07-06 11:12 GMT+02:00 Martijn van Duren :
> >> I have an (exotic) case where I need to be able to get the
> >> filedescriptor from a previously opened stream (via stream_socket_pair)
> >> to hand over to the child process, which needs to reexecute.
> >>
> >
> "hand over to a child process"
> Child as in pcntl_fork()? Or a subprocess via exec() et. al.?
>
> For the former, the variable should (I think) carry over.
> For the latter, the stream number is going to be a meaningless value
> to the subprocess. ((e.g. stdin (fd=0) for the parent is a different
> source than stdin for the child, despite being the same number)).
>
> I'm not sure of your exact use case, but you might be able to use
> proc_open to spawn the child and supply the socket in the descriptor
> spec which will (I think, iirc) bind the internal socket to a new pipe
> between the parent and child.  Though it's possible you'll need to
> maintain a proxy loop in the parent.
>
> 40% of the above is guesswork and conjecture, but maybe it'll spawn
> the right question.


There's a (I think undocumented) feature that allow transferring sockets to
other processes with the socket extension.

https://github.com/amphp/aerys/commit/40fae01e4f5f82570a0bc3cb8ebbf1fee36dbb0b

Bob implemented that, so maybe he can help you.

But what's your exact use case?

Regards, Niklas

Re: [PHP-DEV] Getting fd from stream

[Sara Golemon]

On Thu, Jul 6, 2017 at 10:53 AM, Kalle Sommer Nielsen  wrote:
> 2017-07-06 11:12 GMT+02:00 Martijn van Duren :
>> I have an (exotic) case where I need to be able to get the
>> filedescriptor from a previously opened stream (via stream_socket_pair)
>> to hand over to the child process, which needs to reexecute.
>>
>
"hand over to a child process"
Child as in pcntl_fork()? Or a subprocess via exec() et. al.?

For the former, the variable should (I think) carry over.
For the latter, the stream number is going to be a meaningless value
to the subprocess. ((e.g. stdin (fd=0) for the parent is a different
source than stdin for the child, despite being the same number)).

I'm not sure of your exact use case, but you might be able to use
proc_open to spawn the child and supply the socket in the descriptor
spec which will (I think, iirc) bind the internal socket to a new pipe
between the parent and child.  Though it's possible you'll need to
maintain a proxy loop in the parent.

40% of the above is guesswork and conjecture, but maybe it'll spawn
the right question.

-Sara

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

Re: [PHP-DEV] Partial Classes

[Michał Brzuchalski]

06.07.2017 15:34 "Johannes Schlüter"  napisał(a):
>
> On Do, 2017-07-06 at 13:11 +0500, Khawer . wrote:
> > Partial Classes
> >
> > If we are using same class for different purposes we can extend it,
> > and add new properties and methods. But we will also have to use new
> > class name, when we create objects. C# provides a better concept
> > "Partial Classes". Why not to also implement it in PHP?

Because class in few files won't autoload and more files cause you don't
have class in one place and switching through files may increase
frustration.
Also this would lead to ambiguity if you load few partial classes which
uses methods from not-loaded one how can you know where to find it?

> >
> > Example:
> >
> > Partial Class abc {
> >
> >   public function sayhi() {
> >echo "Hi";
> >   }
> >
> > }
> >
> > Partial Class abc {
> >
> >   public function sayhello() {
> >echo "Hello";
> >   }
> >
> > }
>
> My understanding is that C# mostly uses this for GUI stuff where
> forms/widgets are designed in a visual editor and code is written in
> text. By using partial classes those can be in different files, thus
> developers don't touch generated files.
>
> Except for that a need for splitting this up indicates a design issue
> to me. Like a class doing too many things.
>
> PHP has traits which you eventually can use to emulate such a system in
> a more explicit way.
> http://php.net/traits
>
> > Q: What will happen if both classes contain same method names?
> > A: We will show error method already exists.
> >
> > Q: Will it break any existing code?
> > A: No, there will be no impact on any existing coding because we are
> > not changing anything.
>
> It would break usage of "partial" which is not a keywor, yet.
>
> johannes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Getting fd from stream

[Kalle Sommer Nielsen]

Hi  Martijn

2017-07-06 11:12 GMT+02:00 Martijn van Duren :
> Hello internals@,
>
> I have an (exotic) case where I need to be able to get the
> filedescriptor from a previously opened stream (via stream_socket_pair)
> to hand over to the child process, which needs to reexecute.
>
> I saw that the php:// wrapper supports php://fd/X syntax, so I reckon
> there should be a way to extract the information as well from a stream
> as well. Unfortunately I don't seem to be able to find it.
>
> Can someone point me in the right direction?

It seems like this is not exposed at all by PHP.

I have CC'ed Sara as one of the old school streams persons, maybe she
has some insights why it is not exposed or if it is worth exposing
fileno() in 7.2+



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Anatol Belski]

Morning, guys,

> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Wednesday, July 5, 2017 4:39 PM
> To: Anatol Belski 
> Cc: Sara Golemon ; Jakub Zelenka ; PHP
> Internals 
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> 
>   Ok, so you strive to create a completely new RFC with a solution based
> on today's situation. I think you still don't see my point. Say there's
> insecure_allow_sha1_signature, which is a stream context. Then
> 
> 
>   - in 7.0 and 7.1
> - if absent, insecure_allow_sha1_signature = true
> - if present, the given value taken
> - impact for 7.2 migration - if explicit 
> insecure_allow_sha1_signature =
> false is in the code, no impact
>   - in 7.2
> - if absent, insecure_allow_sha1_signature = false
> - if present, depending on the decision either the exact value is 
> taken
> or ignored
> - future impact - none, the option can be even silently removed
>   - in 7.3
> - removed and disabled completely
> 
>   No see same if insecure_allow_sha1_signature is an INI
> 
>   - in 7.0 and 7.1
> - if not set, insecure_allow_sha1_signature = On
> - if set, the given value is taken
> - impact for 7.2 migration - depending on decision, either it's
> deprecated warning or disabled by default
>   - in 7.2
> - if not set, insecure_allow_sha1_signature = Off
> - if set, the given value is taken, warning is issued
>   - in 7.3
> - removed and disabled completely
> 
>   Both options do same, but in different manner. Both have advantages
> and downsides, but one option only is both necessary and sufficient to achieve
> the goal.
> 
> 
> 
> You plan assumes we'll disallow sha1 / md5 completely in the future, dunno
> whether that'll be the case. I'd prefer that.
> 
Nome, that's not mine, it's was your intention as I've remembered, might be 
wrong. Anyway, what I wanted is only to show the redundancy having multiple 
ways to do same. 

Anyway, now that Jakub also responded with an approach as well, maybe it's time 
to get an RFC get the thing done? It could have the two suggestions brought 
till now as an "exclusive or" choice and the disablement plan. The one that won 
would be followed up. An implementation were great to have before.

Both suggestions, either the separate context options for md5 and sha1, or 
security levels, do same job and only differ in the way it's done. The downside 
of security levels is, that fe the suggested security level 2 will disable 
both, while user might want to disable only sha1, that's where the separate 
options win on flexibility. Whereby having a higher security level should 
automatically ensure a certain weak functionality is disabled at once, which 
has some use as well. IMO, the INI option is a no go - the argument that user 
can get everything done at once breaks encapsulation, as not every stream in 
the app might require it.

The plan about the default disablement by version brought by Jakub sounds 
plausible, as for me. IMHO the complete disablement should not be a part of 
this RFC.

I would suggest, it's time to get on RFC and bust this issue. It would be 
great, if all the interested parties could cooperate on this.

Thanks

Anatol

Re: [PHP-DEV] Partial Classes

[Johannes Schlüter]

On Do, 2017-07-06 at 13:11 +0500, Khawer . wrote:
> Partial Classes
> 
> If we are using same class for different purposes we can extend it,
> and add new properties and methods. But we will also have to use new
> class name, when we create objects. C# provides a better concept
> "Partial Classes". Why not to also implement it in PHP?
> 
> Example:
> 
> Partial Class abc {
> 
>   public function sayhi() {
>    echo "Hi";
>   }
> 
> }
> 
> Partial Class abc {
> 
>   public function sayhello() {
>    echo "Hello";
>   }
> 
> }

My understanding is that C# mostly uses this for GUI stuff where
forms/widgets are designed in a visual editor and code is written in
text. By using partial classes those can be in different files, thus
developers don't touch generated files.

Except for that a need for splitting this up indicates a design issue
to me. Like a class doing too many things.

PHP has traits which you eventually can use to emulate such a system in
a more explicit way.
http://php.net/traits

> Q: What will happen if both classes contain same method names?
> A: We will show error method already exists.
> 
> Q: Will it break any existing code?
> A: No, there will be no impact on any existing coding because we are
> not changing anything.

It would break usage of "partial" which is not a keywor, yet.

johannes


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

[PHP-DEV] PHP 7.0.21 available

[Anatol Belski]

Hi,

The PHP development team announces the immediate availability of PHP 7.0.21.
This is a security release. Several security bugs were fixed in this release.

All PHP 7.0 users are encouraged to upgrade to this version.

For source downloads of PHP 7.0.21 please visit our downloads page:
http://www.php.net/downloads.php

Windows binaries can be found on http://windows.php.net/download/

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-7.php#7.0.21

Regards,
Anatol Belski and Ferenc Kovacs


P.S. Below is the verification information for the downloads

php-7.0.21.tar.bz2
SHA256 hash: 2ba133c392de6f86aacced8c54e0adefd1c81d3840ac323b9926b8ed3dc6231f
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJZXMxRAAoJELyqMOqcDVdjKQcIAImJR8IUdsd5YtwDMCChtW2Z
1FVuB/+zzgrvxRqG2LtRqXumQmKXFgvN/zLA2nP76w9ZKKGzacMlQoh3LtnKOLEt
zLZM7odY1NGFHjes0bXiBbUqn+uA7uV+IrSEDIOtwtvUr+IOFzaE7jjvCWxsJThC
C6BVIoW0s28lsy8I/3tKmLIoSrHf0is25rZohudGK4aLGoBWw7ltbEGxJr6Y9Rrf
atauZUPvJ1Xii7xlLBbvOefsJWskegW6eNniHQ5xhIzvr3Z7priGMOnZwsrbCio8
v4On8p2Dcg5rzyUA8Yvm/vbDdFjeco2VNitf3IMSOAvU1Levue9bcfx0aZqvYUQ=
=2nHR
-END PGP SIGNATURE-


php-7.0.21.tar.gz
SHA256 hash: f2f05f629dd02c75834ddf033916bd5ff92a720602839d81fd8b6d90e37b6225
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJZXMxUAAoJELyqMOqcDVdj3yUIALGqG1D58W1y1GJHmwLLJuOf
HnepD5FcRJKVvWILawE49yHP8oDJmpcl2a3hHdpCJLvyWMjZOMAhn3BQInvgW7uZ
wE6ZMPKH0ZjJBsMOUGw9OgDSePf4Avffg22TelFEIhXf2vxs0y8/DdKxU3qSdJjf
ZOcc+QjO34bsVY0Ejhy5vuUQn2Eym0qNdWUtG2iomvpvilm7imT1AelFUauFDtrq
5X6sQxwRFqGdWzIHk/fND7ROk5WYqhmbpQGoP1TjJ8Hvpb6oFYdI8m3lHWK1GUUl
kBMeSq+dZDqSqEQGl4+sn8R4wVI8vNY0RpWpCavR2dizCavALQCsIE7zQMSY4vY=
=Yiyf
-END PGP SIGNATURE-


php-7.0.21.tar.xz
SHA256 hash: 6713fe3024365d661593235b525235045ef81f18d0043654658c9de1bcb8b9e3
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJZXMxXAAoJELyqMOqcDVdjUaoIAIxw0zGEV32r4cr3PuPap7f4
4pOtAs3MliPQFWURDC8xq8K0WFuhtHgAeizY5vd1kyhkbo/JFbvxEQPABpPcz+5V
RsKRjUn5sWztitXZgNMJbdfY/NeyVaa0/KRHLeKLijiW7Q61ZZLl24ow17EDrLYZ
dPQvSPrKiZEK0HSQIfJ9JWnjbqbAqvRU39Nskx0V7bwPAPND4wjM9yFPRb+O5Mim
UGGykGhKx1vlFCzgEGNPi9vUJBZEy2vhhj1hcNNUOP3SqQuzvmIvbGVRsXh5EFFV
keV2Xduah4nW1bKoPOJXpduh6cwYCTJzhBACoPEZP6qMxvqGcwe9CrTAkQ1cf1g=
=1I+n
-END PGP SIGNATURE-



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

[PHP-DEV] PHP 7.2.0 Alpha 3 Released

[Remi Collet]

The third alpha for 7.2.0 was just released and can be downloaded
from: https://downloads.php.net/~remi/
Or using the git tag: php-7.2.0alpha3

The Windows binaries are available at: http://windows.php.net/qa/

Please test it carefully, and report any bugs in the bug system.
The next release will be tagged on Tuesday July 18th and released on
Thursday July 20th.

This first Beta will also be
- feature freeze
- PHP-7.2 branch

Get your RFCs implemented unless you want to wait for PHP-7.3

See below for Hash Values and GPG signatures

Thank you, and happy testing!


Remi




php-7.2.0alpha3.tar.gz
MD5 hash: 3ea8b6af1e000dc0f74e20fd0f62eed8
SHA256 hash:
4ca81dba4e6fc8c94c484e8af90a1e6c80254c7bdb4ef4201d2aa7aefb1a2ecd
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJZW1+9AAoJENyf+NPuWvJ/2cMQAJp+wlGYulUSqfnwtVQBP8f6
nzL9x1bnoIKypKIPQfTOmBhgDn3jwdLPJzES5sgUYt36NVEZqW9LMXQrfSILeRms
W9qHGPR5h9DnxJCAamYSDErjh3ZKeG0BE7Iicbv0ip2kBApQ8X6gnyT65nYqcNir
9NLph0nG5XQ4S2tWZ/3zf8do/8xGavuUKAom2vpc4Khk/PR8vUQifrNEBHKETBxG
0zspelzVscu+7Jii6kYGWJhEEvO5SGyExBy4/X85KUNv/fOurbCFNK+GShs/tMoX
E+0VTBYGFmNjr8bP3agtEi5mVeKgSNyOLSr1C2AfZwqDUv7kWYzn8mUJMbBFS26e
y5ZO1Hv0OVq8GD/LLlFnLuRrlLxhbgTGr85OS1bgGFgas10RRrWHgODfESxz8JdH
6YG4fEW0hVEjq1CmZ7OQKoDtxFITa/OPJjS3110OVjk9LYcN6lS6UolfDNYU7Bfs
eGgpHZzg61j33m5MpeNOzDYrpNDKs42uykNNsT2jNIi3qy6h8FLhBeTANhOYJHx7
T1nHua02tXqMRn+/cHx37GZqYuY22AQ4WumjYHpce5xkcwr5+CoE6USLZmgZdFwc
vWx2ci+EkpvKDwIXcbkzz+4EirCQ4lma1ToKSyARyK3qGN7KtLk8J9HoAmV8aNQR
V4pfp56R402wOI3ugxNx
=oWpG
-END PGP SIGNATURE-

php-7.2.0alpha3.tar.bz2
MD5 hash: b83efbc529eb27724c59dd301f4205e8
SHA256 hash:
05b95efe75b66608b717bb2f6e5588d5f0d57bcf6957a6beb94ffa207d3a33fa
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJZW1/AAAoJENyf+NPuWvJ/KuIP/1P3kWpAMQQ0I1qC3hBvMksl
6nLT0n3Mhk3HbgbupaMR69EyK4ULPpc0hz+hHtt81UBGfBC8u0e65kTz1MKH3MvF
rS8dWlrBL7O45VwioKw/LBp2YjjKePfy27fcVqybdsw3N+39yChOWDQzF58bMjwq
M0RZWS8Z7R2aZBZBJveMTK2Yrmma/5yutG3hDwPcnsu3pMgBoHu0mxNOvKPZdi8K
d7iRAZVAgfEbmoyfQSDqmJG+HBoTqNrLb/1oQWpYlR2KLSwOuwZkA+z4xIUygKqx
cHtdV8uKWn7iZIYWs8P2XBwiTeWpA84qchKS0ylY4W4usEvaL2t5+pn+ABUeZ/N/
65xMGREtYjFQALjxwrc1m8qxY6aHLclSHCh6YRAual+Z0aTkimG1GhS+tl/oCI8X
GfgYpLCqw7xa9KJngDz7Iuq2RLkw7KHAwdQO/1YOTHWOOi/Dwy/8ZM/XMWOVRGA0
xkgbI8V27wF35RonU1h/ZqpaiTNkLe7Q/gmKOk5K1LFX8h1+dO6WFuexfdUnrx+G
76496PBXCTacm05+fWAtx6/bFoOtdwhjmS+wieiCSo4tMGCLW8AGsYAvKGlxXDKa
syJUhcgC0TakrSBsBNMZ4BTpuahSbRm/whmx5AFeZ7Rk4DsSLhp6TzkGhXaFpv5T
f/p3bRpPJRfc7CXHUU5t
=KLlQ
-END PGP SIGNATURE-

php-7.2.0alpha3.tar.xz
MD5 hash: de555e594f4211d0152c6a762762ae01
SHA256 hash:
68abd6fc51cc5cfc7a7b1c2153644c7052f3ed841c21519095dda24eee67f63b
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJZW1/DAAoJENyf+NPuWvJ/GDMP/0RgkjOOK0kkbIgId1zXCl4O
47p/fqzeVQ1kxF+TNxWwLyMLI/3hVUI0d3W1/oci+CWGcw60DuAk0PMrlaiSiXSq
jfJNBsw9g06L0e+DkDdNbkV0Xqlk7ykxr+nKWcFulQGsyvqjFR522hyT6wdNPTyZ
EXHn1L9EJMqmsbOzwBCV0CKtC69J/QdDWjjiZj1tAIRZVNAY4xTuTEj/ddIj3Kav
XrlTCyWluOHQ9ChFD1v6Ip3P3j3p2wjb9fpKhtFzcFLDR7b6WSmhoU1kvb8kk+fx
gi94HWNExQDsEdI4zoR2d+qfQ1vwNzRxiFROQDyKxO3AICuDIc39vYVvkp51Ti/O
Yil1lPilDrsMsqr4pWWxCGWyn6KQA03tsxpHS/Ygd9kaHcjPwDI0kQStsxq+fKcK
/jasOpnYRTtxq2qaYl8fNJTWdc7bCcl9rclTNSuw9K0iaKsjTVg57wDlrYbJrd21
6iXxSTcCEXMI1hjtXGU2+uLLN0h5Ruy+WUtEPqKOdZP8HLtNpeVj0pZ3NENdGWEv
oRADQ5cc3zx4B300FSDZmAepP2WkBi/3gGo1eI0v7wmvu57WDE04ujQfbUwpJ/Rz
8f2u8HfxwRd+RNedNM1kYJPfkUWcDiw8yiI1VMRt0aWKlxUm3FbjO8R1xPVhcKvG
cpfE/ogRQ74ovhHkw2Pp
=vVXO
-END PGP SIGNATURE-

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

[PHP-DEV] Getting fd from stream

[Martijn van Duren]

Hello internals@,

I have an (exotic) case where I need to be able to get the
filedescriptor from a previously opened stream (via stream_socket_pair)
to hand over to the child process, which needs to reexecute.  

I saw that the php:// wrapper supports php://fd/X syntax, so I reckon
there should be a way to extract the information as well from a stream  
as well. Unfortunately I don't seem to be able to find it.

Can someone point me in the right direction?

Sincerely,

Martijn van Duren

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

Re: [PHP-DEV] Change -> to dot(.)

[li...@rhsoft.net]

Am 06.07.2017 um 08:13 schrieb Khawer.:

In all major programming languages we access object properties and methods
using dot(.).

C#:
Abc Abc = new Abc();
Abc.method();

Java:
Abc Abc = new Abc();
Abc.method();

JavaScript:
var apple = new function() {
 this.name = "Test";
}
alert(apple.name());


Why not to make PHP similar to these languages by allowing to access object
properties and methods using dot(.)


to gain what?


We will still


who is "we"


keep "->" until PHP 8 to maintain backward compatibility


and then force to rewrite every single piece of code out there?
that's a "have a solution and seeking for the problem"

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

[PHP-DEV] Partial Classes

[Khawer .]

Partial Classes

If we are using same class for different purposes we can extend it, and add
new properties and methods. But we will also have to use new class name,
when we create objects. C# provides a better concept "Partial Classes". Why
not to also implement it in PHP?

Example:

Partial Class abc {

  public function sayhi() {
   echo "Hi";
  }

}

Partial Class abc {

  public function sayhello() {
   echo "Hello";
  }

}

Q: What will happen if both classes contain same method names?
A: We will show error method already exists.

Q: Will it break any existing code?
A: No, there will be no impact on any existing coding because we are not
changing anything.

Re: [PHP-DEV] Change -> to dot(.)

[Michał Brzuchalski]

06.07.2017 09:43 "Niklas Keller"  napisał(a):
>
> Stephen Reay  schrieb am Do., 6. Juli 2017,
09:04:
>
> >
> > > On 6 Jul 2017, at 13:13, Khawer .  wrote:
> > >
> > > In all major programming languages we access object properties and
> > methods
> > > using dot(.).
> > >
> > > C#:
> > > Abc Abc = new Abc();
> > > Abc.method();
> > >
> > > Java:
> > > Abc Abc = new Abc();
> > > Abc.method();
> > >
> > > JavaScript:
> > > var apple = new function() {
> > >this.name = "Test";
> > > }
> > > alert(apple.name());
> > >
> > >
> > > Why not to make PHP similar to these languages by allowing to access
> > object
> > > properties and methods using dot(.). We will still keep "->" until
PHP 8
> > to
> > > maintain backward compatibility.
> >
> > In each of those languages, the plus operator is used for string
> > concatenation.
> >
> > In PHP the dot operator is used for string concatenation, and objects
can
> > be cast to strings when concatenating, so how do you differentiate the
two
> > calls at the end of this block:
> >
> > class Bar {
> > public function baz() {…}
> >
> > public function __toString(): string {...}
> > }
> >
> > function baz(): string {…}
> >
> > $foo = new Bar();
> > $foo.baz(); // call method Baz on object $foo
> > $foo.baz(); // concat the result of casting $foo to string, with the
> > result of calling baz()
> >
>
> Obviously by using plus for concatenation.

That would be huge BC break because plus on string which ale numerical is
adding numbers so result fir now would be sum. Not concatenated string.

>
> Regards, Niklas
>
> >

Re: [PHP-DEV] Change -> to dot(.)

[Niklas Keller]

Stephen Reay  schrieb am Do., 6. Juli 2017, 09:04:

>
> > On 6 Jul 2017, at 13:13, Khawer .  wrote:
> >
> > In all major programming languages we access object properties and
> methods
> > using dot(.).
> >
> > C#:
> > Abc Abc = new Abc();
> > Abc.method();
> >
> > Java:
> > Abc Abc = new Abc();
> > Abc.method();
> >
> > JavaScript:
> > var apple = new function() {
> >this.name = "Test";
> > }
> > alert(apple.name());
> >
> >
> > Why not to make PHP similar to these languages by allowing to access
> object
> > properties and methods using dot(.). We will still keep "->" until PHP 8
> to
> > maintain backward compatibility.
>
> In each of those languages, the plus operator is used for string
> concatenation.
>
> In PHP the dot operator is used for string concatenation, and objects can
> be cast to strings when concatenating, so how do you differentiate the two
> calls at the end of this block:
>
> class Bar {
> public function baz() {…}
>
> public function __toString(): string {...}
> }
>
> function baz(): string {…}
>
> $foo = new Bar();
> $foo.baz(); // call method Baz on object $foo
> $foo.baz(); // concat the result of casting $foo to string, with the
> result of calling baz()
>

Obviously by using plus for concatenation.

Regards, Niklas

>

Re: [PHP-DEV] Change -> to dot(.)

[Stephen Reay]

> On 6 Jul 2017, at 13:13, Khawer .  wrote:
> 
> In all major programming languages we access object properties and methods
> using dot(.).
> 
> C#:
> Abc Abc = new Abc();
> Abc.method();
> 
> Java:
> Abc Abc = new Abc();
> Abc.method();
> 
> JavaScript:
> var apple = new function() {
>this.name = "Test";
> }
> alert(apple.name());
> 
> 
> Why not to make PHP similar to these languages by allowing to access object
> properties and methods using dot(.). We will still keep "->" until PHP 8 to
> maintain backward compatibility.

In each of those languages, the plus operator is used for string concatenation.

In PHP the dot operator is used for string concatenation, and objects can be 
cast to strings when concatenating, so how do you differentiate the two calls 
at the end of this block:

class Bar {
public function baz() {…}

public function __toString(): string {...}
}

function baz(): string {…}

$foo = new Bar();
$foo.baz(); // call method Baz on object $foo
$foo.baz(); // concat the result of casting $foo to string, with the result of 
calling baz()
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Exposing object handles to userland

[Michał Brzuchalski]

06.07.2017 07:24 "tyson andre"  napisał(a):
>
> Updated https://github.com/TysonAndre/php-src/pull/1 , which is now much
shorter.
>
> In response to Nikita Popov's comments:
>
> > I'm +1 on the addition and would be fine with including it without RFC,
if
> > there are no objections on internals.
>
> How long should I wait to see if there are objections before creating a
pull request?

AFAIK you can create PR any time.

>
> > > - Can two objects can have the same object id
> > >   but different object handlers?
> > No: In PHP 7 this is not possible, which is also why spl_object_hash()
no
> > longer includes the handlers.
>
> True. Checking again, the implementation of spl_object_hash
> doesn't include the handlers, so I don't need to worry.
>
> > You can drop the masking. It was never effective at what it's supposed
to
> > do (hide memory addresses), but as this is the object ID only, it is
> > completely unnecessary here.
> > [...]
> > Only in the sense that it could theoretically wrap around to negative
> > numbers. Of course those would still serve as IDs just as well.
>
> That makes sense. I'm omitting the XOR
> (and returning the unobfuscated object handle/id)
> in the proposed change, then.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Change -> to dot(.)

[Marco Pivetta]

What's the point?

Sorry for the snarky response, but it had to be done 

On 6 Jul 2017 8:13 AM, "Khawer ."  wrote:

In all major programming languages we access object properties and methods
using dot(.).

C#:
Abc Abc = new Abc();
Abc.method();

Java:
Abc Abc = new Abc();
Abc.method();

JavaScript:
var apple = new function() {
this.name = "Test";
}
alert(apple.name());


Why not to make PHP similar to these languages by allowing to access object
properties and methods using dot(.). We will still keep "->" until PHP 8 to
maintain backward compatibility.

Re: [PHP-DEV] Change -> to dot(.)

[ilija . tovilo]

The dot is already the string concatenation operator. This would be a horrible 
migration process. The PHP team is never going to upset the developer 
experience that much for a purely cosmetic change.

Also, C and C++ use the -> symbol, two major languages.

Regards

On 6 Jul 2017, 08:13 +0200, Khawer . , wrote:
> In all major programming languages we access object properties and methods
> using dot(.).
>
> C#:
> Abc Abc = new Abc();
> Abc.method();
>
> Java:
> Abc Abc = new Abc();
> Abc.method();
>
> JavaScript:
> var apple = new function() {
> this.name = "Test";
> }
> alert(apple.name());
>
>
> Why not to make PHP similar to these languages by allowing to access object
> properties and methods using dot(.). We will still keep "->" until PHP 8 to
> maintain backward compatibility.

[PHP-DEV] Change -> to dot(.)

[Khawer .]

In all major programming languages we access object properties and methods
using dot(.).

C#:
Abc Abc = new Abc();
Abc.method();

Java:
Abc Abc = new Abc();
Abc.method();

JavaScript:
var apple = new function() {
this.name = "Test";
}
alert(apple.name());


Why not to make PHP similar to these languages by allowing to access object
properties and methods using dot(.). We will still keep "->" until PHP 8 to
maintain backward compatibility.