Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Yasuo Ohgaki]

Hi Andrey,

On Fri, Apr 8, 2016 at 6:54 PM, Andrey Andreev  wrote:
> On Fri, Apr 8, 2016 at 12:29 PM, Yasuo Ohgaki  wrote:
>>
>> Hi Andrey,
>>
>> On Fri, Apr 8, 2016 at 6:20 PM, Andrey Andreev  wrote:
>> > On Fri, Apr 8, 2016 at 11:33 AM, Yasuo Ohgaki 
>> > wrote:
>> >>
>> >> Hi Andrey,
>> >>
>> >> On Fri, Apr 8, 2016 at 4:57 PM, Andrey Andreev 
>> >> wrote:
>> >> >>
>> >> >> PS(gc_maxlifetime) is needed, so I fixed the last commit.
>> >> >>
>> >> >
>> >> > It is necessary for probability-triggered GC because you don't have
>> >> > another
>> >> > way of giving a TTL value then, but that's not the case for a direct
>> >> > session_gc() call.
>> >>
>> >> PS(gc_maxlifetime) is not related directly to probability based GC,
>> >> but it's about which session should be deleted.
>> >>
>> >> Save handlers are supposed to delete inactive sessions exceeds
>> >> PS(gc_maxlifetime) when GC is issued. Save handlers are not suppose to
>> >> use PS(vars) directly and should use passed TTL parameter. Therefore,
>> >> the parameter is passed.
>> >>
>> >
>> > It is not directly related to gc_probability it is very obviously the
>> > result
>> > gc_probability-based design.
>> >
>> > Still, even if we agree to disagree on that, it's not a blocker for
>> > maxlifetime being overridable via a parameter.
>>
>> We need TTL value and the TTL is gc_maxlifetime.
>> How would you specify session data to be removed?
>>
>> TTL value is mandatory.
>
>
>
> I wrote this pseudo-code in my very first reply to this thread ...
>
> function session_gc($ttl = ini_get('session.gc_maxlifetime')) {}
>
> If that's unclear, here's a more verbose way to put it:
>
> function session_gc($ttl = null)
> {
> if (empty($ttl))
> {
> $ttl = ini_get('session.gc_maxlifetime');
> }
>
> // ...
> }
>
> It just gives the ability to override the INI value for those who don't want
> or need it.

I thought you claim that use of gc_maxlifetime is wrong.

3. If session_gc() bypasses the gc_probability, gc_divisor INI
settings*, then why does it still rely on gc_maxlifetime?

Anyway, you're suggesting session_gc() should have $ttl =
ini_get('session.gc_maxlifetime') as the TTL parameter. This sounds
reasonable and I'll add optional 1st parameter.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

[PHP-DEV] Re: Req #69959 [Com]: unserialize() needlessly requires boilerplate

[Yasuo Ohgaki]

Hi all,

On Sat, Apr 9, 2016 at 8:07 AM, lucas at threeamdesign dot com dot au
 wrote:
> Edit report at https://bugs.php.net/bug.php?id=69959=1
>
>  ID: 69959
>  Comment by: lucas at threeamdesign dot com dot au
>  Reported by:lucas at threeamdesign dot com dot au
>  Summary:unserialize() needlessly requires boilerplate
>  Status: Suspended
>  Type:   Feature/Change Request
>  Package:*General Issues
>  PHP Version:7.0.0alpha2
>  Block user comment: N
>  Private report: N
>
>  New Comment:
>
> I'm sure you're time poor, but it seems you haven't really read my proposal. 
> I offered a perfectly sound and *completely backwards-compatible* solution.
>
> Adding an *optional* second parameter, that is a reference to whether the 
> deserialization was successful, means the function's return value can stay 
> the same, thus no updates are required to userland code. This mirrors the 
> behaviour of `exec` where the shell return value is not the return value of 
> the function.

Last comment sounds reasonable.
How about add 2nd parameter to unserialize()?
Re-open this bug report?

What is your thoughts?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] IntlCharsetDetector

[Sara Golemon]

On Thu, Apr 7, 2016 at 9:36 AM, Bishop Bettini  wrote:
> The problem is, developers are going to write code to guess character sets.
>
True.  But they're going to put more faith in something in the
standard distribution, assuming it's passed muster.

> Ironically, PHPUnit attempts to detect UTF-8
>
Akward

> I'd rather we include the patch for a few reasons:
>
> 1. so that there's a modern "standard" method of doing so, and that
> "standard" method has plenty of documentation that points people to the
> limitations.
>
In that spirit, how about we put in some stub documentation under the
intl extension with a paragraph or two on why UCharsetDetector *isn't*
wrapped, and why it's such a bad idea to try to solve the problem from
this end.

> 2. to completely expose the underlying ICU, rather than arbitrarily
> deciding one part isn't good for developers to use.
>
Is it arbitrary though?  The fact that coming up with test cases which
produce reasonable/expected results is half crap-shoot makes this an
evidence based decision, not a capricious one.

> 3. to provide an alternative to mb_detect_encoding.
>
And again in that spirit, I think this is a good argument for going
E_DEPRECATED on mb_detect_encoding().  The entire conversation which
led to prototyping an IntlCharsetDetector extension came from the fact
that mb_detect_encoding() wasn't doing its job well.  Rather than have
two supported, bad solutions, I think it'd be better to have one
deprecated (and thus unsupported) bad solution (which is only kept for
BC).

> While I can't say if this will or won't cause more user confusion, I do
> believe this adds value: ICU provides a confidence metric, which no other
> in-built or buildable solution (to my knowledge) provides.
>
The confidence metric is useful, but my spidey sense tells me that
it'll simply be ignored.

How about a compromise.  I'll reorder this patch to be a standalone
extension and we PECLize it.  If someone REALLY wants to throw caution
to the wind, they can, but they're on their own when it gives them
fugly results.

-Sara

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

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuringassignment

[S.A.N]

Maybe in the future when there will be an inline object {}, you will
need to make the destructuring {}

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

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuringassignment

[Ivan Enderlin]

Hi Andrea,

On 08/04/16 13:26, Andrea Faulds wrote:

Hi Ivan,

Ivan Enderlin wrote:
Thanks a lot for this RFC. Huge +1 from the all Hoa's community and 
myself.

However, did you discuss about `[…]` vs. `{…}`? Most of the time, arrays
or vectors constructing are represented by `[…]` symbols while
destructing are represented by `{…}`. What your point of view or
arguments here?


I'm not sure I understand what you mean. In JS, for example, you use 
{} to create an object or for destructuring assignment for an object. 
But you don't use {} for other cases. [] is used to create arrays and 
for destructuring assignment from arrays. The pattern resembles the 
syntax for constructing what it matches against. In Haskell, (…,…) is 
used for constructing a tuple and pattern-matching against it.


I can't think of a language where {…} is used for destructuring or 
pattern-matching against something which is not written with {…}.


Does that make sense?

Yup.

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

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuringassignment

[Andrea Faulds]

Hi Ivan,

Ivan Enderlin wrote:

Thanks a lot for this RFC. Huge +1 from the all Hoa's community and myself.
However, did you discuss about `[…]` vs. `{…}`? Most of the time, arrays
or vectors constructing are represented by `[…]` symbols while
destructing are represented by `{…}`. What your point of view or
arguments here?


I'm not sure I understand what you mean. In JS, for example, you use {} 
to create an object or for destructuring assignment for an object. But 
you don't use {} for other cases. [] is used to create arrays and for 
destructuring assignment from arrays. The pattern resembles the syntax 
for constructing what it matches against. In Haskell, (…,…) is used for 
constructing a tuple and pattern-matching against it.


I can't think of a language where {…} is used for destructuring or 
pattern-matching against something which is not written with {…}.


Does that make sense?

--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuring assignment

[Ivan Enderlin]

On 08/04/16 12:17, Rowan Collins wrote:

On 08/04/2016 08:43, Ivan Enderlin wrote:
Most of the time, arrays or vectors constructing are represented by 
`[…]` symbols while destructing are represented by `{…}`. What your 
point of view or arguments here? 


When you say "most of the time", do you mean in other languages?

Yes.


Which other languages?
Javascript, Rust, Python… I don't know the exact syntax but I see this 
kind of syntax often. Actually, both exist. I am just curious and wonder 
if you think about using another syntax, and if yes, why choosing this one.



Importantly, do those other languages have similar semantics to PHP? 
I'm reminded me of the suggestion that PHP short array syntax should 
look more like JSON, which to me would be a terrible idea, because PHP 
arrays have very different behaviour from JavaScript objects, on which 
JSON is modelled.

Totally agree.

Regards.

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

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Lester Caine]

On 08/04/16 09:38, Yasuo Ohgaki wrote:
>> If you want to explicitly document something as a best practice, it IS your
>> > problem when users shoot their feet with it
> Lack of proper API for required task is our problem. Misuse is not ours. IMHO.
> 
> The best way to perform GC would be cron task. Low traffic sites can
> make sure obsolete session is deleted. High traffic site can avoid
> occasional slow down by GC. I suppose almost all high traffic sites
> uses memcached or like that does not require PHP's session GC at all,
> though.

Changes to 'defaults' on session handling, and other processes
'improving security' in that area have been a source of problems on many
of my sites, so establishing a proper practice would be nice.

Many of my sites involve people starting a session at the start of an
interview process and the session holds that interview point locked
until finished and for complex interviews this can be a couple of hours.
Some staff will forget to 'log out' and then the next person kicks them
off with a message, or the unfinished sessions get wiped over night. But
ideally the interview times get logged accurately, something that
becomes a problem when something else terminates the session early.

Am I doing anything wrong using sessions in this way and expecting it to
work?

I have also been 'caught out' by time-outs which seem to be too short on
other internet services. They tend to get a complaint when I've spent
time putting data together only to find the session has been terminated
- and all the data entred is lost! Handling this type of problem is
another area where forcing defaults for a mistaken security improvement
needs to be handled while looking at the wider context?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuring assignment

[Rowan Collins]

On 08/04/2016 08:43, Ivan Enderlin wrote:
Most of the time, arrays or vectors constructing are represented by 
`[…]` symbols while destructing are represented by `{…}`. What your 
point of view or arguments here? 


When you say "most of the time", do you mean in other languages? Which 
other languages? Importantly, do those other languages have similar 
semantics to PHP? I'm reminded me of the suggestion that PHP short array 
syntax should look more like JSON, which to me would be a terrible idea, 
because PHP arrays have very different behaviour from JavaScript 
objects, on which JSON is modelled.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Andrey Andreev]

Hi,

On Fri, Apr 8, 2016 at 12:29 PM, Yasuo Ohgaki  wrote:

> Hi Andrey,
>
> On Fri, Apr 8, 2016 at 6:20 PM, Andrey Andreev  wrote:
> > On Fri, Apr 8, 2016 at 11:33 AM, Yasuo Ohgaki 
> wrote:
> >>
> >> Hi Andrey,
> >>
> >> On Fri, Apr 8, 2016 at 4:57 PM, Andrey Andreev 
> wrote:
> >> >>
> >> >> PS(gc_maxlifetime) is needed, so I fixed the last commit.
> >> >>
> >> >
> >> > It is necessary for probability-triggered GC because you don't have
> >> > another
> >> > way of giving a TTL value then, but that's not the case for a direct
> >> > session_gc() call.
> >>
> >> PS(gc_maxlifetime) is not related directly to probability based GC,
> >> but it's about which session should be deleted.
> >>
> >> Save handlers are supposed to delete inactive sessions exceeds
> >> PS(gc_maxlifetime) when GC is issued. Save handlers are not suppose to
> >> use PS(vars) directly and should use passed TTL parameter. Therefore,
> >> the parameter is passed.
> >>
> >
> > It is not directly related to gc_probability it is very obviously the
> result
> > gc_probability-based design.
> >
> > Still, even if we agree to disagree on that, it's not a blocker for
> > maxlifetime being overridable via a parameter.
>
> We need TTL value and the TTL is gc_maxlifetime.
> How would you specify session data to be removed?
>
> TTL value is mandatory.
>


I wrote this pseudo-code in my very first reply to this thread ...

function session_gc($ttl = ini_get('session.gc_maxlifetime')) {}

If that's unclear, here's a more verbose way to put it:

function session_gc($ttl = null)
{
if (empty($ttl))
{
$ttl = ini_get('session.gc_maxlifetime');
}

// ...
}

It just gives the ability to override the INI value for those who don't
want or need it.

Cheers,
Andrey.

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Yasuo Ohgaki]

Hi Andrey,

On Fri, Apr 8, 2016 at 6:24 PM, Andrey Andreev  wrote:
> On Fri, Apr 8, 2016 at 11:38 AM, Yasuo Ohgaki  wrote:
>>
>> Hi Andrey,
>>
>> On Fri, Apr 8, 2016 at 5:02 PM, Andrey Andreev  wrote:
>> > On Fri, Apr 8, 2016 at 6:46 AM, Yasuo Ohgaki  wrote:
>> >>
>> >> ,,,
>> >>
>> >> >
>> >> > Speaking of the documentation part - it's not hard to imagine A LOT
>> >> > of
>> >> > people doing this:
>> >> >
>> >> > session_start();
>> >> > session_gc();
>> >> >
>> >> > That's not a small problem.
>> >>
>> >> Shooting their own foot is not our problem, but leaving obsolete and
>> >> possibly active session is ours.
>> >>
>> >
>> > If you want to explicitly document something as a best practice, it IS
>> > your
>> > problem when users shoot their feet with it
>>
>> Lack of proper API for required task is our problem. Misuse is not ours.
>> IMHO.
>
>
> I understand your POV, but you can't advertise something as a best practice
> and not warn about mistakes that are easy to make - it would be indecent at
> the very least.

We were getting bug reports like
"Calling save handler function directly crashes PHP".

Many of crash bugs by misuse are fixed, but we have to consider such
misuses also.

We also have to consider service providers. They should be able to use
session_gc() properly and mitigate risk of obsolete session being
active again.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Yasuo Ohgaki]

Hi Andrey,

On Fri, Apr 8, 2016 at 6:20 PM, Andrey Andreev  wrote:
> On Fri, Apr 8, 2016 at 11:33 AM, Yasuo Ohgaki  wrote:
>>
>> Hi Andrey,
>>
>> On Fri, Apr 8, 2016 at 4:57 PM, Andrey Andreev  wrote:
>> >>
>> >> PS(gc_maxlifetime) is needed, so I fixed the last commit.
>> >>
>> >
>> > It is necessary for probability-triggered GC because you don't have
>> > another
>> > way of giving a TTL value then, but that's not the case for a direct
>> > session_gc() call.
>>
>> PS(gc_maxlifetime) is not related directly to probability based GC,
>> but it's about which session should be deleted.
>>
>> Save handlers are supposed to delete inactive sessions exceeds
>> PS(gc_maxlifetime) when GC is issued. Save handlers are not suppose to
>> use PS(vars) directly and should use passed TTL parameter. Therefore,
>> the parameter is passed.
>>
>
> It is not directly related to gc_probability it is very obviously the result
> gc_probability-based design.
>
> Still, even if we agree to disagree on that, it's not a blocker for
> maxlifetime being overridable via a parameter.

We need TTL value and the TTL is gc_maxlifetime.
How would you specify session data to be removed?

TTL value is mandatory.

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Andrey Andreev]

Hi,

On Fri, Apr 8, 2016 at 11:38 AM, Yasuo Ohgaki  wrote:

> Hi Andrey,
>
> On Fri, Apr 8, 2016 at 5:02 PM, Andrey Andreev  wrote:
> > On Fri, Apr 8, 2016 at 6:46 AM, Yasuo Ohgaki  wrote:
> >>
> >> ,,,
> >>
> >> >
> >> > Speaking of the documentation part - it's not hard to imagine A LOT of
> >> > people doing this:
> >> >
> >> > session_start();
> >> > session_gc();
> >> >
> >> > That's not a small problem.
> >>
> >> Shooting their own foot is not our problem, but leaving obsolete and
> >> possibly active session is ours.
> >>
> >
> > If you want to explicitly document something as a best practice, it IS
> your
> > problem when users shoot their feet with it
>
> Lack of proper API for required task is our problem. Misuse is not ours.
> IMHO.
>

I understand your POV, but you can't advertise something as a best practice
and not warn about mistakes that are easy to make - it would be indecent at
the very least.

Cheers,
Andrey.

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Andrey Andreev]

Hi,

On Fri, Apr 8, 2016 at 11:33 AM, Yasuo Ohgaki  wrote:

> Hi Andrey,
>
> On Fri, Apr 8, 2016 at 4:57 PM, Andrey Andreev  wrote:
> >>
> >> PS(gc_maxlifetime) is needed, so I fixed the last commit.
> >>
> >
> > It is necessary for probability-triggered GC because you don't have
> another
> > way of giving a TTL value then, but that's not the case for a direct
> > session_gc() call.
>
> PS(gc_maxlifetime) is not related directly to probability based GC,
> but it's about which session should be deleted.
>
> Save handlers are supposed to delete inactive sessions exceeds
> PS(gc_maxlifetime) when GC is issued. Save handlers are not suppose to
> use PS(vars) directly and should use passed TTL parameter. Therefore,
> the parameter is passed.
>
>
It is not directly related to gc_probability it is very obviously the
result gc_probability-based design.

Still, even if we agree to disagree on that, it's not a blocker for
maxlifetime being overridable via a parameter.

Cheers,
Andrey.

Re: [PHP-DEV] Re: Forbid binding methods to incompatible $this

[Yasuo Ohgaki]

Hi Nikita,

On Fri, Apr 8, 2016 at 7:42 AM, Nikita Popov  wrote:
> As the discussion was positive, this is now merged as
> https://github.com/php/php-src/commit/75af8150f58fb55637ac12b33d469b27adef9d76

Could you write UPGRADING for this?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-04-08

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-08 06:34:58+03:00
commit: 60b1441
previous commit:a186ac0
revision date:  2016-04-07 10:26:32+09: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.18% -0.35%  0.70%  
  7.31%
:-|   Drupal 7.36 cgi -T1  0.18%  0.56% -0.11%  
  4.01%
:-|   MediaWiki 1.23.9 cgi -T5000  0.11%  0.09%  1.62%  
  3.04%
:-|   bench.php cgi -T100  0.01%  0.01% 23.76%  
  2.24%
:-|  micro_bench.php cgi -T10  0.01%  0.01%  5.87%  
  3.60%
:-|  mandelbrot.php cgi -T100  0.07%  0.20% 28.91%  
  9.58%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-04-08/

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] [RFC][Discussion] Add session_gc()

[Yasuo Ohgaki]

Hi Andrey,

On Fri, Apr 8, 2016 at 5:02 PM, Andrey Andreev  wrote:
> On Fri, Apr 8, 2016 at 6:46 AM, Yasuo Ohgaki  wrote:
>>
>> ,,,
>>
>> >
>> > Speaking of the documentation part - it's not hard to imagine A LOT of
>> > people doing this:
>> >
>> > session_start();
>> > session_gc();
>> >
>> > That's not a small problem.
>>
>> Shooting their own foot is not our problem, but leaving obsolete and
>> possibly active session is ours.
>>
>
> If you want to explicitly document something as a best practice, it IS your
> problem when users shoot their feet with it

Lack of proper API for required task is our problem. Misuse is not ours. IMHO.

The best way to perform GC would be cron task. Low traffic sites can
make sure obsolete session is deleted. High traffic site can avoid
occasional slow down by GC. I suppose almost all high traffic sites
uses memcached or like that does not require PHP's session GC at all,
though.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Yasuo Ohgaki]

Hi Andrey,

On Fri, Apr 8, 2016 at 4:57 PM, Andrey Andreev  wrote:
>>
>> PS(gc_maxlifetime) is needed, so I fixed the last commit.
>>
>
> It is necessary for probability-triggered GC because you don't have another
> way of giving a TTL value then, but that's not the case for a direct
> session_gc() call.

PS(gc_maxlifetime) is not related directly to probability based GC,
but it's about which session should be deleted.

Save handlers are supposed to delete inactive sessions exceeds
PS(gc_maxlifetime) when GC is issued. Save handlers are not suppose to
use PS(vars) directly and should use passed TTL parameter. Therefore,
the parameter is passed.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Andrey Andreev]

Hi,

On Fri, Apr 8, 2016 at 6:46 AM, Yasuo Ohgaki  wrote:

> ,,,

>
> > Speaking of the documentation part - it's not hard to imagine A LOT of
> > people doing this:
> >
> > session_start();
> > session_gc();
> >
> > That's not a small problem.
>
> Shooting their own foot is not our problem, but leaving obsolete and
> possibly active session is ours.
>
>
If you want to explicitly document something as a best practice, it IS your
problem when users shoot their feet with it.

Cheers,
Andrey.

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Andrey Andreev]

Hi,

On Fri, Apr 8, 2016 at 8:12 AM, Yasuo Ohgaki  wrote:

> Hi Andrey,
>
> On Fri, Apr 8, 2016 at 12:46 PM, Yasuo Ohgaki  wrote:
> >>
> >> The signature for SessionHandlerInterface::gc() accepts a TTL value as a
> >> parameter; session_gc() can too:
> >>
> >> function session_gc($ttl = ini_get('session.gc_maxlifetime')) {}
> >>
> >> * Note: The current patch doesn't actually ignore gc_probability, but I
> >> think that's by mistake (also relevant to my previous point). I'll
> comment
> >> on the PR on GitHub.
> >
> > Good point.
> > Since session module does the job if module should execute GC or not.
> > It should be 1 or very short time.
>

I don't understand what you're saying here. Is it that gc_maxlifetime
should be 1 second? o.O


>
> PS(gc_maxlifetime) is needed, so I fixed the last commit.
>
>
It is necessary for probability-triggered GC because you don't have another
way of giving a TTL value then, but that's not the case for a direct
session_gc() call.

Cheers,
Andrey.

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuring assignment

[Ivan Enderlin]

Hello,

On 07/04/16 14:21, Andrea Faulds wrote:

Hi everyone,

Bob and I have made an RFC which proposes an alternative syntax for 
list():


https://wiki.php.net/rfc/short_list_syntax

Please tell us your thoughts.

Thanks!


Thanks a lot for this RFC. Huge +1 from the all Hoa's community and myself.
However, did you discuss about `[…]` vs. `{…}`? Most of the time, arrays 
or vectors constructing are represented by `[…]` symbols while 
destructing are represented by `{…}`. What your point of view or 
arguments here?


Again, thanks!

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

[PHP-DEV] Re: [RFC] Square bracket syntax for array destructuring assignment

[Cameron Ball]

This gets a vote from me. The symmetry is very nice :]

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