[PHP-DEV] Re: [RFC][VOTE] Add session_create_id() function

Hi Tom, On Sun, Aug 14, 2016 at 12:35 AM, Tom Worster wrote: > Rather than argue the details of randomness, I have more basic comments. > > 1. If an app needs to access session values, it can and should do this > without indirection through the PHP session ID table. I don't get

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

Hi Tom, On Sun, Aug 14, 2016 at 12:22 AM, Tom Worster wrote: > On 8/12/16, 4:38 PM, "Yasuo Ohgaki" wrote: > >>Base 64 adds padding for extra bytes. The Padding char is "=" and it's >>illegal char as SID. Therefore trims is mandatory. > >

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

> On 14/08/2016, at 2:47 AM, w...@wkhudgins.info wrote: > > On 2016-08-13 04:34, Simon Welsh wrote: >>> On 2/08/2016, at 8:52 AM, w...@wkhudgins.info wrote: >>> Hello, >>> I recently emailed the group about submitting an RFC for str_begins() and >>> str_ends() functions. The RFC has now been

Re: [PHP-DEV] Namespaces internal refactoring

Hi Stas, I'll answer your message as it directly refers to links with my name. I understand the reasons of why namespaces were implemented that way, as I follow this list for quite a long time. I never complained about the implementation itself as it was publicly introduced originally back in

Re: [PHP-DEV] Namespaces internal refactoring

Hi! > The current approach to namespaces blocks new features like you see it > in the following PR. The link already points to the two most relevant > comments that should give you full context: > > https://github.com/php/php-src/pull/947/#issuecomment-224912697 I don't think this - private

Re: [PHP-DEV] Simple variable handling.

On 13/08/16 18:28, Marco Pivetta wrote: > A "NI" or "Email address" concept is only a string at low level. Yes ... but where do you store the flag such as "NI" ... > It is well known/accepted that such concepts should be turned into > simple objects instead, so that you can actually use

Re: [PHP-DEV] Simple variable handling.

A "NI" or "Email address" concept is only a string at low level. It is well known/accepted that such concepts should be turned into simple objects instead, so that you can actually use type-signatures to type-hint against NI/Email. This avoids having to re-validat e for data-integrity and

Re: [PHP-DEV] Simple variable handling.

On 13/08/16 14:43, Marco Pivetta wrote: > It receives a value (nested, if necessary) and tells us if it is valid or > not, plus why (as a set of strings, usually). > > This is validation. Please do use separate terminology if you mean: > * "frontend (client-side) validation" > * "frontend

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

On 2016-08-13 04:34, Simon Welsh wrote: On 2/08/2016, at 8:52 AM, w...@wkhudgins.info wrote: Hello, I recently emailed the group about submitting an RFC for str_begins() and str_ends() functions. The RFC has now been officially submitted and is viewable at:

[PHP-DEV] Re: mt_srand with array seed?

On 8/12/16 2:48 PM, Lauri Kenttä wrote: On 2016-08-12 21:40, Tom Worster wrote: mt_srand() will work. But what would be in the array? Integers from which the upper 32 bits, if they exist, are discarded? mt19937ar.c contains init_by_array. Compability with that would probably be a good goal,

[PHP-DEV] Re: [RFC][VOTE] Add session_create_id() function

On 8/10/16 5:14 AM, Yasuo Ohgaki wrote: Hi all, This is RFC for adding session_create_id() function. Session ID string uses special binary to string conversion. Users should write lengthy and slow code to have the same session ID string as session module does. It also validates and makes sure

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

Hi Yasu, On 8/12/16, 4:38 PM, "Yasuo Ohgaki" wrote: >Base 64 adds padding for extra bytes. The Padding char is "=" and it's >illegal char as SID. Therefore trims is mandatory. substr(base64_encode(random_bytes($n)), 0, $n). There is no "=" in the value for any $n. >Don't

Re: [PHP-DEV] Simple variable handling.

So much confusion... There are 3 (or more) types of validation in pretty much every web-app, so let's please stop calling it simply "validation". 1. frontend validation (unsafe/unreliable), prevents invalid data submission, makes things friendlier for the user 2. form validation, in the

[PHP-DEV] Re: Bug #72828

On 13.08.2016 at 15:08, Nikita Popov wrote: > On Sat, Aug 13, 2016 at 2:42 PM, Christoph M. Becker > wrote: > >> You have commented on : >> >> | Unless the allocations explicitly use the system allocator (i.e. do >> | not use emalloc and

[PHP-DEV] Re: Bug #72828

On Sat, Aug 13, 2016 at 2:42 PM, Christoph M. Becker wrote: > Hi Nikita! > > You have commented on : > > | Unless the allocations explicitly use the system allocator (i.e. do > | not use emalloc and variants), do NOT introduce NULL

[PHP-DEV] Bug #72828

Hi Nikita! You have commented on : | Unless the allocations explicitly use the system allocator (i.e. do | not use emalloc and variants), do NOT introduce NULL checks. Can you please elaborate, why that shouldn't be done. Actually, the allocations use

Re: [PHP-DEV] Simple variable handling.

On 13/08/16 10:14, Tony Marston wrote: > I do not see that complicating the language by making it do what SHOULD > be done in userland code is a good idea. Helping 1% of users while > hindering the remaining 99% is not an idea which should EVER be > contemplated. I'm currently looking to

Re: [PHP-DEV] Simple variable handling.

"Peter Lind" wrote in message news:caeu6nadvbkmqhju0assr5f+ubo9vvryjyvjmr0ihxb8bdmg...@mail.gmail.com... On 12 August 2016 at 12:13, Lester Caine wrote: On 12/08/16 10:42, Peter Lind wrote: > On 12 August 2016 at 11:25, Lester Caine wrote: > > Thanks

Re: [PHP-DEV] Simple variable handling.

"Niklas Keller" wrote in message news:canuqdcjaxejscajye+q-uhxcfjexwrywlkzmfwrqvdaewvb...@mail.gmail.com... 2016-08-11 14:42 GMT+02:00 Lester Caine : On 11/08/16 04:56, Michal Brzuchalski wrote: > You want to stick such validation at runtime at any time with variable and

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

> On 2/08/2016, at 8:52 AM, w...@wkhudgins.info wrote: > > Hello, > > I recently emailed the group about submitting an RFC for str_begins() and > str_ends() functions. The RFC has now been officially submitted and is > viewable at: > > https://wiki.php.net/rfc/add_str_begin_and_end_functions

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

On 04/08/16 06:50, Stanislav Malyshev wrote: >> I guess that "i" isn't appliable when it have slashes. >> > In this case, functions should be: strbegins, stribegins, strends, >> > striends. >> > In all case, I think that is better a third parameter and keep underlined. > Please, not stribegins.