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

Hi Davey, On Sun, Jul 24, 2016 at 2:37 PM, Davey Shafik wrote: > > It didn't actually reopen, and just setting closed to false, it kept the > original votes. So I added a second vote below. Bonus: the original is also > preserved. > > Hope that's OK. Oops, I thought flip-flopped

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

Yasuo, It didn't actually reopen, and just setting closed to false, it kept the original votes. So I added a second vote below. Bonus: the original is also preserved. Hope that's OK. - Davey On Sat, Jul 23, 2016 at 9:50 PM, Yasuo Ohgaki wrote: > Hi all, > > Due to a

Re: [PHP-DEV] RFC: lazy statements

Dan Ackroyd wrote: > This looks to solve a problem very similar to the one solved by the > 'Memoize' annotation in HHVM - > https://docs.hhvm.com/hack/attributes/special#__memoize > However the memoize functionality seems a lot clearer to me, as it's > less 'magic'; it doesn't make accessing a

[PHP-DEV] [RFC][VOTE] Session ID without hashing - Reopened

Hi all, Due to a defect in the RFC, vote is reopened for a week. Removed lines are indicated by . No additional lines nor modifications other than removed lines for session.use_strict_mode change. Sorry for the confusion! Currently session module uses obsolete MD5 for session ID.

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

Hi Yasuo, On Jul 24, 2016 10:51 AM, "Yasuo Ohgaki" wrote: > > Hi all, > > On Sun, Jul 24, 2016 at 6:13 AM, Stanislav Malyshev wrote: > >> Changing the RFC during voting requires a _restart_ not an extension. > >> The vote must be re-run. I will not put

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

Hi all, On Sun, Jul 24, 2016 at 6:13 AM, Stanislav Malyshev wrote: >> Changing the RFC during voting requires a _restart_ not an extension. >> The vote must be re-run. I will not put this in 7.1 without a new vote. > > OK, looks like I was underestimating the magnitude of

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

Hi! > Changing the RFC during voting requires a _restart_ not an extension. > The vote must be re-run. I will not put this in 7.1 without a new vote. OK, looks like I was underestimating the magnitude of the messiness that this change (or lack of it) brought to a vote. Let's re-run the vote

Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 1:11 PM, Stanislav Malyshev wrote: > There is a lot of ways in which PHP needs improvement, but right now I > think inventing more syntax tricks in not one of them. Even in syntax > department, PHP has areas where we could use improvement (e.g. to name

Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 8:15 AM, Rowan Collins wrote: > Glad it makes sense. :) I realise "return $$" would have to have some > special handling, but it would feel more natural to me. I guess the only > concern is what happens when a pipeline has a return terminal and is

Re: [PHP-DEV] Pipe Operator v2

On Sat, Jul 23, 2016 at 4:15 AM, Rasmus Schultz wrote: > FWIW, I've read the manual page for the Hack page, and the RFC, a couple of > times now, and I simply don't understand it. > Perhaps the documentation needs clarifying then. > Are most PHP developers going to understand

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

Stas, The issue is that changes were made once the voting started, and some of us were waiting for the vote to restart: > I'd like to see the vote re-run (1 week?) with the changes in place. I didn't vote because I expected it to be restarted. I would have voted -1 on the current proposal.

Re: [PHP-DEV] Pipe Operator v2

Hi! >> $x = loadConfig(); >> $x = buildDic($x); >> $x = getApp($x) >> $x = getRouter($x) >> $x = getDispatcher($x, $request) >> $x = dispatchBusinessLogic($x, $request, new Response()) >> $x = renderResponse($x) >> $x = buildPsr7Response($x) >> $response =emit($x); >> > > I agree the example

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

Hi! > We already had a vote, at it was completed. Having another vote on the > same subject, slightly modified, is highly irregular and contrary to > voting RFC, which mandates 6 month period or *substantial* changes (with > assumed new discussion period I imagine, since past discussion can't >

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

Hi! > I missed to remove the related lines in RFC. I marked the line by . > I don't mind reopen the vote few days. Any objections? > If no objections, I'll reopen vote few days. We already had a vote, at it was completed. Having another vote on the same subject, slightly modified, is highly

Re: [PHP-DEV] RFC: lazy statements

Hi! > This Feature Request is about the implementation of lazy statements. > > Basically it should implements a 'lazy' keyword (or similar) and > structured like an anonymous function, except that it doesn't accepts > arguments, but accept the use() feature. > > $var = lazy { return 1; }

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

Not replying to anyone in particular or quoting anything so I'll start afresh. This is with the topic though, but I'm going to step outside of the box a bit. PHP was a template engine at inception. It still is to some degree - hence braceless syntax. The argument can be made that while the

[PHP-DEV] Best way to fix #71929 curl_getinfo($ch, CURLINFO_CERTINFO)

Hi, I'm currently looking at bug #71929 and i'm wondering what is the best way to fix it. Basically the bug is that currently ext/curl tries to parse the "Subject" and "Issuer" returned by lib/curl to return this information as a PHP array. Here is the actual output : array ( 'Subject' =>

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

On 07/23/2016 05:23 PM, Rowan Collins wrote: > On 22/07/2016 15:54, Michael Vostrikov wrote: >>> The more you compare it to a function call, the less I understand >>> how it >> gains over just defining a function e() and writing > 'html') ?> >>> > I might as well just write "function e($string,

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

On 22/07/2016 15:54, Michael Vostrikov wrote: The more you compare it to a function call, the less I understand how it gains over just defining a function e() and writing > I might as well just write "function e($string, $mode='html') { }" > they will already have a method of doing this

Re: [PHP-DEV] Pipe Operator v2

On 22/07/2016 06:52, Sara Golemon wrote: Ah! I understand your point now. Indeed, in terms of code-scan, there's something of a whiplash effect going on. Now I understand the motivation behind $> assignment and/or using a terminal like `return $$` at the end. Adding in support for some

[PHP-DEV] [RFC] [Declined] var_info

Hi! The vote on https://wiki.php.net/rfc/var_info is now closed. The RFC was declined with 0 "Yes" and 25 "No" votes. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

[PHP-DEV] [RFC] [Declined] var_type

Hi! The vote on https://wiki.php.net/rfc/var_type is now closed. The RFC was declined with 4 "Yes" and 15 "No". -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

On 22/07/2016 19:41, David Rodrigues wrote: Fifth point: you can't use arguments on each escape to change the mean of what happen, so I need define each possibility (that could be a lot). For instance: imagine that I have a escape that does, on reality, a "clamp" that do a $value bet more than

Re: [PHP-DEV] Pipe Operator v2

On 23/07/2016 12:15, Rasmus Schultz wrote: I mean, maybe it's just me, because I'm familiar with the cascade operator from other languages - but it seems simpler, more intuitive, easier to pick up, and appears to solve most of the same problems? If so, perhaps it would be right to consider the

Re: [PHP-DEV] Pipe Operator v2

FWIW, I've read the manual page for the Hack page, and the RFC, a couple of times now, and I simply don't understand it. Are most PHP developers going to understand this feature, the meaning of $$, and when/how to use this? Are they going to be able to read code written in this way? To your

Re: [PHP-DEV] RFC: lazy statements

Hi David, On 21 July 2016 at 16:51, David Rodrigues wrote: > This Feature Request is about the implementation of lazy statements. This looks to solve a problem very similar to the one solved by the 'Memoize' annotation in HHVM -