Re: [PHP-DEV] Re: [RFC][DISCUSSION] Session ID without hashing

Hi! > Concern has been discussed is risk of broken PRNG and predictable > session ID. We may insist any platform must have reliable PRNG, but it > would be good idea to have least mitigation. Reading extra bytes > should be good enough for this purpose. I still see no reason to change it stated i

Re: [PHP-DEV] [RFC] Simple Annotations

On 06/28/2016 04:24 PM, Rasmus Schultz wrote: This was just an example of a value object - for example: class HttpMethod { private $method; protected function __construct($method) { $this->method = $method; } public function getMethod() { return $this->met

Re: [PHP-DEV] [RFC] Simple Annotations

This was just an example of a value object - for example: class HttpMethod { private $method; protected function __construct($method) { $this->method = $method; } public function getMethod() { return $this->method; } public static function get() {

Re: [PHP-DEV] [RFC] Simple Annotations

On 28 June 2016 20:10:15 GMT+01:00, Pedro Cordeiro wrote: >> << HttpMethod::post() >> // equivalent to static method-call >> HttpMethod::post() >> > >What would this, specifically, do? Would it call HttpMethod::post() >when >the class gets instantiated and return its return on a >ReflectionClass:

Re: [PHP-DEV] [RFC] Simple Annotations

> << HttpMethod::post() >> // equivalent to static method-call > HttpMethod::post() > What would this, specifically, do? Would it call HttpMethod::post() when the class gets instantiated and return its return on a ReflectionClass::getAnnotations()? Why is it necessary to be able to evaluate expres

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

Hi! >> Voting has opened on the RFC to change most conditions in extensions that >> raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead. >> >> RFC: https://wiki.php.net/rfc/throw_error_in_extensions >> >> PR: https://git

Re: [PHP-DEV] [RFC] Simple Annotations

Thanks, Richard and Rowan - this gives me more to work with! I will work on a new proposal and ask for more input when I have a draft ready :-) On Tue, Jun 28, 2016 at 7:56 PM, Rowan Collins wrote: > On 28/06/2016 17:31, Rasmus Schultz wrote: >> >> For another, eager construction means we can f

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

Hi Jakub, > On Jun 28, 2016, at 12:28 PM, Jakub Zelenka wrote: > > Hi, >> >> > Just noticed the openssl case in X509_digest and it's obviously oversight > by whoever added that bit because it should be warning as it's for all > other similar fails. I'm going to change it to warning to make it

Re: [PHP-DEV] [RFC] Simple Annotations

On 28/06/2016 17:31, Rasmus Schultz wrote: For another, eager construction means we can filter annotations with instanceof rather than by class-name, which is much powerful, enabling you to leverage inheritance - for example, you'd be able to ask directly for all instances of ValidationAnnotation

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

Hi, On Mon, Jun 27, 2016 at 4:17 PM, Aaron Piotrowski wrote: > Hello, > > Voting has opened on the RFC to change most conditions in extensions that > raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead. > > RFC: https://wiki.php.net/rfc/throw_error_in_extensions < > https:

Re: [PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

> Am 28.06.2016 um 18:41 schrieb Nikita Popov : > > On Tue, Jun 28, 2016 at 6:16 PM, Dmitry Stogov wrote: > >> Hi internals, >> >> >> The RFC has been moved into voting stage: >> >> >> https://wiki.php.net/rfc/async_signals >> >> >> Thanks. Dmitry. >> > > What about Bob's suggestion to

Re: [PHP-DEV] [RFC] Simple Annotations

On 6/28/2016 6:31 PM, Rasmus Schultz wrote: > Since the discussion isn't completely dead yet (thank you Pedro and > Marco), I will just briefly explain what I had in mind for another > RFC. > I want to see this feature happen too but the right way, so let us just spend some more time wrapping our

Re: [PHP-DEV] [RFC] Simple Annotations

Hi Rasmus, I think you may be onto something here... :) On 28/06/2016 17:31, Rasmus Schultz wrote: The UnknownAnnotation object has three properties: class-name, method-name ("__construct" if constructor was used) and the list of arguments. I'm not sure we need an extra UnknownAnnotation cla

Re: [PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

pcntl.async_signals=0 leads to exactly the same behavior as it was in 5.* and 7.0. Allow manual handling and using TICKs. pcntl.async_signals=1 - new behavior with interrupts. Thanks. Dmitry. From: Nikita Popov Sent: Tuesday, June 28, 2016 19:41 To: Dmitry

Re: [PHP-DEV] [RFC DISCUSSION] var_info

On 6/28/2016 12:44 AM, Dan Ackroyd wrote: > The RFC doesn't seem to state any reason why this should be in core, > rather than in a userland library. > I will extend the RFC on the weekend with the missing information, thanks for the heads up. On 6/28/2016 4:21 AM, Jesse Schalken wrote: > I think

Re: [PHP-DEV] [RFC DISCUSSION] Error Storage Behavior

On 6/27/2016 9:53 PM, Stanislav Malyshev wrote: > Hi! > >> Currently error_get_last() always contains the last error that occurred, >> however, this is actually not desired if the last error was an exception >> that was caught. >> >> https://github.com/php/php-src/pull/1936 > > I think conditioni

Re: [PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

On Tue, Jun 28, 2016 at 6:16 PM, Dmitry Stogov wrote: > Hi internals, > > > The RFC has been moved into voting stage: > > > https://wiki.php.net/rfc/async_signals > > > Thanks. Dmitry. > What about Bob's suggestion to add a flag (for disabling async signals) to pcntl_signal() instead of having a

Re: [PHP-DEV] [RFC] Simple Annotations

Note that I only make comparisons with doc-blocks to point out the fact that, functionally, they would not be very different from an annotation feature that solely permits you to annotate with values. A doc-block is a string, which is a value - an array/int/float/string/bool is a value. It's only v

[PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

Hi internals, The RFC has been moved into voting stage: https://wiki.php.net/rfc/async_signals Thanks. Dmitry.

Re: [PHP-DEV] [RFC] Simple Annotations

I completely agree with Marco. Throwing class-loading errors for value-object classes is alright. For logic-parsing inside annotations, I don't feel any need for it. Metadata should be static, IMO, but it could very well be (and should be) value-objects. >At the end of the day, what we end up with

Re: [PHP-DEV] [RFC] Simple Annotations

Hi Rasmus, On 27 June 2016 at 20:37, Rasmus Schultz wrote: > Tonight I started trying to write a proposal for even more simplified > annotations, e.g. something simple enough that it cannot result in > fatal errors. I eventually gave up, and here's why. > > Essentially, if you have to restrict y

Re: [PHP-DEV] PHP 7.1.0 Alpha 2 Released

2016-06-28 12:37 GMT+02:00 Joe Watkins : > Hi, > > The second alpha for 7.1.0 was just released and can be downloaded from: > > https://downloads.php.net/~krakjoe/ > > The Windows binaries are available at > > http://windows.php.net/qa/ > > Please test it carefully, and report any bugs in the bug

[PHP-DEV] Re: [RFC][DISCUSSION] Session ID without hashing

Hi all, On Wed, Apr 6, 2016 at 2:47 PM, Yasuo Ohgaki wrote: > Session module does not require hashing to generate session ID. This > RFC removes hashing from session module and enable use_strict_mode as > an insurance for broken RNG. > > https://wiki.php.net/rfc/session-id-without-hashing > > Com

[PHP-DEV] PHP 7.1.0 Alpha 2 Released

Hi, The second alpha for 7.1.0 was just released and can be downloaded from: https://downloads.php.net/~krakjoe/ 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 June 21s

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-06-28

Results for project PHP master, build date 2016-06-28 06:30:25+03:00 commit: ae8cf3cb previous commit:e539823 revision date: 2016-06-27 14:23:00-07:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB