Re: [PHP-DEV] [VOTE] get_class() disallow null parameter

On Sep 26, 2016 12:09 AM, "Niklas Keller" <m...@kelunik.com> wrote: > > 2016-09-25 15:19 GMT+02:00 Christoph M. Becker <cmbecke...@gmx.de>: >> >> On 25.09.2016 at 11:29, Leigh wrote: >> >> > On Sun, 25 Sep 2016 at 06:29 Pierre Joye <

Re: [PHP-DEV] [VOTE] get_class() disallow null parameter

On Sep 25, 2016 4:29 PM, "Leigh" <lei...@gmail.com> wrote: > > > > On Sun, 25 Sep 2016 at 06:29 Pierre Joye <pierre@gmail.com> wrote: >> >> Also this behavior is clearly documented: >> >> http://th1.php.net/manual/en/function.get

Re: [PHP-DEV] [VOTE] get_class() disallow null parameter

hp "If object is omitted when inside a class, the name of that class is returned." I am opposed to break BC because we change our mind about how clean is this behavior and I recommend the (future) RMs to veto this change. Cheers Pierre

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

Adding the RMs. Dacey, I think this needs a deeper look and decision. On Sep 22, 2016 7:51 AM, "Pierre Joye" <pierre@gmail.com> wrote: > > On Sep 22, 2016 1:07 AM, "Levi Morrison" <le...@php.net> wrote: > > > > On Wed, Sep 21, 2016 at 11:1

Re: [PHP-DEV] Fix ReflectionType::__toString() BC break

On Sep 22, 2016 1:07 AM, "Levi Morrison" wrote: > > On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas > wrote: > >> To handle this in code written around current __toString seems pretty > > simple > > > > Yes it is, but that's not what we're talking about:

Re: [PHP-DEV] Follow up to "The death of `#ifndef FAST_ZPP`?"

On Sep 15, 2016 7:10 AM, "Andrea Faulds" <a...@ajf.me> wrote: > > Hi Pierre, > > > Pierre Joye wrote: >> >> >> Thanks you :) >> >> Please add this note to UPGRADING.INTERNALS as well : > > > Well, I was wondering about that,

Re: [PHP-DEV] Modern practices ...

r other toolchains may be added; patches are welcome! :-) >>> >>> Again something I have tried to maintain in the past, but the volume of >>> work on the TODO list is delaying bringing many of the old crib sheets >>> up to date. >> >> I guess, we all

Re: [PHP-DEV] [RFC][DISCUSSION] Improve uniqid() uniqueness

Hi, On Sep 12, 2016 5:48 PM, "Kazuo Oishi" wrote: > > Hi, > > > I know some code breaks, but it's not many. It's not fatal BC also. > > > > IMHO, uniqid() should try to generate uniqid() possible. uniqid() does produce > > non unique ID because it is system time based. This

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 12, 2016 6:51 PM, "Nikita Popov" <nikita@gmail.com> wrote: > > On Mon, Sep 12, 2016 at 1:42 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: >> >> On Mon, Sep 12, 2016 at 10:21 AM, Derick Rethans <der...@php.net> wrote: >> >> >

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 12, 2016 3:24 PM, "Stanislav Malyshev" wrote: > > Hi! > > >> PEAR/PECL as a package manager has historically had little utility to the > >> average user apart from installing those PECL extensions which aren't > >> packaged by a particular user's distribution

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 12, 2016 2:36 PM, "Tony Marston" wrote: > > Sent: Sunday, September 11, 2016 8:32 PM > >To: Tony Marston ; Stanislav Malyshev ; internals@lists.php.net > >Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle > > > > > >On 09/11/2016 10:47

Re: [PHP-DEV] Follow up to "The death of `#ifndef FAST_ZPP`?"

n that needs parameter parsing and which targets only PHP 7.0+, you now don't need to (and shouldn't) include zpp fallback code if you're using Fast ZPP. > > Thanks! Thanks you :) Please add this note to UPGRADING.INTERNALS as well : Cheers Pierre

Re: [PHP-DEV] Modern practices ...

On Sep 10, 2016 3:32 PM, "Lester Caine" <les...@lsces.co.uk> wrote: > I think I am right in saying Pierre originally needed pickle so that > PEAR could be dropped in the windows? It was not the reason. My main motivation is about ease developer work (no information dupl

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 10, 2016 4:19 PM, "Tony Marston" wrote: > That is a valid opinion. Consider the fact that the Windows operating system was only accepted by large numbers of users as it had a "modern" GUI and not a command line interface. You try and release a new piece of

Re: [PHP-DEV] [RFC] Make uniqid() more unique

ems uniqid() is popular for test scripts, so > > it would be preferred keeping it. > > > Nobody said it should be removed now. Maybe in the future. But you might as > well just use bin2hex(random_bytes(16)). Or uuid. This why this standard exists. I would recommend to move to that instead of trying to reinvent the wheel. https://github.com/ramsey/uuid is pretty good. Cheers Pierre

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 8, 2016 3:05 PM, "Tony Marston" <tonymars...@hotmail.com> wrote: > > "Pierre Joye" wrote in message news:caezptu4twuap1xjx+z_n+sgj1ujptyn8pj5xuvmjei2dke0...@mail.gmail.com... > >> >> hi Tony, >> >> On Wed, Sep 7, 20

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 7, 2016 6:24 PM, "Lester Caine" <les...@lsces.co.uk> wrote: > > On 07/09/16 12:02, Pierre Joye wrote: > > One point, pickle does not need composer to run. > > > > pickle install memcache will install the memcache extension (windows > > b

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

or even cvs if some of us still have that internally. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

hi Tony, On Wed, Sep 7, 2016 at 2:52 PM, Tony Marston <tonymars...@hotmail.com> wrote: > "Pierre Joye" wrote in message > news:CAEZPtU6aHYb9HsNXbXWp9q9PMoLYiJp=n1rjmspofmhbebd...@mail.gmail.com... > >> Happy to see there are still users for this tool, Christia

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

On Sep 6, 2016 6:29 PM, "Ferenc Kovacs" wrote: > > On Tue, Sep 6, 2016 at 12:40 PM, Rowan Collins > wrote: > > > On 06/09/2016 11:18, Derick Rethans wrote: > > > >> One of PHPs biggest strengths is the availability of an extension for > >> nearly

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

ntrol. There's even a lock file so everyone installing an >> app can install the same version of every depenendy. That way it's way >> easier to reproduce bugs locally. >> >> It has to be 100% stable, and I'm not sure that composer/pickle fit the >>> >>>

Re: [PHP-DEV] Missing reflection info about strict types?

Hi, On Sep 5, 2016 8:53 PM, "Julien Pauli" wrote: > > On Mon, Sep 5, 2016 at 3:19 PM, Julien Pauli wrote: > > On Mon, Sep 5, 2016 at 2:44 PM, Nicolas Grekas wrote: > >> Thanks for trying Julien > >> > >>> I guess what you miss for what

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Hi Tyrael On Sep 5, 2016 7:10 AM, "Ferenc Kovacs" wrote: > > You are probably talking about https://bugs.php.net/bug.php?id=71224. > > My understanding is that when fetching the packages from pecl.php.net > pickle would still have the same problem ( >

Re: [PHP-DEV] Re: [RFC][VOTE] E_WARNING on invalid container read-adccess

in good enough way. There is no need to cancel the vote. However it is the role of the RMs to veto the patch of its quality is not at the level we want. If an acceptable patch can be done before RC then it can be applied. Thoughts? Cheers Pierre

Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter1 to be object, string given

ble. I still prefer Julien's proposal, let see when we have the patch :) Cheers Pierre

Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter 1 to be object, string given

Your example uses a > static method - you should be passing null and not the name of the class > (this is also in the documentation). > > [1]: http://php.net/manual/en/reflectionmethod.invoke.php I have to disagree here. Many codes out there uses string. What is the appealing reason to break these codes in 7.1? I think it should restore the precious behavior and if the docs need a fix, let fix it, not the other way. Cheers Pierre

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On Aug 17, 2016 12:20 PM, "Yasuo Ohgaki" wrote: > > Hi Dan, > > I understood about RFC process. > > On Wed, Aug 17, 2016 at 12:23 PM, Dan Ackroyd wrote: > > Additionally, you seem to completely have ignored this: > > > > Dan Ackroyd wrote: > >> And I

Re: [PHP-DEV] Write down a deprecation policy

it the right place to > discuss it? The release process RFC does not allow BC breaks but in edge cases where it is absolutely required. The utf8 proposal does not fit in this definition. It can be clarified, always good to be more clear. Cheers Pierre

Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

On Aug 15, 2016 10:18 AM, "Yasuo Ohgaki" wrote: > > Hi all, > > utf8_decode() and utf8_encode() are not needed and causing problems > than solving. > > https://wiki.php.net/rfc/remove_utf_8_decode_encode > > Proposal > - Document deprecation them now > - Remove them from

Re: [PHP-DEV] [RFC] orphan extensions cleanup

On Aug 18, 2016 8:03 PM, "Christoph M. Becker" wrote: > > On 18.08.2016 at 01:32, Kalle Sommer Nielsen wrote: > > > 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev : > >> Please comment and discuss! > > > > What about adding the following: > > ext/dba > > > >

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On Aug 15, 2016 10:36 AM, "Yasuo Ohgaki" wrote: > I don't mind suspend vote for a while to resolve issues if there > should be changes in the RFC. I also don't mind adding missing > features, e.g. helpful error messages when exception is disabled, to > my todo list. BTW,

Re: [PHP-DEV] [RFC] orphan extensions cleanup

Hi Stas, On Aug 15, 2016 11:50 PM, "Stanislav Malyshev" <smalys...@gmail.com> wrote: > > Hi! > > >> enchant: > >> I thought Pierre maintained enchant? Despite it haven't had much real > >> activity for years > > > > Well there a

Re: [PHP-DEV] [RFC] orphan extensions cleanup

> > no maintainer: > > > > https://wiki.php.net/rfc/umaintained_extensions > > enchant: > I thought Pierre maintained enchant? Despite it haven't had much real > activity for years Well there are not much changes in the api. And it works. So -1 here. > gettext >

Re: [PHP-DEV] Adding validate_var_array()/validate_input_array() to which version?

On Aug 5, 2016 2:30 AM, "Yasuo Ohgaki" wrote: > > Hi Christian, > > On Thu, Aug 4, 2016 at 8:27 PM, Christian Stadler wrote: > > Am 04.08.2016 um 12:10 schrieb Yasuo Ohgaki: > >> Hi Christian and all, > >> > >> On Thu, Aug 4, 2016 at 10:07 AM, Christian Stadler

Re: [PHP-DEV] [RFC][DISCUSSION] Add validation functions to filter

so using different approaches and OO based, which simplifies a lot their usage. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

the content of a rfc but the time available for contributors to act. And all contributors do not follow the RFCs daily. Cheers Pierre

Re: [PHP-DEV] orphaned extensions in 7.1?

On Mon, Jul 18, 2016 at 3:41 PM, Niklas Keller <m...@kelunik.com> wrote: > 2016-07-18 9:54 GMT+02:00 Pierre Joye <pierre@gmail.com>: >> >> hi, >> >> On Mon, Jul 18, 2016 at 7:12 AM, Davey Shafik <da...@php.net> wrote: >> > The only negat

Re: [PHP-DEV] orphaned extensions in 7.1?

tion (with less impacted users maybe). Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Bumping minimal OpenSSL version to 1.0.1 in master for PHP 7.1

tive due to many outdated components. They do provide latest versions as far as I remember. All in all I think we should drop these features and also require 1.x. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Request for wiki karma

y. I add Scott to this thread to be sure he reads. As far as I remember he has a patch too but there was concerns about having argon2 support at this stage because of the current state of argon2 specs (or something along this line). Let be sure that these concerns are solved before considering to include it as it means some bc risks later if the specs change. Cheers Pierre

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

On Jul 9, 2016 4:05 PM, "Leigh" <lei...@gmail.com> wrote: > > On Sat, 9 Jul 2016 at 09:49 Pierre Joye <pierre@gmail.com> wrote: >> >> >> I am sorry but this PR possibly breaks BC and cases have been clearly explained how and why. Asking to sho

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

On Jul 9, 2016 3:49 PM, "Pierre Joye" <pierre@gmail.com> wrote: > > > On Jul 9, 2016 3:19 PM, "Leigh" <lei...@gmail.com> wrote: > > > > > > On Sat, 9 Jul 2016 at 08:48 Pierre Joye <pierre@gmail.com> wrote: > >

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

On Jul 9, 2016 3:19 PM, "Leigh" <lei...@gmail.com> wrote: > > > On Sat, 9 Jul 2016 at 08:48 Pierre Joye <pierre@gmail.com> wrote: >> >> So, I voted no then as it is clear that you do not see a problem to >> break codes without a single warning

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

On Thu, Jul 7, 2016 at 7:56 PM, Pierre Joye <pierre@gmail.com> wrote: > > On Jul 7, 2016 7:53 PM, "Leigh" <lei...@gmail.com> wrote: >> >> On 7 July 2016 at 13:39, Pierre Joye <pierre@gmail.com> wrote: >> > Hi >> >

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

On Jul 7, 2016 7:53 PM, "Leigh" <lei...@gmail.com> wrote: > > On 7 July 2016 at 13:39, Pierre Joye <pierre@gmail.com> wrote: > > Hi > > > > Looks good but missing an option to choose the default mode. > > > > I would choose BC as defau

Re: [PHP-DEV] [RFC][VOTE] RNG fixes

Hi Looks good but missing an option to choose the default mode. I would choose BC as default at least for one release (7.1). I tend to vote against fixing mt_rand because of that. On Jul 7, 2016 5:39 PM, "Leigh" wrote: > As the discussion thread has been quiet for a while,

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

On Jul 5, 2016 6:14 AM, "Yasuo Ohgaki" wrote: > > Hi Stas, > > Thank you for sharing opinion. > Followings is mine. > > On Tue, Jul 5, 2016 at 7:23 AM, Stanislav Malyshev wrote: > >> Could you share the reason why against this change? > > > > 1. I'm not

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

On Jun 30, 2016 3:41 AM, "Dan Ackroyd" <dan...@basereality.com> wrote: > > On 28 June 2016 at 03:36, Pierre Joye <pierre@gmail.com> wrote: > > > > I like the idea. > > > > It should be 2/3 tho'. > > Why? > > It's not a language

Re: [PHP-DEV] [RFC] RNG fixes

looking for > legitimate uses of mt_srand() - this is the functionality that will be > broken. > > On 16 June 2016 at 03:21, Pierre Joye <pierre@gmail.com> wrote: > > There are ways to achieve what you want in a nice way while not breaking > > things. Let consider them.

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

erstand the goal to secure (and this is a very open definition) session manage for php but this cannot be done in step by step basis. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

hi, On Fri, Jun 24, 2016 at 5:20 PM, Dmitry Stogov <dmi...@zend.com> wrote: > Hi internals, > > > Please review the RFC https://wiki.php.net/rfc/async_signals Travis is not happy in ZTS, can you check please? https://travis-ci.org/php/php-src/jobs/139981256 -- Pierre

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

or may behave (more) badly with this than with a fatal error. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

On Mon, Jun 27, 2016 at 5:08 PM, Joe Watkins wrote: > Morning, > > How is the impact wider than ext/pcntl ? The implementation is only in pctnl. The feature is used indirectly by the engine and makes it a core feature. Quote from the RFC: "Zend Engine in PHP 7.1 was

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

On Jun 27, 2016 1:20 PM, "Joe Watkins" wrote: > The proposed version of this RFC is 7.1, and the discussion was started > very late. However, since this is a self contained change in an extension, > I'm not sure it needs a 2/3 majority, and I'm not sure that it needs a

Re: [PHP-DEV] 5.5 EOL

t would be nice. I think we could do it with the release before the last release but we missed it. So yes, publishing an announcement this week would be best. Alternatively we do two more releases but I am not too keen to extend 5.5 support :) Cheers, Pierre -- Pierre @pierrejoye | http://www.libgd.

Re: [PHP-DEV] [RFC] RNG fixes

On Fri, Jun 24, 2016 at 8:35 AM, Pierre Joye <pierre@gmail.com> wrote: > hi, > > On Thu, Jun 23, 2016 at 11:56 PM, Stanislav Malyshev > <smalys...@gmail.com> wrote: >> Hi! >> >>> I would prefer something like random_fast_int() == mt_rand() == rand()

Re: [PHP-DEV] [RFC] RNG fixes

ors but do not have to punish good cases by removing useful features for the "good of all". Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] RNG fixes

On Jun 19, 2016 10:50 PM, "Fleshgrinder" wrote: > > On 6/17/2016 7:18 PM, Christoph Becker wrote: > > Consequently, we should remove rot13() as well, see > > . And we shouldn't stop there as > > include(_once), require(_once),

[PHP-DEV] Re: Improve GD test suite

a drawn image is correct. However, as Pierre > mentioned long ago[1], md5() does not work (reliably) for this purpose. > > An alternative would be to have prepared images, and to compare these > with the actual resulting images pixel by pixel. While that might work > fine for lossless

Re: [PHP-DEV] [RFC] [Accepted] Replace "Missing argument" warning with "Too few arguments" exception

On Fri, Jun 17, 2016 at 4:57 PM, Matteo Beccati <p...@beccati.com> wrote: > On 16/06/2016 08:18, Pierre Joye wrote: >> Hi Dmitry >> >> I am sorry but I have to ask to wait before merging it. >> >> It is definitely not clear that: >> >> . The rfc

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

On Jun 17, 2016 1:10 PM, "Dmitry Stogov" wrote: > > Got it :( > Then this may be a serious BC break, and it's better to depricate it in 7.1 and throw exception only in 8. Fully agree. Thanks :) > Thanks. Dmitry. > > > > On Thu, Jun 16, 2016 at 8:14 PM +0300, "Stanislav

Re: [PHP-DEV] [RFC] RNG fixes

On Jun 17, 2016 1:55 AM, "Fleshgrinder" <p...@fleshgrinder.com> wrote: > > On 6/16/2016 8:14 PM, Pierre Joye wrote: > > Well know you do as I gave you examples of such usages. Their Code not > > public so I cannot give you links. > > > > That's a knock

Re: [PHP-DEV] [RFC] RNG fixes

On Jun 17, 2016 12:43 AM, "Fleshgrinder" <p...@fleshgrinder.com> wrote: > > On 6/16/2016 4:21 AM, Pierre Joye wrote: > > No they don't all do it. > > > > We don't know but I will try to find legitimate usages of (mt_)rand. Well know you do as I gave

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

On Jun 11, 2016 4:27 AM, "Dmitry Stogov" wrote: > > In general, you are right, but this is possible only if application ignores Error exceptions... Exactly. Many if not hundred of applications do not even use exception but if a couple of places, let alone plug-ins for these

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

On Jun 16, 2016 11:41 AM, "Joe Watkins" wrote: > > Morning, > >> This would keep the "BC promise" intact instead of going back to > cowboy php days. > >> Please don't let's make it harder to go from 7.0 to 7.1 than it was > from 5.6 to 7.0. > >Can we reduce

Re: [PHP-DEV] [RFC] [Accepted] Replace "Missing argument" warning with "Too few arguments" exception

and having a more clear way to define what is acceptable as BC. I think the RMs should step in here. Thanks, Pierre On Jun 16, 2016 1:12 PM, "Dmitry Stogov" <dmi...@zend.com> wrote: > Hi internals, > > > The RFC https://wiki.php.net/rfc/too_few_args<https://wiki.php.

Re: [PHP-DEV] PHP allocating too much memory

Hi On Jun 16, 2016 7:22 AM, "Peter LeBrun" wrote: > > Hey everyone, thanks for your help and input. We've narrowed it down to > cases where there is string concatenation with a constant, but currently > upgrading to 7.0.7 to see if that makes a difference. Is it possible

Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning with "Too few arguments" exception

rt discussion period. The rule is a minimum discussion time, not a "let choose randomly depending on what or who". This is worrisome. My take on it is that the RMs should veto it (it is part of their roles). Thanks Pierre

Re: [PHP-DEV] [RFC] RNG fixes

r software (e.g. game) wants to have more control > over distribution and ways to tweak it. Hence, they will directly > implement it straight on their own anyways. No they don't all do it. There are ways to achieve what you want in a nice way while not breaking things. Let consider them. Cheers, Pierre

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

itry and the team are very careful. I also have to say that to the very short timeline to finalize 7.0 should not be paid by breaking BCs in 7.x. We can have a short timeline for 8.0 as well. If we need more drastic BC breaks earlier than expected. If JIT is a goal for 8.0, then let do the BC breaks

Re: [PHP-DEV] [RFC] RNG fixes

o use reliable alternatives. However this is a documentation/education issue. There is no need to make mt_rand/rand crypto safe but there is a use for a reliable implemantion of mt_rand. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Libsodium - Discussion

On Sun, Jun 5, 2016 at 2:46 PM, Scott Arciszewski <sc...@paragonie.com> wrote: > > On Sun, Jun 5, 2016 at 2:20 AM, Pierre Joye <pierre@gmail.com> wrote: >> >> >> On Jun 5, 2016 5:15 AM, "Stanislav Malyshev" <smalys...@gmail.com> wrote: >&g

Re: [PHP-DEV] [RFC] Libsodium - Discussion

ature of the APIs make it not as friendly or future proof as it could. Cheers Pierre

Re: [PHP-DEV] [RFC] Libsodium - Discussion

e interfaces for non C developers. - compare should be string_compare, or it could be confusing about what it can compare, especially in code review while checking crypt code, where many other types come into the game Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Ru

Re: [PHP-DEV] [RFC][Vote] Typed Properties

On May 23, 2016 4:09 PM, "Stanislav Malyshev" wrote: > > Hi! > > > The performance effect of this implementation is terrible. > > > > Assignment to typed property is 2.3 times slower. > > Assignment to untyped property in a class with typed properties is 1.8 times slower. > >

Re: [PHP-DEV] [RFC] Pipe Operator

the rfc my immediate feeling was negative. Yet another syntaxic sugar that will be used so rarely that I will have to try and rtfm when I see it. The cases presented in this thread and in other discussions changed my mind. I will vote for it. Thanks Pierre

Re: [PHP-DEV] Assess acceptability of having php-ds into core

ng to help to improve the situation, in contrary. I would prefer to discuss each structure individually to see if we need it, where it should be and how it should be done from an api pov. Cheers Pierre

Re: [PHP-DEV] [RFC] Allow loading extensions by name

ou to perform all tasks. Although I have to > admit that PHP tends to be very slow on Windows compared to Linux, that > is a fact. Off topic but you are wrong here. As a matter of fact. Check real life benchmarks and raw benchmarks. -- Pierre @pierrejoye | http://www.libgd.org

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

APIs, focusing purely on its core purposes, managing session data storage and provides interfaces to match application needs. We do not do that very well anymore. I will leave this thread for now as I will going to repeat myself more than you wish, I think we made our points clear :) Cheers, -- Pier

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

On May 11, 2016 1:54 PM, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote: > > Hi Pierre, > > On Wed, May 11, 2016 at 2:19 PM, Pierre Joye <pierre@gmail.com> wrote: > > On May 11, 2016 11:46 AM, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote: > &g

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

as well. Both csrf ans auth may need sessions but they are not part of the session features. Cheers, Pierre

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

Hi, On May 10, 2016 10:25 AM, "Yasuo Ohgaki" wrote: > > Hi all, > > It's not nice to work on the same code (i.e. session module) for > multiple RFCs, but time is limited. > > I would like to hear from ideas/comments before I write patch for this. >

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

On Sat, Apr 30, 2016 at 3:52 PM, Lester Caine <les...@lsces.co.uk> wrote: > On 30/04/16 09:38, Pierre Joye wrote: >>> Sorry if you didn't spend the last 6+ years of your free time >>> > < >> https://github.com/phpDocumentor/phpDocumentor2/commit/6

Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...

On Apr 29, 2016 3:42 PM, "Marco Pivetta" wrote: > > Hey Lester, > > Sorry if you didn't spend the last 6+ years of your free time > < https://github.com/phpDocumentor/phpDocumentor2/commit/66dc9069085dcea957508f84e9c79eaf4c234586 > > (yes, that is an import) maintaining an

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

Hi Larry, On Apr 30, 2016 6:48 AM, "Larry Garfield" wrote: > > Most of the examples that have been given so far are either trivial boolean flags or data validation rules to be evaled. In practice, very little of Drupal's use of annotations in Drupal 8 fit either

Re: [PHP-DEV] [RFC] PHP Attributes

f they would like to change one thing or another. That could (or must) part of the PHP specifications. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.1 roadmap

review patches and raises possible issues. I would not worry too much about that. Lukas for example did a great job and was not a C developer to begin with. The key role however of the RM is to ensure that the release process goes smoothly, the planing is respected and BC is kept during the full life of a given release. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.1 roadmap

On Apr 22, 2016 8:42 PM, "Ferenc Kovacs" wrote: > > co-RM can simply mean "one of the two RMs", and emphasize that somebody > would volunteer to take the role but not being comfortable to doing it > alone so I think we are on the same page. Exactly. And I am convinced Davey and

Re: [PHP-DEV] UUID

to clarify this point before anything can be merged. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UUID

on" which > defaults to 4? I would prefer not to refer to random to avoid any confusion with the recent added random function. As uuid is not crypto safe and is not aimed to. Users will then hopefully not think about using instead of the random api. Also uuid alone may be a problem (bc?) It sounds like a logical choice. Alternatively uuid_create (). Cheers Pierre

Re: [PHP-DEV] UUID

On Tue, Apr 12, 2016 at 2:52 PM, Pierre Joye <pierre@gmail.com> wrote: > On Apr 12, 2016 1:09 PM, "Sebastian Bergmann" <sebast...@php.net> wrote: >> >> In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2) >> as well as Windo

Re: [PHP-DEV] UUID

ovides compliant APIs as part of their libc (https://www.freebsd.org/cgi/man.cgi?query=uuid for freebsd f.e.). On Windows UuidCreate and UuidToString should do it but I did not check their compliance yet. For the reference here: by compliant, I mean compliant with https://tools.ietf.org/html/rfc412

Re: [PHP-DEV] RETURN micro optimization

w exactly how this change will affect them to make sure that users can migrate to 7.1 smoothly and still use their tools. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fixed bug #71906: AddressSanitizer: negative-size-param (-1) in mbfl_strcut: ext/mbstring/libmbfl/mbfl/mbfilter.c

On Mar 30, 2016 3:12 PM, "Yasuo Ohgaki" wrote: > > Hi all, > > On Mon, Mar 28, 2016 at 5:22 PM, Stanislav Malyshev wrote: > > Commit:64f42c73efc58e88671ad76b6b6bc8e2b62713e1 > > Author:Stanislav Malyshev Mon, 28 Mar 2016 01:22:37

Re: [PHP-DEV] [RFC Discussion] Typed Properties

On Mar 30, 2016 10:17 AM, "Joe Watkins" wrote: > > Morning Dmitry, > > > 1) static typed properties are prohibited. why? > > Feels like that's a separate feature, static properties are as good as > makes no difference, global variables. > > Instance properties, the engine

Re: [PHP-DEV] crypt_blowfish salt padding

Hi Alexander, On Sun, Mar 27, 2016 at 10:16 PM, Solar Designer <so...@openwall.com> wrote: > Hi, > > This commit: > > commit 03315d9625dc87515f1dfbf1cc7d53c4451b5ec9 > Author: Pierre Joye <paj...@php.net> > Date: Mon Jul 18 21:26:29 2011 + > > -

Re: [PHP-DEV] Add spaceship assignment operator

to remotely imagine why one would need that. In short, yes, it is consistent but it is really unreadable, at best. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC about automatic template escaping

ape method (or filter/whatever else) has not been specified. This is a huge difference with is proposed here. Not sure about having such features in the core. It does sound like trying to solve a real issue but using the wrong solution or in the wrong place. Cheers, Pierre

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt

gt; So, to all people who wote "no", > please make clear you want to maintain this library. +1 here but I wonder why it would be different now than with 7.0 except introducing a BC in a minor release (7.2)? I would still vote +1 while it should be removed with 8.0. Cheers Pierre

Re: [PHP-DEV] NEWS entries

can be added but the fix has not been merged. Also security issues handling as a whole is a different important discussion :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

<    1   2   3   4   5   6   7   8   9   10   >