Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Sat, 15 Aug 2020 at 10:54, Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi Theodore, > > pt., 14 sie 2020, 22:16 użytkownik Theodore Brown > napisał: > > > On Fri, Aug 14, 2020 at 2:23 PM Derick Rethans wrote: > > > > > On Fri, 14 Aug 2020, Sara Golemon wrote: > > > > >

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Tue, 11 Aug 2020 at 13:21, Derick Rethans wrote: > On Tue, 11 Aug 2020, Chris Riley wrote: > > > Quick question. > > > > What is the expected behaviour of: > > > > @[Bar()]; > > class Foo {} > > That will error out in PHP 8, with:

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

On Tue, 11 Aug 2020 at 12:40, Matteo Beccati wrote: > Hi, > > On 11/08/2020 12:10, Chris Riley wrote: > > What is the expected behaviour of: > > > > @[Bar()]; > > class Foo {} > > > > That would appear to be valid code and for the difference o

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

Hi, Quick question. What is the expected behaviour of: @[Bar()]; class Foo {} That would appear to be valid code and for the difference of a single ; does wildly different things, assuming there is a function Bar defined somewhere. (and only by the fact that @ doesn't suppress fatal errors

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

, Chris Riley wrote: > Hi all, > > The named parameters RFC has been accepted, despite significant objections > from maintainers of larger OSS projects due to the overhead it adds to > maintaining backwards compatibility as it has now made method/function > parameter nam

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

and I'll update. Regards, Chris On Fri, 24 Jul 2020 at 12:12, Chris Riley wrote: > Hi all, > > The named parameters RFC has been accepted, despite significant objections > from maintainers of larger OSS projects due to the overhead it adds to > maintaining backwards compatibilit

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

On Fri, 24 Jul 2020 at 16:41, Sara Golemon wrote: > On Fri, Jul 24, 2020 at 10:10 AM Nikita Popov > wrote: > > > > You added PHP 8.0 as a proposed version, but that will not be > possible > > > > anymore 2 weeks of discussion + 2 weeks of voting are not possible > to fit > > > > in before the

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

Hi all, Following up from this I've created a draft RFC: https://wiki.php.net/rfc/renamed_parameters will move to in discussion once I've ensured everything important has been captured. Regards, Chris On Fri, 24 Jul 2020 at 12:12, Chris Riley wrote: > Hi all, > > The named parameter

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

On Fri, 24 Jul 2020 at 14:43, Benjamin Eberlei wrote: > > > On Fri, Jul 24, 2020 at 3:15 PM Chris Riley wrote: > >> On Fri, 24 Jul 2020 at 14:01, Benjamin Eberlei >> wrote: >> >>> >>> >>> On Fri, Jul 24, 2020 at 1:13 PM Chris Riley w

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

On Fri, 24 Jul 2020 at 14:01, Benjamin Eberlei wrote: > > > On Fri, Jul 24, 2020 at 1:13 PM Chris Riley wrote: > >> Hi all, >> >> The named parameters RFC has been accepted, despite significant objections >> from maintainers of larger OSS projects due to th

[PHP-DEV] Wiki Karma request

Hi, Requesting karma to create RFC's for my account: carnage. Want to get the ball rolling on https://externals.io/message/61 Thanks, Chris

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

On Fri, 24 Jul 2020 at 13:05, Marcio Almada wrote: > Hi > > > > > Hi all, > > > > The named parameters RFC has been accepted, despite significant > objections > > from maintainers of larger OSS projects due to the overhead it adds to > > maintaining backwards compatibility as it has now made

[PHP-DEV] [RFC][Proposal] Renamed parameters

Hi all, The named parameters RFC has been accepted, despite significant objections from maintainers of larger OSS projects due to the overhead it adds to maintaining backwards compatibility as it has now made method/function parameter names part of the API; a change to them would cause a BC break

Re: [PHP-DEV][RFC] Cast in foreach

Cast would work for both key and value, although I think the instances where you need to cast a key will be fewer. On Thu, Feb 21, 2019, 15:08 Legale.legale wrote: > what about: > > foreach($array as $i=>$v) {} > > ?On Feb 21, 2019 13:15, Chris Riley wrote: > > >

Re: [PHP-DEV][RFC] Cast in foreach

In this instance, I would expect the cast to come before each variable eg foreach ($data as ["id" => (int) $id, "name" => (string) $name]) On Thu, Feb 21, 2019, 13:28 Kalle Sommer Nielsen wrote: > Den tor. 21. feb. 2019 kl. 14.16 skrev Chris Riley : > >

[PHP-DEV][RFC] Cast in foreach

Hi internals, I'd like to propose opening an rfc to make the following syntax legal: foreach($array as (int) $i) {} Which would be functionally equivalent to foreach($array as $i) { $i=(int) $i; } Thoughts? Feedback? ~C

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

Hi, How useful is "scalar" as a type hint? I'm not sure it provides any benefit over "mixed". Would it not be better to copy Hack and instead introduce two type hints: "num" (or "number") which is int|float and "arraykey" which is string|int? To me, these are much more useful pseudo types than

Re: [PHP-DEV] RFC - Immutable classes

On 2 September 2016 at 15:59, Silvio Marijić wrote: > Michal I'm talking about __clone() callback after clone operation. But I > agree with you about syntax part. > > 2016-09-02 16:46 GMT+02:00 Michał Brzuchalski < > michal.brzuchal...@gmail.com> > : > > > 02.09.2016

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

On 10 May 2016 at 17:48, Fleshgrinder wrote: > On 5/10/2016 5:24 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

Re: [PHP-DEV] Final properties

On 5 April 2016 at 11:57, Michał Brzuchalski wrote: > Hi, > > 2016-04-05 12:13 GMT+02:00 Marco Pivetta : > > > Hi, > > > > On 5 April 2016 at 12:06, Michał Brzuchalski > > wrote: > > > >> Hi Marco, > >> > >> Ad. 1 it is

Re: [PHP-DEV] #71915 openssl_random_pseudo_bytes is not "fork-safe"

On 29 March 2016 at 19:49, Jakub Zelenka wrote: > I have added some feedback and assigned it to myself ;) > > On Tue, Mar 29, 2016 at 3:05 PM, Tom Worster wrote: > > > mathieuk has requested feedback on a patch to mitigate this problem in > PHP. > > > >

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

On 29 March 2016 at 23:21, Nikita Popov wrote: > Hi internals! > > Currently, inside instance methods the following invariant holds: > > assert(is_null($this) || is_object($this)) > > This is a problem. I'd like to guarantee the following invariant instead: > >

Re: [PHP-DEV] [RFC][Discussion] Precise session data management

You are right, perhaps this should be controlled simply by an ini flag: session https only. On Mon, 28 Mar 2016, 01:09 Stanislav Malyshev, wrote: > Hi! > > >> Could we also add HTTPS detection and enable the secure flag by default > >> when a session is established on an

Re: [PHP-DEV] [RFC][Discussion] Precise session data management

On 24 March 2016 at 14:43, Scott Arciszewski <sc...@paragonie.com> wrote: > On Thu, Mar 24, 2016 at 9:55 AM, Chris Riley <t.carn...@gmail.com> wrote: > >> On 24 March 2016 at 02:34, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> >> > Hi all, >> >

Re: [PHP-DEV] [RFC][Discussion] Precise session data management

On 24 March 2016 at 02:34, Yasuo Ohgaki wrote: > Hi all, > > Since the vote for > https://wiki.php.net/rfc/precise_session_management > is declined 15 vs 11. > https://wiki.php.net/rfc/precise_session_management#vote > > We have to come up with other solutions for > > -

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

Honestly, as it stands this is a pretty terrible idea. 1. It has a huge potential for introducing BC breaks. - I have some code somewhere which uses output buffering and echo to write cached copies of html pages to disk. This would break that. - Writing out html like structures when running as

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

On 16 March 2016 at 17:17, Bob Weinand wrote: > Hey, thank you both for investing your time :-) > Property types are definitely interesting. > > > Am 16.03.2016 um 17:36 schrieb Phil Sturgeon : > > > > Hello everyone, > > > > I have completed the draft

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

On 15 March 2016 at 17:40, Will Fitch wrote: > > > On Tue, Mar 15, 2016, at 12:18 PM, Ferenc Kovacs wrote: > > On Tue, Mar 15, 2016 at 6:13 PM, Scott Arciszewski > > wrote: > > > > > On Tue, Mar 15, 2016 at 1:09 PM, Ferenc Kovacs >

Re: [PHP-DEV] Re: [RFC] Traits with interfaces

On 24 February 2016 at 22:04, Chase Peeler <chasepee...@gmail.com> wrote: > > > On Wed, Feb 24, 2016 at 4:46 PM Kevin Gessner <kgess...@etsy.com> wrote: > >> On Tue, Feb 23, 2016 at 4:48 AM, Chris Riley <t.carn...@gmail.com> wrote: >> >> >

Re: [PHP-DEV] Re: [RFC] Traits with interfaces

On 23 February 2016 at 00:37, Alex Bowers wrote: > Would a fair solution to this be having the using class define whether to > inherit the implementations? Perhaps a new keyword akin to 'propagated', so > the code will read > > Class Foo { >Use propagated TraitName; > }

Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

On 22 January 2016 at 14:29, Pierre Joye wrote: > On Jan 22, 2016 7:03 PM, "Derick Rethans" wrote: > > Freshly adopted: > > http://rubyonrails.org/conduct/ > https://golang.org/conduct > > I like both with a very good special mention for the Go one

Re: [PHP-DEV] PHP 7.1 - Argon2

On 11 January 2016 at 09:12, Rouven Weßling wrote: > > > On 11 Jan 2016, at 07:57, Scott Arciszewski wrote: > > > > Does adding Argon2 as a possible choice for password_hash() + > > password_verify() need an RFC? Or can I just submit a pull request?

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

On 5 January 2016 at 16:15, Anthony Ferrara wrote: > All, > > On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara > wrote: > > Hey all, > > > > I have created a new RFC for the PHP Project to adopt the Contributor > > Covenant as the official Code of

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

On Tue, 5 Jan 2016, 18:20 Ferenc Kovacs wrote: > >> Additionally, given that this CoC has far reaching consequences, I would >> suggest opening up voting on it's implementation to a wider segment of the >> community eg those currently subscribed to the PHP mailing lists or at

Re: [PHP-DEV] Benchmark Results for PHP Master 2015-12-17

On 18 December 2015 at 02:39, Good Guy wrote: > On 18/12/15 02:15, Yasuo Ohgaki wrote: > >> The objective of this benchmark is to alert developers accidental >> performance drop. Even small change may affect performance a lot. This >> would be good enough for the purpose.

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

On 4 December 2015 at 13:54, Lester Caine wrote: > On 04/12/15 10:29, Sebastian Bergmann wrote: > >> Windows as a platform is different from Linux/Mac in several aspects > > True. But why does the PHP Project have to provide Windows binaries on > > php.net? Microsoft should

Re: [PHP-DEV] HashDos protection

On 1 December 2015 at 09:50, Dmitry Stogov wrote: > Hi Nikita, > > few notes: > > It looks like the patch messes the attempt of catching the problem (few > lines related to zend_hash_find_bucket changes) with optimization to > compensate collision check overhead (everything

Re: [PHP-DEV] RE: HashDos protection

On 28 November 2015 at 01:00, Pascal KISSIAN wrote: > -Message d'origine- > De : Nikita Popov [mailto:nikita@gmail.com] > Envoyé : jeudi 26 novembre 2015 18:25 > À : PHP internals; Anatol Belski; Remi Collet > Objet : HashDos protection > > >Hi internals! >

[PHP-DEV] Pear.php.net SSL cert

Anyone else getting an invalid cert on https://pear.php.net ?

Re: [PHP-DEV] RE: HashDos protection

On 30 November 2015 at 13:58, Pascal KISSIAN wrote: > >De : Nikita Popov [mailto:nikita@gmail.com] > >Envoyé : dimanche 29 novembre 2015 12:45 > >À : Pascal KISSIAN > >Cc : PHP internals > >Objet : Re: HashDos protection > > >Collisions in DJBX33A are (integer

Re: [PHP-DEV] Native Annotation Syntax

On 26 November 2015 at 16:05, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Ok then. I'll pretend that lack of interest didn't happen many other > situations (like http://marc.info/?t=14460876781) and move on. > > I don't want to bring the patch up to date/simplify it

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

On 24 November 2015 at 17:16, Andrea Faulds wrote: > Hi Stas, > > Stanislav Malyshev wrote: > >> Hi! >> >>>>>function a(\int $i) {} Is it intentional that the \ in front of the "int" is allowed? IMHO, this confusing notation must not be

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

On 23 November 2015 at 09:08, Rasmus Lerdorf wrote: > On 11/23/2015 09:49 AM, Phil Sturgeon wrote: > > The "There will always be bugs" argument is a strawman, nobody is > > saying wait until it's perfect. > > > > People in this thread are consistently conflating "there will

Re: [PHP-DEV] Immutable modifier

On 17 November 2015 at 11:04, Rowan Collins wrote: > Hi Andrea, > > Andrea Faulds wrote on 17/11/2015 01:47: > >> Larry Garfield wrote: >> >>> The "everything in the constructor" is the problem. That results in, >>> essentially, an obscenely long function call that just

[PHP-DEV] Immutable modifier

Hi, There has been a lot of interest recently (eg psr-7) in immutable data. I'm considering putting an RFC together to add language support for immutables: immutable class Foo { public $bar; public function __construct($bar) { $this->bar = $bar; } } Immutable on a class declaration makes all

Re: [PHP-DEV] Immutable modifier

On 16 November 2015 at 09:24, Daniel Persson <mailto.wo...@gmail.com> wrote: > Any differance from the final keyword? > > http://php.net/manual/en/language.oop5.final.php > > On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley <t.carn...@gmail.com> wrote: > >> Hi, &g

Re: [PHP-DEV] Immutable modifier

> Final does not make the properties immutable, it makes the class not > extensible. > On Nov 16, 2015 10:24, "Daniel Persson" <mailto.wo...@gmail.com> wrote: > >> Any differance from the final keyword? >> >> http://php.net/manual/en/language.oop5.fi

Re: [PHP-DEV] Immutable modifier

On Tue, 17 Nov 2015, 02:07 Andrea Faulds <a...@ajf.me> wrote: Hi, Chris Riley wrote: > > There has been a lot of interest recently (eg psr-7) in immutable data. I'm > considering putting an RFC together to add language support for immutables: > I wonder if immutable classes ar

Re: [PHP-DEV] [VOTE] Void Return Type RFC

Hi, I'm still not sure why we are using void as the return type and not null. Null matches behaviour, void just adds another keyword without value. ~C On 30 October 2015 at 04:33, Rasmus Lerdorf wrote: > On 10/29/2015 08:55 PM, Stanislav Malyshev wrote: > > Hi! > > > >>

Re: [PHP-DEV] Password_hash salt generation refactor

On 19 October 2015 at 16:22, Tom Worster wrote: > On 10/18/15 7:39 PM, Ángel González wrote: > >> Korvin wrote: >> >>> +1 for 7.0.x security patch release, best effort sounds scary. >>> >> This is a salt. It doesn't need to be cryptographically secure. Using >> php_rand() >>

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

On 14 October 2015 at 22:52, Andrea Faulds wrote: > Good evening, > > I'm reviving my Void Return Type RFC, this time for PHP 7.1: > > https://wiki.php.net/rfc/void_return_type > > Please read it and tell me your thoughts! > > Thanks. > > P.S. As it so (fatefully?) happens, I

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

On 15 October 2015 at 16:32, Andrea Faulds wrote: > In a sense, what this RFC offers might be called a compromise. It enforces > the rules of `void` within the function, but at the end of the day the > caller still gets a null out of it since that's what PHP's always done. > > > If

[PHP-DEV] Add Scrypt support to password_hash

We already have a pecl extension for adding scrypt to php, however I think it would be worth while to add it as an additional option to password_hash. We would of cause leave Bcrypt as the default option. Any thoughts on this? Chris