Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

Am 30.04.2017 um 01:26 schrieb Yasuo Ohgaki: On Sun, Apr 30, 2017 at 8:14 AM, Yasuo Ohgaki wrote: I don't need your view of HKDF RFC or usage, but I do need good practical examples that justify your point of view. Please don't waste of your/my time, just give some good examples in next reply.

Re: [PHP-DEV] ZEND_ARG_TYPE_INFO usage in core?

Hey Nikita, Nikita Popov wrote: The solution to these problems is simple: Stop checking arginfo types for internal functions, just use them for reflection / inheritance checks, but leave the actual type-checking to zpp. I agree that this is the way forward. An alternative would be splitting t

Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

On Sun, Apr 30, 2017 at 8:14 AM, Yasuo Ohgaki wrote: > I don't need your view of HKDF RFC or usage, but I do need good practical > examples that justify your point of view. Please don't waste of your/my > time, > just give some good examples in next reply. Thanks. > BTW, valid (yet not common/pr

Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

Hi Andrey, On Tue, Apr 25, 2017 at 7:17 PM, Andrey Andreev wrote: > Hi, > > On Tue, Apr 25, 2017 at 3:28 AM, Yasuo Ohgaki wrote: > >> > >> If you want examples, search GitHub for PHP code utilizing HKDF - you > >> will see that most projects use it without a salt, including > >> https://github.

Re: [PHP-DEV] ZEND_ARG_TYPE_INFO usage in core?

On Sat, Apr 29, 2017 at 3:54 PM, Nikita Popov wrote: > 1. In weak mode, arginfo type violations throw, while zpp violations warn > and return NULL. As such, adding arginfo types to existing functions is a BC > break. > 2. For methods in particular, prior to PHP 7.2, adding arginfo types was > also

Re: [PHP-DEV] ZEND_ARG_TYPE_INFO usage in core?

On Sat, Apr 29, 2017 at 10:24 PM, Sara Golemon wrote: > Spinning off a sub-thread: Does anyone know any particular reason why > ZEND_ARG_TYPE_INFO is not (barring two windows specific functions in > standard) used anywhere in core? > > Is it? > 1. Nobody has done the grunt work since 7.0? > 2. I

[PHP-DEV] ZEND_ARG_TYPE_INFO usage in core?

Spinning off a sub-thread: Does anyone know any particular reason why ZEND_ARG_TYPE_INFO is not (barring two windows specific functions in standard) used anywhere in core? Is it? 1. Nobody has done the grunt work since 7.0? 2. It breaks something? (should only impact reflection AIUI) 3. ??? I'd

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Sat, Apr 29, 2017 at 2:46 PM, Rowan Collins wrote: > In this case, we should acknowledge that userland cannot > (delta dirty backtrace hack) change behaviour based on > strict types inside the body of the function, and in most > cases neither sold internal functions. We can then decide > if thi

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On 29 April 2017 17:25:45 BST, Sara Golemon wrote: >Your example of GMP can't be simply dismissed as "a special edge >case", it's precisely true that internals does not always follow the >same rules as userspace and often it breaks those rules for very good >reason. I think the adage applies here

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On 4/29/2017 6:25 PM, Sara Golemon wrote: > Your example of GMP can't be simply dismissed as "a special edge > case", it's precisely true that internals does not always follow the > same rules as userspace and often it breaks those rules for very good > reason. > I only said that I do not conside

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On 29.04.2017 at 18:11, Fleshgrinder wrote: > The fact that internals are not reflective is sad, we > most probably should do something about that. As of PHP 7.0.0 there is ZEND_ARG_TYPE_INFO[1] which is not yet used, though, presumably due to BC concerns. [1]

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Sat, Apr 29, 2017 at 11:11 AM, Fleshgrinder wrote: > Let me be Bob, and my assumption would be completely different. I expect > that internals behave the same as userland implementations. I know that > this is not the case in every circumstance, but those where this > assumption does not hold t

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On 4/29/2017 5:53 PM, Sara Golemon wrote: > Not on *both* strict mode and the value of another parameter, there's > very little application of strict mode throughout the codebase because > strict mode is new. What there are precedents of, and what I was > responding to in your earlier email, was t

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On Sat, Apr 29, 2017 at 10:01 AM, Rowan Collins wrote: > That mix sounds very reasonable. Does it still make you go "eww" to suggest > that those settings that don't deserve their own method, and take a boolean > argument rather than a string or int, could have a different method, such as > setFla

Re: [PHP-DEV] [RFC] Enable strict_types checking for curl_setopt()

On 29 April 2017 00:30:06 BST, Sara Golemon wrote: >On Fri, Apr 28, 2017 at 6:05 PM, Rowan Collins > wrote: >>>I reject the idea of making a worse API for the sake of an artificial >>>purity standard which has long since been violated elsewhere. >> >> Personally, I think if we were designing from