Re: [PHP-DEV] [VOTE] Add persistent curl share handles

On Tue, 5 Nov 2024 at 19:35, Eric Norris wrote: > > > That said, as I mentioned above I would be fine with removing cookie > > > jar persistence if that was necessary to secure a passing vote, since > > > it's not our primary focus. > > > > Given the information regarding the TLS re-use, the cook

Re: [PHP-DEV] [RFC] Lazy Objects

On Tue, 4 Jun 2024 at 13:29, Nicolas Grekas wrote: > Dear all, > > Arnaud and I are pleased to share with you the RFC we've been shaping for > over a year to add native support for lazy objects to PHP. > > Please find all the details here: > https://wiki.php.net/rfc/lazy-objects > > We look forwa

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

rrors does it not cause utter confusion if Bar isn't defined) Regards, Chris On Mon, 10 Aug 2020 at 09:41, Derick Rethans wrote: > Hi, > > I've just opened the vote to make sure we don't make a terrible mistake > with using the @@ syntax for attribut

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

ional voting option for those who would prefer to go down this route. I think the RFC now represents a concrete problem and solution suitable for voting on, but I'm going to leave discussion open for a few days in case anyone has any queries on the revisions. Regards, Chris On Fri, 24 Jul 202

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

t fairly let me know 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 > maintaini

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

urrently stand is that they are fully enabled: if we release PHP 8.0 with named params as they are now, there's no take backsies. Fixing the polymorphism issue and the maintenance issues become much harder as you have to work around the fact that there will be userland code relying on the feature as shipped. If we target fixing this in 8.1 we would lose the option of being able to make named params explicitly opt in and as such any possibility of a strict solution to the polymorphism issues that it throws up. Regards, Chris

[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

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

edParam) > > class Baz { > > public function bar($:renamedParam) { //... } > > } > > > > // Compile time error cannot rename named parameter $:external (renamed > to > > $:renamed) > > class Baz { > > public function baz($internal:renamed) {

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

tion, that must hit before the named parameter syntax is in a tagged version of PHP. Regards, Chris

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 : > > &g

[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

[PHP-DEV] Re: unpack() offset and consumed data measurement

On 28 January 2018 at 12:12, Chris Wright wrote: > > Here is some code that demonstrates the problem: > > /* This is the only way to know for certain how big float is on the > local system */ > define('FLOAT_WIDTH', strlen(pack('f', 0.0))); >

[PHP-DEV] Re: unpack() offset and consumed data measurement

On 28 January 2018 at 12:42, Christoph M. Becker wrote: > On 28.01.2018 at 13:12, Chris Wright wrote: > > > Since PHP 7.1 the unpack() function has a (still undocumented) optional > 3rd > > argument […] > > JFTR: documented with > <http://svn.php.net/vie

[PHP-DEV] unpack() offset and consumed data measurement

k up a patch in the coming week. Thanks, Chris

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] Re: PHP's mail servers suck

have the ability to give someone access, it's never > > granted. > > > > We need a way for infrastructure stuff like like to have a solid > > point > > person, who can give others power to handle things.   Sounds like > > we have > > some people willing t

Re: [PHP-DEV] Source tar.gz's extract slowly on some platforms

On 23 April 2017 at 17:24, Rowan Collins wrote: > On 23/04/2017 09:36, Christoph M. Becker wrote: > >> Thanks to Adam, there is . >> > > Yay! Adam, I love you! :) > > And cheers to you, Christoph, for the link! > > -- > Rowan Collins > [IMSoP] > > We are a

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 16:29 "Larry Garfield" napis

Re: [PHP-DEV] [RFC][VOTE]: Argon2 Password Hash

d there's always the possibility that something may change between now and then (e.g. some better default is decided on and/or some vuln is discovered in bcrypt/Argon2 that changes the considerations). Thanks, Chris

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 write patch for this. > >

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 posiible to redeclare in a sub-class final property as > >> non-final, here

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. > > > > https://bugs.php.net/bug.php?id=71915 > >

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: > > assert(is_null($this) || $t

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 HTTPS endpoint? > > You

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

On 24 March 2016 at 14:43, Scott Arciszewski wrote: > On Thu, Mar 24, 2016 at 9:55 AM, Chris Riley wrote: > >> On 24 March 2016 at 02:34, Yasuo Ohgaki wrote: >> >> > Hi all, >> > >> > Since the vote for >> > https://wiki.php.net/rf

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 > > - Session loss by race cond

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 for an RFC, to add Typed Properties. The > >

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 > wrote: > > > > > >> > > >> > > >> On Tue, Mar 15, 2016 at 5:11

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

On 24 February 2016 at 22:04, Chase Peeler wrote: > > > On Wed, Feb 24, 2016 at 4:46 PM Kevin Gessner wrote: > >> On Tue, Feb 23, 2016 at 4:48 AM, Chris Riley wrote: >> >> > This isn't such a great idea as it will cause some of traits >> functional

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; > } > > Only then will the

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 for its clarity > and completeness. > > Cheers,

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? > > The original RFC (https://wiki.php.net/rfc

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 >> least those who h

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 Conduct for the project > > > > https://wiki.php.

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. IMO. Regards, -- Yasuo O

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 be treated as any ot

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 else). I think it's be

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 overflow notwithstanding) comple

[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 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! > >his mail turned out to be

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 without

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 allowed. >>>

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 always > > be bugs" wi

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 happens to be >>> named _

Re: [PHP-DEV] Immutable modifier

On Tue, 17 Nov 2015, 02:07 Andrea Faulds 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 are really th

Re: [PHP-DEV] Immutable modifier

ties immutable, it makes the class not > extensible. > On Nov 16, 2015 10:24, "Daniel Persson" 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 Rile

Re: [PHP-DEV] Immutable modifier

On 16 November 2015 at 09:24, Daniel Persson 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 wrote: > >> Hi, >> >> There has been a lot of interest r

[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 (ma

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! > > > >> "void" or "null" as ret

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() >> there should pose no

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 this truly is

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 originally introduce

[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

Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

I updated the blog post to better explain why changing the license would be hard and would probably never happen. -Chris On Tue, Oct 6, 2015 at 1:56 PM, Marcel Araujo wrote: > PHP won't die! > > http://ctankersley.com/2015/10/06/zends-acquisition-doesnt-matter/ > > PHP,

Re: [PHP-DEV] New PHP SAPI for Nginx

On 26 June 2015 at 06:39, Rasmus Lerdorf wrote: > On 06/25/2015 01:31 PM, S.A.N wrote: > > New versions Nginx, implement thread pools, > > http://nginx.com/blog/thread-pools-boost-performance-9x/ > > > > I think this is a good opportunity to write a Nginx module (PHP SAPI) > > which is to process

Re: [PHP-DEV] [Q] Session provider & returning FAILURE from PS_OPEN_FUNC?

On 23 June 2015 at 23:09, Eric Stenson wrote: > Quick behavioral question: > > If an extension is implementing a Session handler, and returns FAILURE > from its PS_OPEN_FUNC(), will the extension receive subsequent > PS_READ_FUNC()/PS_WRITE_FUNC() calls? > > Also, if an extension returns FAILURE

Re: [PHP-DEV] PHP-FPM: How to clear the realpath cache on deployment?

On 19 June 2015 at 13:43, Sebastian Bergmann wrote: > Scenario: nginx + PHP-FPM / FastCGI. > > The final step of the deployment is updating a symlink to point to the > new version. > > For N <= realpath_cache_ttl seconds after the deployment, some > filesystem operations fail because of outd

Re: [PHP-DEV] LDAP module test suite

On 15 June 2015 at 14:02, Côme BERNIGAUD wrote: > Hello, > > What is the needed configuration to be able to run the whole LDAP test > suite? > It connects with "cn=Manager,dc=my-domain,dc=com" but then tries to create > "dc=my-domain,dc=com". > How can "cn=Manager,dc=my-domain,dc=com" exist if "d

Re: [PHP-DEV] Array dereferencing of scalars

On 12 June 2015 at 00:35, Rowan Collins wrote: > On 11/06/2015 21:22, Chris Wright wrote: > >> I'm inclined to agree that we should have consistency here, and that the >> current behaviour in a function context is the correct one. A couple of >> (IMO) good ar

Re: [PHP-DEV] Array dereferencing of scalars

On 11 June 2015 at 09:59, Rowan Collins wrote: > Yasuo Ohgaki wrote on 11/06/2015 00:50: > >> If PHP should return NULL always against NULL variables, we may be better >> to >> reconsider these behavior. >> >> [yohgaki@dev Download]$ php >> > $v = NULL; >> $$v; >> >> >> PHP Notice: Undefined var

Re: [PHP-DEV] PDO Oracle driver

On 22 April 2015 at 10:40, Stelian Mocanita wrote: > Hello internals, > > I would like to ask what on your thoughts on removing the Oracle drive for > PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php) > at least since it's been experimental for a long time now, and it has

Re: [PHP-DEV] Naming of 'weak' type hints

On 30 March 2015 at 15:16, Zeev Suraski wrote: > All, > > > > One thing that I think we should change is how we refer to the ‘weak’ type > hints. The word ‘weak’ has a negative ring to it, and considering this is > how the language behaves across the board it’s a pretty bad name for this > featu

Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

On 26 March 2015 at 22:40, Michael Morris wrote: > It's not a feature though - it's a bug. It's just one of those bugs that > the fixing of which may break something. > > TL;DR -1 for 7, and -1 in general. It's not really a bug, it works according to the defined behaviour, the issue is that som

Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7

On 25 March 2015 at 14:32, Rowan Collins wrote: > Chris Wright wrote on 25/03/2015 13:44: > >> That said, in the interests of not causing people using this functionality >> issues with logs full of errors and/or error-related performance issues, I >> would support having

Re: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP 7

On 25 March 2015 at 09:22, Tony Marston wrote: > "Zeev Suraski" wrote in message news:66c0cca2453de53bed0328af2732c7 > b...@mail.gmail.com... > > >> -Original Message- >>> From: Nikita Popov [mailto:nikita@gmail.com] >>> Sent: Tuesday, March 24, 2015 4:45 AM >>> To: PHP internals >>

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On 18 March 2015 at 17:07, Lazare Inepologlou wrote: > > 2015-03-18 16:28 GMT+01:00 Chris Wright : > >> On 18 March 2015 at 13:12, Pavel Kouřil wrote: >> >> > On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov >> > wrote: >> > > On 18 Mar 2015

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

On 18 March 2015 at 13:12, Pavel Kouřil wrote: > On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov > wrote: > > On 18 Mar 2015 15:52, "Pavel Kouřil" wrote: > >> > >> Hello, > >> > >> I made that conclusion because in the first example, the library kinda > >> forces strict mode rules on the caller

Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5

Congratulations Anthony, and to Andrea for her initial proposal. Finally, we have scalar type hints in PHP. PHP 7 is going to be a real game changer! Chris > On 16 Mar 2015, at 9:03 pm, Anthony Ferrara wrote: > > All, > > Voting has been closed on the scalar type declar

Re: [PHP-DEV] [RFC-Discuss] Scalar Type Declarations v0.5

namespaces? declare(strict_types=1) namespace Foo; namespace Bar; declare(strict_types=1) strict namespace Baz; Really good proposal though. Really hope it passes vote and we finally get scalar type hints in PHP. Cheers, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubsc

Re: [PHP-DEV] Preventing users from voting multiple times on a single bug

On 31 December 2014 at 11:12, Jacob Bednarz wrote: 1. Is this the correct list for changes related to bugs.php.net itself? If >not, what is the correct mailing list for this change? > This should probably go to php-webmaster@

Fwd: Re: [PHP-DEV] Re: Only variables can be passed by reference

Forgot to cc list, see below -- Forwarded message -- From: "Chris Wright" Date: 4 Dec 2014 14:09 Subject: Re: [PHP-DEV] Re: Only variables can be passed by reference To: "Andrea Faulds" Cc: > On 4 December 2014 at 12:26, Andrea Faulds wrote: >> &g

Re: [PHP-DEV] [RFC] Turn gc_collect_cycles into a function pointer

On 4 December 2014 at 14:26, Ferenc Kovacs wrote: > On Thu, Dec 4, 2014 at 1:17 PM, Julien Pauli wrote: > > > On Thu, Dec 4, 2014 at 12:39 PM, Ferenc Kovacs wrote: > > > > > > > > > On Thu, Dec 4, 2014 at 11:53 AM, Julien Pauli wrote: > > >> > > >> On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eber

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

On 19 November 2014 14:27, Rowan Collins wrote: > Alain Williams wrote on 19/11/2014 13:46: > >> On Wed, Nov 19, 2014 at 02:41:54PM +0100, Remi Collet wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Le 19/11/2014 00:11, Levi Morrison a écrit : >>> [1]: https://wiki.ph

Re: [PHP-DEV] Using a common shared lib for multiple SAPIs?

re is only a matter of a few MBs, tens of MBs at the most. In terms of modern computing this is almost nothing. In short, while I have no problem with altering the build process to make this *an option*, I wouldn't like it to be the default behaviour because the gains are just not big enough and it creates a couple of extra tripping hazards. Thanks, Chris

Re: AW: [PHP-DEV] forbid use declaration outside of a namespace in PHP 7

On 13 November 2014 11:29, Johannes Schlüter wrote: > On Wed, 2014-11-12 at 22:27 +0100, Robert Stoll wrote: > > > That's still perfectly fine because in your code the use statement is > not outside of a namespace, it is implicitly in the default namespace. > > I am talking about the two followin

Re: [PHP-DEV] forbid use declaration outside of a namespace in PHP 7

On 11 November 2014 12:11, Robert Stoll wrote: > > -Ursprüngliche Nachricht- > > Von: Robert Stoll [mailto:p...@tutteli.ch] > > Gesendet: Mittwoch, 29. Oktober 2014 20:55 > > An: 'PHP Internals' > > Betreff: [PHP-DEV] forbid use declaration outside of a namespace in PHP 7 > > > > Heya, >

Re: [PHP-DEV] Add a new flag for json_encode

On 5 November 2014 17:21, Jakub Zelenka wrote: > > > On Wed, Nov 5, 2014 at 4:52 PM, Chris Wright wrote: > >> >> I'm sorry, but I don't understand why it would need to be deprecated. For >> me "making it the default behaviour" would mean "

Re: [PHP-DEV] [RFC] Additional splat operator usage

On 5 November 2014 11:43, Chris Wright wrote: > On 5 November 2014 11:22, Leigh wrote: > >> On 4 November 2014 18:14, Rowan Collins wrote: >> > >> > If anything, I think I would expect the keys of splatted arrays to be >> discarded, since it seems most n

Re: [PHP-DEV] Add a new flag for json_encode

On 5 November 2014 16:45, Jakub Zelenka wrote: > > On Wed, Nov 5, 2014 at 2:33 PM, Chris Wright wrote >> >> >> I'm afraid I have to disagree here, I don't like the idea of changing >> this behaviour without making it controllable >> > > If w

Re: [PHP-DEV] Add a new flag for json_encode

On 4 November 2014 17:07, Jakub Zelenka wrote: > On Tue, Nov 4, 2014 at 2:57 PM, Ferenc Kovacs wrote: > > > On Tue, Nov 4, 2014 at 4:13 AM, Juan Basso wrote: > > > > > Hi, > > > > > > I opened a pull request[1] in order to solve the bug 50224[2] and it > > ended > > > creating this pull request

Re: [PHP-DEV] [RFC] Additional splat operator usage

On 5 November 2014 11:22, Leigh wrote: > On 4 November 2014 18:14, Rowan Collins wrote: > > > > If anything, I think I would expect the keys of splatted arrays to be > discarded, since it seems most natural to use this in a list context, but I > can imagine always having to check in the manual.

Re: [PHP-DEV] [RFC] Additional splat operator usage

le want to discuss it on-list at this stage I suggest starting a separate thread (I wasn't planning to until I have clarified my own ideas). I do need to explore the impact to to opcodes and opcache, and was planning to come to you to discuss this shortly. Thanks, Chris Thanks. Dmitry. >

Re: [PHP-DEV] [RFC] Additional splat operator usage

On 4 November 2014 18:14, Rowan Collins wrote: > On 3 November 2014 22:45:11 GMT, Chris Wright wrote: > >Good evening list, > > > >I'd like to open discussion a relatively simple and clear-cut RFC, > >either > >people will like it or they won't,

Re: [PHP-DEV] Debugging code ...

On 4 November 2014 16:07, Lester Caine wrote: > On 04/11/14 14:51, Kristopher wrote: > > Every IDE I've used has always working nicely with docblock > annotation > > and typing and has provided the facilities people seem to think > should > > be built in to PHP. > > > > You understand

Re: AW: [PHP-DEV] Types on the right or on the left

On 4 November 2014 12:17, Robert Stoll wrote: > > > -Ursprüngliche Nachricht- > > Von: are.you.winn...@gmail.com [mailto:are.you.winn...@gmail.com] Im > Auftrag von Chris Wright > > Gesendet: Dienstag, 4. November 2014 12:51 > > An: Andrea Faulds > >

Re: AW: [PHP-DEV] Types on the right or on the left

On 4 November 2014 10:32, Andrea Faulds wrote: > > > On 4 Nov 2014, at 08:51, Stas Malyshev wrote: > > > > I agree, this is not a very good situation. It would be much better to > > take a systematic approach to this, but this is impossible since there > > is no systematic approach to strict typ

[PHP-DEV] [RFC] Additional splat operator usage

Good evening list, I'd like to open discussion a relatively simple and clear-cut RFC, either people will like it or they won't, there isn't a lot more to say here than what's in the RFC so please have a read. https://wiki.php.net/rfc/additional-splat-usage Thanks, Chris

Re: [PHP-DEV] [PR] DateTime RFC7231 constant

.c#1189 The "R" format character is available and probably makes the most sense of the available possibilities, as the format approximately complements "r". Thanks, Chris

Re: [PHP-DEV] Annotation PHP 7

Cs you linked above are all basically dead. You are of course welcome to put together a proposal and/or start up a discussion on the subject if it is something you would be prepared to put work into. Thanks, Chris

Re: [PHP-DEV] Re: [RFC] Access to aliases definition by reflection

"HttpClient"; $obj = new $className; var_dump($obj instanceof $className); There may be others as well, these are just two that immediately sprang to mind. The getDefinedAliases() code depicted above doesn't really belong on a ReflectionClass, or any of the other classes that currently exist, as the aliases aren't associated with the class/function itself but the environment in which it was defined. Thanks, Chris

[PHP-DEV] Volunteering for sysadmin help

#x27;s any help that I can provide, I'd be glad to throw in my time to help out. -- Chris Tankersley http://ctankersley.com 419.785.6408

Re: [PHP-DEV] [RFC] Readonly Properties

On 27 October 2014 20:27, Andrea Faulds wrote: > > > On 26 Oct 2014, at 19:16, Rowan Collins wrote: > > > > I just had a thought on both the naming and future-proofing concerns of > this proposal: what about pre-emptively reserving the skeleton of the > syntax needed for accessors, without actua

  1   2   3   4   5   >