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

On 16 March 2016 at 09:36, Phil Sturgeon wrote: > 3. Weak vs Strict. Right now this is entirely strict, with no > declare() to change mode. Reasons for this vary, from various sources, > but include "Not sure how to implement it" and "Well people should not > be using

Re: [PHP-DEV] [RFC] Callable constructors

On 25 February 2016 at 14:19, Dan Ackroyd <dan...@basereality.com> wrote: > On 25 February 2016 at 18:16, Adam Harvey <a...@adamharvey.name> wrote: >> >> am I right >> that this is equivalent to the following? >> >>$injector->delegate(

Re: [PHP-DEV] Re: [RFC] Callable constructors

On 25 February 2016 at 09:40, Andrea Faulds wrote: > Instead of changing __construct to implicitly create the object it acts on > in certain contexts, I would suggest a simpler approach: add a magic ::new() > static method that exists on all classes (think ::class, although that is a

Re: [PHP-DEV] [RFC] Callable constructors

On 25 February 2016 at 08:44, Dan Ackroyd wrote: > I use the Auryn* DIC library. What I've wanted to do, and should be > able to do in my opinion, is this: > > $injector->delegate('FooInterface', 'FooImplementation::__construct'); I only skimmed the RFC (and am unfamiliar

Re: [PHP-DEV] Throwable and Error exceptions break existing PHP 5.x code

On 11 January 2016 at 06:05, Rowan Collins wrote: > Since set_exception_handler() is intended as a last-ditch "something's gone > very wrong" function anyway, I think it receiving all Throwables makes > sense, even if the BC break in your scenario is unfortunate. Agreed

Re: [PHP-DEV] Re: [RFC] GitHub Pull Requests Triage Team

On 1 January 2016 at 12:12, Bishop Bettini wrote: > On Fri, Jan 1, 2016 at 2:53 PM, John Bafford wrote: >> I think when I brought this up before, the major open discussion point >> before the thread died was what period of time constituted long enough for >>

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

On 4 January 2016 at 13:06, Anthony Ferrara wrote: > 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.net/rfc/adopt-code-of-conduct I am definitely pro-this. Good thinking!

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

On 4 January 2016 at 17:34, Stanislav Malyshev wrote: > If we're talking about having a declaration of principles, I am not sure > we need elaborate text to say "don't be an ass" but I don't mind having > one in case somebody ever need explicit instructions on how exactly not

Re: [PHP-DEV] Converting an 'old' PHP 5.x extension to PHP 7

On 10 December 2015 at 08:51, Sjoerd Maessen wrote: > As a first time poster I'm very nervous but here we go! Welcome! > I cloned the github repo and was able to remove 1 error during the > compilation process that had to do with ZVAL_STRING. This was an easy error >

Re: [PHP-DEV] PHP 7 ?! :)

On 3 December 2015 at 13:49, Niklas Keller wrote: > Yes, but it's missing an usort($releases, function($a, $b) { return > version_compare($a["version"], $b["version]); }); ;-) I'm *cough* sure I don't know what you're *cough* talking about... Adam PS:

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

On 22 November 2015 at 14:19, Rasmus Lerdorf wrote: > On 11/22/2015 06:18 AM, Anthony Ferrara wrote: >> Zeev, >> >> On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski wrote: >>> >>> IMHO, unless we think fixing this would require breaking binary >>> compatibility

Re: [PHP-DEV] PHP7 / foreach / references / ugly code / discrepancy to PHP 5.6

Hey Nikita, On 10 November 2015 at 11:45, Nikita Popov wrote: > This is a bug in PHP 5, which has been fixed in PHP 7 as a side-effect of > other changes. The new behavior is correct. This issue is tracked at > https://bugs.php.net/bug.php?id=70857. Are there any other

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

On 29 October 2015 at 06:24, Marcio Almada wrote: > Welcome back, Andrea! It's great to see you contributing here again :) +1. :) > 1) functions declared with "void" return type will still return > "null", so "void" is a big fat lie for PHP while "null" is currently >

Re: [PHP-DEV] Scalar type hints and scalar type name aliases cause confuson

(Sorry Andrea, I'm picking on your e-mail because it's easiest, but it's a general response to the thread.) On 13 October 2015 at 06:32, Andrea Faulds wrote: > e.g. > > $ ./sapi/cli/php -r 'function foo(): long {}' > > Fatal error: 'long' is not a valid type hint, use 'int'

[PHP-DEV] Re: ABI break? (was: [PHP-CVS] com php-src: Don't inline "slow" and rarely used functions.: Zend/zend_alloc.c Zend/zend_alloc.h)

On 16 September 2015 at 14:36, Kalle Sommer Nielsen wrote: > 2015-09-16 23:31 GMT+02:00 Anatol Belski : >> While your observation is correct, I wouldn't see the matter as an alarming >> issue. We're oriented to have less bugs in every next RC, thus RC2 will

[PHP-DEV] ABI break? (was: [PHP-CVS] com php-src: Don't inline "slow" and rarely used functions.: Zend/zend_alloc.c Zend/zend_alloc.h)

On 9 September 2015 at 03:42, Dmitry Stogov wrote: > Commit:ac83eaef1097552065395872c69b77dcab2919b1 > Author:Dmitry Stogov Wed, 9 Sep 2015 13:42:35 > +0300 > Parents: 6d885e395ca33fef28c5b84b7cfd59885aaa6e2d > Branches: master > > Link:

Re: [PHP-DEV] set_exception_handler catches all Throwables

On 19 August 2015 at 07:20, Björn Larsson bjorn.x.lars...@telia.com wrote: Den 2015-08-19 kl. 15:55, skrev Ryan Pallas: I agree with this completely. I think the point here is that catch(Exception $e) remains unchanged while setting a handler actually catches more things now. Tbh I feel like

Re: [PHP-DEV] libpcre version requirements

On 13 August 2015 at 04:35, Christoph Becker cmbecke...@gmx.de wrote: On 12.08.2015 at 08:44, Anatol Belski wrote: [...] However look - http://w3techs.com/technologies/details/os-linux/all/all . From those, CentOS 5/6 releases are not even a year old and contain 6.6, 7.x but take 20% of

Re: [PHP-DEV] libpcre version requirements

On 11 August 2015 at 09:46, Christoph Becker cmbecke...@gmx.de wrote: What is the minimum libpcre version that is supported as external libpcre for ext/pcre? According to config0.m4 it is PCRE 6.6 (2006-02-06), but is this still valid and do we really have to support such old versions?

Re: [PHP-DEV] PCRE JIT stack size limit

On 23 July 2015 at 11:47, Christoph Becker cmbecke...@gmx.de wrote: snip great explanation, thanks Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit). That would mean, however, to add yet another ini setting, of which there are already so many. I'm not a big fan of that,

Re: [PHP-DEV] Re: Announcing PHP 5.5 security-only

On 22 June 2015 at 16:05, Ángel González keis...@gmail.com wrote: @Adam, I was expecting the gory details to involve a of PHP commiters with black robes, faces hidden behind their hoods meeting overnight and an absurdly complex algorithm involving lunar cycles. instead you point to a manual

Re: [PHP-DEV] Re: Announcing PHP 5.5 security-only

On 22 June 2015 at 14:10, Stanislav Malyshev smalys...@gmail.com wrote: Hi! *** The PHP 5.5 branch is going to enter in security only, and in the same time, PHP 5.4 will finally die *** I think http://php.net/supported-versions.php says we end 5.4 support on 14 Sep 2015 so we have 2 more

Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism

On 28 April 2015 at 15:10, Patrick ALLAERT patrickalla...@php.net wrote: Le mar. 28 avr. 2015 à 20:42, Kalle Sommer Nielsen ka...@php.net a écrit : I should probably have been faster at replying, but for PHP7 this is a no-go. I realize this is a pure internal change and have nothing to do

Re: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

On 8 April 2015 at 08:16, Anthony Ferrara ircmax...@gmail.com wrote: Sophistication is fine. What worries me though is magic. What worries me is the growing inability to debug with normal tools. Perhaps we need a GDB extension to provide tooling for common debugging tasks. Heck, even dumping a

Re: [PHP-DEV] Deprecate setlocale?

On 2 April 2015 at 12:24, Dan Ackroyd dan...@basereality.com wrote: On 2 April 2015 at 16:01, Keyur Govande keyurgova...@gmail.com wrote: To Rasmus's point, here's a PR for HHVM to provide a thread-safe setlocale implementation: https://github.com/facebook/hhvm/pull/4736/files It should be

Re: [PHP-DEV] [RFC] Basic Scalar Types

On 11 March 2015 at 14:28, Bob Weinand bobw...@hotmail.com wrote: after all, some people are not happy with the current proposals about scalar types. So, they both still possibly may fail. Thus, I'd like to come up with a fallback proposal in case both proposals fail:

Re: [PHP-DEV] Re: [VOTE] Remove deprecated functionality in PHP 7

On 5 March 2015 at 12:21, Pierre Joye pierre@gmail.com wrote: It would be good to do a pecl release for each of them, and mark the package as deprecated/overseeded by mysqli (I let you choose). Doing so will trigger a build there, cleaner. I'm on the fence about making a release for ereg

Re: [PHP-DEV] Re: [VOTE] Remove deprecated functionality in PHP 7

On 5 March 2015 at 05:39, Jan Ehrhardt php...@ehrhardt.nl wrote: I had already built a php_ereg.dll and a php_mysql.dll for PHP7, using the sources of two days ago. The config.w32 for ereg needs some changes, if you want to enable shared builds on Windows:

Re: [PHP-DEV] Re: [VOTE] Remove deprecated functionality in PHP 7

On 16 January 2015 at 09:16, Nikita Popov nikita@gmail.com wrote: I'll land the minor removals sometime soon; the unbundling of ext/ereg and ext/mysql should probably be done by someone else who's more into the PECL business. They gone. Many thanks to Tjerk, for doing all the hard work on

[PHP-DEV] Deadline for 7.0; was: [RFC][Discussion] In Operator

On 20 February 2015 at 04:54, Niklas Keller m...@kelunik.com wrote: Question: The timline says Line up any remaining RFCs that target PHP 7.0., does that mean RFCs have to start voting on Mar 15 or should the vote end there? My interpretation was that votes had to be concluded on or before

Re: [PHP-DEV] [VOTE] Expectations

On 19 February 2015 at 01:09, Joe Watkins pthre...@pthreads.org wrote: The expectations RFC is now in voting phase: https://wiki.php.net/rfc/expectations#vote Sorry, I had an e-mail backlog while this was in discussion, so I'm only getting around to this now. Two thoughts: 1. This is

Re: [PHP-DEV] Deadline for 7.0; was: [RFC][Discussion] In Operator

(Please don't top post!) On 20 February 2015 at 11:31, François Laupretre franc...@php.net wrote: My interpretation was that votes had to be concluded on or before March 15 to be included in 7.0, but that is kind of ambiguous, now you mention it. I would say that vote can *start*by March 15,

[PHP-DEV] [RFC] Comparable: the revenge

Hi all, Those of you with long memories will remember that I proposed a Comparable interface way back in the pre-5.4 days, but withdrew it when it became obvious that there was no consensus for it as a feature and that a vote was likely to fail. RFC: https://wiki.php.net/rfc/comparable PR:

Re: [PHP-DEV] [RFC] Comparable: the revenge

I don't want to get into a lengthy debate (you have your opinion; I have mine!), but to rebut a couple of specific points: On 19 February 2015 at 14:19, Levi Morrison le...@php.net wrote: Another issue: it allows comparing an object to non-objects (even though the stated goal is only to compare

Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions

On 11 February 2015 at 06:59, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski anatol@belski.net wrote: ext/mssql 17:13 Did you accidentally miss out mssql? it resultes in significant resistance to leave core, such as mcrypt and

Re: [PHP-DEV] [VOTE] Scalar Type Hints

On 6 February 2015 at 04:14, Andrea Faulds a...@ajf.me wrote: At long last, I’m going to put the RFC to a vote. It’s been long enough - I don’t think there needs to be, or will be, much further discussion. True, and I probably won't respond to any replies to this because we don't need more

Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()

On 5 February 2015 at 13:06, Yasuo Ohgaki yohg...@ohgaki.net wrote: Since script()/script_once() is almost copy of require()/require_once(), it could be INI option. require_embed = On/Off Almost all users use 'require' only for script today, I guess. I should have included this option in

Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions

On 3 February 2015 at 03:11, Anatol Belski anatol@belski.net wrote: properly after the voting phase the https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the voting. Each item is voted separately. The voting ends on 2015-02-09 at 21:00 CET. To explain my -1s: - ext/imap

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

On 22 January 2015 at 00:56, Benjamin Eberlei kont...@beberlei.de wrote: On Wed, Jan 7, 2015 at 8:33 PM, Benjamin Eberlei kont...@beberlei.de wrote: Hello everyone, After discussion I am putting the RFC on turning gc_collect_cycles into a function pointer to vote:

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

On 20 January 2015 at 07:09, Kristopher kristopherwil...@gmail.com wrote: @everyone: Would an RFC be necessary to update the PHP manual to actually recommend the PHP 5 constructors and recommend against using the PHP 4 style constructors, using very explicit language? If not, should this

Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls

On 20 January 2015 at 12:54, Marc Bennewitz dev@mabe.berlin wrote: valid for call_user_func[_array] and callable type-hint but invalid for for direct variable calls: - string MyClass::staticFunc - string self::staticFunc - string static::staticFunc - string parent::func - string

Re: [PHP-DEV] [RFC] Skipping parameters take 2

On 17 January 2015 at 18:04, Andrea Faulds a...@ajf.me wrote: For consistency with list(), we could also just put nothing: foo($bar, , $baz); Which is like: list($bar, , $baz) = $arr; Thoughts? That was Stas's original, original proposal way back when. I argued then for having

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

On 15 January 2015 at 17:35, Pierre Joye pierre@gmail.com wrote: On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote: On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote: On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote: https://wiki.php.net/rfc

Re: [PHP-DEV] [RFC] Skipping parameters take 2

On 14 January 2015 at 11:15, Marc Bennewitz dev@mabe.berlin wrote: But I think adding default as new keyword is a big BC break! Default already is a keyword: http://php.net/switch. There's no BC break. I personally also don't like it and asked myself why can't the parameter simply skipped?

Re: [PHP-DEV] journald support for Linux systems that use systemd

On 8 January 2015 at 01:39, Markus Fischer mar...@fischer.name wrote: On 08.01.15 02:14, Johannes Schlüter wrote: On Wed, 2015-01-07 at 17:01 -0500, Mark Montague wrote: I'd like to start an RFC (see the draft proposal at the end of this message) for adding journald support to PHP on Linux

Re: [PHP-DEV] [RFC] Extension Prepend Files

I'm going to be a bit hazier than normal in this e-mail, for which I apologise. People who know who I work for, you can probably guess the parameters of the NDA I'm trying not to break here. On 8 January 2015 at 04:38, Benjamin Eberlei kont...@beberlei.de wrote: +1 on everything I snipped

Re: [PHP-DEV] PHP 5.5.21RC1 is ready for testing

On 8 January 2015 at 10:24, Remi Collet r...@fedoraproject.org wrote: Is this expected ? Notice the diff between (see attachement) : - - 5.4.35 and 5.4.36 show 5 changes, - - 5.5.20 and 5.521RC1 show only 2 - - 5.6.4 and 5.6.5RC1 show only 2 Since you mentioned on IRC that this seemed

Re: [PHP-DEV] Faster zend sorting implementation

On 5 January 2015 at 18:39, Xinchen Hui larue...@php.net wrote: On Tue, Jan 6, 2015 at 2:04 AM, Tim Düsterhus t...@bastelstu.be wrote: On 05.01.2015 18:08, Xinchen Hui wrote: do you think such BC break is acceptable? or I still need a RFC? : Chiming in as a pure userland developer. The

Re: [PHP-DEV] [RFC] Scalar Type Hints

On 31 December 2014 at 12:27, Andrea Faulds a...@ajf.me wrote: Parameter type hints for PHP’s scalar types are a long-requested feature for PHP. Today I am proposing an RFC which is a new attempt to add them to the language. It is my hope that we can finally get this done for PHP 7. I’d

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

On 16 December 2014 at 10:38, Stanislav Malyshev smalys...@gmail.com wrote: I've tried to search the ML for such list of RFCs: https://wiki.php.net/rfc/gc_fn_pointer https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree) https://wiki.php.net/rfc/closure_apply

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

On 16 December 2014 at 13:18, Andrea Faulds a...@ajf.me wrote: Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a year sounds like a better solution. If others agree, I might withdraw this RFC. I disagree. 2to3 wasn't a success in the Python world — in the end, the

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

On 16 December 2014 at 14:00, Zeev Suraski z...@zend.com wrote: - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, under release process that forbids that) What part of the release process forbids that? None, but I'd still advocate releasing a new minor because there's

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

On 16 December 2014 at 14:19, Zeev Suraski z...@zend.com wrote: -Original Message- From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf Of Adam Harvey Sent: Wednesday, December 17, 2014 12:10 AM To: Zeev Suraski Cc: PHP Internals Subject: Re: [PHP-DEV] [RFC] PHP 5.7

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

On 12 December 2014 at 23:19, Zeev Suraski z...@zend.com wrote: 3. Last (and probably least) - a 5.7 that breaks compatibility is inconsistent with our version strategy, that suggests 5.7 should be fully compatible with 5.6. Whoa — I'm not talking about breaking compatibility. I'm talking

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

On 15 December 2014 at 08:51, Derick Rethans der...@php.net wrote: Yes, I disagree. It's a time thing. Let's all work on one thing instead of *two*. Clearly you must see that there is not enough bandwidth? It will also prevent people from oh we can get this into 5.7 nonsense. It's not helpful,

Re: [PHP-DEV] On the road to PHP 5.7 , or not ?

On 12 December 2014 at 10:07, Levi Morrison le...@php.net wrote: Just because we are releasing PHP 7.0 next year (well, according to our timeline anyway) that doesn't mean we can't release a 5.7. Agreed. I have to apologise here — I've had a draft RFC half-written for over a week at this point

Re: [PHP-DEV] Fwd: [php-src] Constant-Time bin2hex() implementation (#909)

On 26 November 2014 at 08:49, Ferenc Kovacs tyr...@gmail.com wrote: That's a rather extreme reaction to trying to patch string operations that real-world frameworks use to handle crypto secrets, don't you think? and there are at least that much, but probably lot more usages in the wild(see

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

On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote: On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote: https://wiki.php.net/rfc/remove_php4_constructors Entirely +1 on removing them in PHP7. Did we decide on having a 5.7 release? (I was on vacation and may have

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

On 24 November 2014 at 14:21, Sara Golemon poll...@php.net wrote: On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds a...@ajf.me wrote: Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape I'm okay with producing UTF-8 even though our strings are technically binary. As you state, UTF-8 is

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

On 24 November 2014 at 14:35, Andrea Faulds a...@ajf.me wrote: On 24 Nov 2014, at 22:30, Adam Harvey ahar...@php.net wrote: I'm also OK with this, although I do wonder if we should be respecting the user's default_charset setting instead. (Since default_charset defaults to UTF-8, in practice

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

On 21 November 2014 07:36, Ferenc Kovacs tyr...@gmail.com wrote: In this case the 3 month period will be too short imo. We release RCs/betas every two weeks, so 3 months would be about 6 release. 5.6.0 had 3 alpha, 4 beta and 4 rc before release. 5.5.0 had 6 alpha, 4 beta and 3 rc before

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

My -1 is pretty much the same as Levi's: On 19 November 2014 13:57, Levi Morrison le...@php.net wrote: - The RFC does not address how this is different from FILTER_VALIDATE_* from ext/filter. I know there was a mention of this on the mailing list, but the RFC should say why a tool that

Re: [PHP-DEV] [VOTE][RFC] Safe Casting Functions

On 20 November 2014 18:06, Andrea Faulds a...@ajf.me wrote: On 21 Nov 2014, at 00:45, Adam Harvey ahar...@php.net wrote: On 19 November 2014 13:57, Levi Morrison le...@php.net wrote: - The RFC does not address how this is different from FILTER_VALIDATE_* from ext/filter. I know

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

On 11 November 2014 04:11, Robert Stoll p...@tutteli.ch wrote: I always found it very ugly that it is possible to define a use outside of a namespace. Consider the following: namespace{ //default namespace } use foo\Bar; namespace test{ new Bar(); //error, test\Bar not found } After

Re: [PHP-DEV] Currently supported versions of PHP

On 27 October 2014 18:29, Sebastian Bergmann sebast...@php.net wrote: On 10/27/2014 10:45 AM, Peter Cowburn wrote: The closest we have, at the moment, is probably http://php.net/eol.php which details the versions which are no longer supported. We need the inverse of that :) Good question.

Re: [PHP-DEV] Currently supported versions of PHP

On 28 October 2014 05:32, Stas Malyshev smalys...@sugarcrm.com wrote: The page looks good, but we've moved 5.4 to security-only on 18 Sep 2014 (5.4.33), and it'll be supported for 1 year starting that date. Good catch — I meant to put in a more generic ability to override the support dates in

Re: [PHP-DEV] Thoughts on the PHP.net website

On 25 October 2014 03:15, Rowan Collins rowan.coll...@gmail.com wrote: Daniel Ribeiro wrote on 24/10/2014 19:52: *Disclaimer: *I wanted to bring this discussion inside the internals mailing list not only because of the fact that the PHP.net website's source code on GitHub doesn't have issues

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

On 22 September 2014 04:32, Derick Rethans der...@php.net wrote: On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or

Re: [PHP-DEV] Why does checkdnsrr() default to MX??

On 19 September 2014 02:58, Chris Wright c...@daverandom.com wrote: On 18 September 2014 20:29, Kris Craig kris.cr...@gmail.com wrote: Hey guys, I just spent some time troubleshooting what appeared to be a DNS issue before I realized that, absent the optional $type argument, checkdnsrr()

Re: [PHP-DEV] Why does checkdnsrr() default to MX??

On 19 September 2014 10:51, Kris Craig kris.cr...@gmail.com wrote: On Fri, Sep 19, 2014 at 10:24 AM, Adam Harvey ahar...@php.net wrote: As an alternative, could we just make the type argument mandatory in PHP 7 and start issuing E_DEPRECATED warnings if it's omitted in 5.6 or 5.7? I like

Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator

On 16 September 2014 11:34, Andrea Faulds a...@ajf.me wrote: By popular demand, I’ve changed the RFC to instead propose a ?? operator, after Nikita Popov generously donated a working ?? patch. In doing so, the RFC is renamed “Null Coalesce Operator”. Please read it:

Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator

On 8 September 2014 07:56, Christoph Becker cmbecke...@gmx.de wrote: Am 08.09.2014 15:58, schrieb Andrea Faulds: We could add such an operator, perhaps with the ?? syntax. However, I don’t really like the idea. It’s too similar to ?: so I don’t think it’d be accepted, and even if it was, I’m

Re: [PHP-DEV] [RFC] Implicit isset() in Shorthand Ternary Operator

On 8 September 2014 17:07, Andrea Faulds a...@ajf.me wrote: On 8 Sep 2014, at 23:58, Adam Harvey ahar...@php.net wrote: +1 on ?? — there's precedent for it, and it means we don't have to explain why the shorthand form of an operator behaves differently to the long form, which is just going

Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)

On 21 August 2014 08:30, Derick Rethans der...@php.net wrote: Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to

[PHP-DEV] Re: [STANDARDS] Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single switch statement

On 6 August 2014 12:32, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Aug 6, 2014 at 8:35 PM, Sara Golemon poll...@php.net wrote: Did we agree on that? The lang spec was originally written to 5.6 to have a relatively stable target, but (in my mind at least) was meant to track master as we

Re: [PHP-DEV] [VOTE][RFC] intdiv()

-1 explanation: I don't think %% is clear enough, the only sensible syntax choice (//) is unavailable to us, and I think the utility of having it baked into the language as an operator is pretty minimal regardless (I coded a lot of Python for scientific research in a previous job, and I don't

Re: [PHP-DEV] crypt() BC issue

On 16 July 2014 23:16, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Tjerk, On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Why should `password_verify()` work on a hash that

Re: [PHP-DEV] RFC: Expectations

On 22 October 2013 02:08, Derick Rethans der...@php.net wrote: I'm pretty convinced that expectations *without* exceptions are a good idea, as using assert (which is really eval) is a nasty thing that should be replaced, but IMO exception throwing should not be part of this feature. I agree

Re: [PHP-DEV] RFC: Expectations

On 22 October 2013 10:32, Joe Watkins pthre...@pthreads.org wrote: On 10/22/2013 06:20 PM, Adam Harvey wrote: I agree that something to replace the eval-based assert() would be good. What if the new syntax simply respected assert_options(), and assert_options() was extended to support

Re: [PHP-DEV] NEWS handling

On 8 October 2013 06:46, Michael Wallner m...@php.net wrote: I was wondering how we are supposed to handle NEWS entries when a fix goes into both branches, PHP-5.4 and 5.5. IIRC we used to add the BFN only to the lowest numbered branch, but then again that was at times we had mostly onle one

Re: [PHP-DEV] Locale-independent double-to-string cast

On 2 October 2013 10:57, Christopher Jones christopher.jo...@oracle.com wrote: On 10/02/2013 10:26 AM, Nikita Popov wrote: I'd like to change our double-to-string casting behavior to be locale-independent and would appreciate some opinions as to whether you consider this feasible. I'd like

Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)

On 02.10.2013, at 10:59, Michael Wallner m...@php.net wrote: Since ever people are confused by _GET and _POST superglobals, because, despite their name, they do not (really) depend on the request method. Therefor I propose to phase out $_GET and name it $_QUERY and I propose to phase out

Re: [PHP-DEV] RFC: Anonymous Classes

On 23 September 2013 08:03, Chris Wright daveran...@php.net wrote: To summarize how I think this should be handled: Serialisation results in a stdClass, unserialisation cannot be done because if you want it you're already Doing It WrongT. To me, serialising successfully would indicate that

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

On 19 September 2013 10:52, Daniel Lowrey rdlow...@gmail.com wrote: *I consider this a bug* I understand that it's easier to code not verifying the peer, and the hostname may not be available when you are stacking ssl over a stream. But file_get_contents(https://...;) is *precisely* the

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

On 19 September 2013 17:31, Pierre Joye pierre@gmail.com wrote: On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey ahar...@php.net wrote: As for the CA bundle side of things, I wonder if this is one of those rare times where an ini setting might make sense, as opposed to actual bundling

Re: [PHP-DEV] Re: Re: PHP Crypt functions - security audit

On 19 September 2013 17:41, Pierre Joye pierre@gmail.com wrote: It does when you use curl's win32 SSL support. That makes my previous point wrong as we do not compile it with this option but openssl (for cross platform compatibility reasons). But as the curl's ca file works just fine,

Re: [PHP-DEV] [RFC] Named parameters

On 6 September 2013 09:39, Nikita Popov nikita@gmail.com wrote: The RFC and implementation are not yet complete. I mainly want to have feedback on the idea in general and on the Open Questions ( https://wiki.php.net/rfc/named_params#open_questions) in particular. Thanks for proposing this.

Re: [PHP-DEV] [RFC] Named parameters

On 6 September 2013 12:12, Dan Ackroyd dan...@basereality.com wrote: If named parameters are introduced, signature validation should include parameter names. Throwing a fatal error (for the interface/class combination) would break backwards compatibility though. We could use some lower error

Re: [PHP-DEV] [RFC] Named parameters

On 6 September 2013 13:01, Dan Ackroyd dan...@basereality.com wrote: I'd say the odds are that those sorts of users are going to be writing code that is required to be notice/strict clean anyway — that's certainly been true everywhere I've worked that's had a modern codebase. Yes, so say

Re: [PHP-DEV] [RFC] Argument unpacking

On 31 August 2013 03:21, Nikita Popov nikita@gmail.com wrote: This is very special use case to be hidden in library functions, I don't think we need to have language syntax specially directed at that, at the cost of making it overall more complex and hard to understand. I can see what add

Re: [PHP-DEV] [RFC] Argument unpacking

On 30 August 2013 08:23, Nikita Popov nikita@gmail.com wrote: The syntax it introduces looks as follows: $db-query($query, ...$params); Somebody was going to do this, and it's going to be me. Sorry. We were doing so well. I don't like the ellipsis. I could just about deal with it for

Re: [PHP-DEV] Operator precedence is undefined?

(Piggy-backing on Sara's e-mail, although this is more a response to Sherif and Yasuo.) On 19 July 2013 22:33, Sara Golemon poll...@php.net wrote: I never said that the compiler might magically produce differing results for the same input. I said that the language's definition does not declare

[PHP-DEV] Re: [PHP-DOC] Re: OPCache documentation

On 20 June 2013 14:36, Julien Pauli jpa...@php.net wrote: On Wed, May 15, 2013 at 3:54 PM, Julien Pauli jpa...@php.net wrote: Hi all, As you know, 5.5 final is coming soon. We are in RC, so mainly stabilizing stuff and preparing the final release for anyone to setup 5.5 on their servers.

Re: [PHP-DEV] Proposal for better UTF-8 handling

On 26 May 2013 21:05, Stas Malyshev smalys...@sugarcrm.com wrote: I agree with Nikita — I'm not against adding more Unicode/charset handling functions if they make sense (and I haven't looked at the code for this particular proposal yet), particularly if they'd be part of a default build, but

Re: [PHP-DEV] Proposal for better UTF-8 handling

On 24 May 2013 08:26, Ferenc Kovacs tyr...@gmail.com wrote: On Fri, May 24, 2013 at 3:09 PM, Nikita Popov nikita@gmail.com wrote: We already have a lot of functions for multibyte string handling. Let me list a few: * The str* functions. Most of them are safe for usage with UTF8.

Re: [PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2

On 23 May 2013 13:31, Nikita Popov nikita@gmail.com wrote: On Sat, May 18, 2013 at 11:48 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5. Once in the hash extension, once in the OpenSSL extension. The

Re: [PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2

On 23 May 2013 14:11, Nikita Popov nikita@gmail.com wrote: If a bug is found we fix it. Proving several implementations of the same thing to account for potential bugs isn't a good idea imho. It's not a very good example, I admit, but my point is that it's not as though they're actually the

Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e

On 23 May 2013 17:14, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! the code does throw new, it is always useful. So how you would propose to solve this? rethrow $e; Yes, this is definitely an option, but requires a new keyword. We could use a C++ style throw; as an implicit rethrow.

Re: [PHP-DEV] idea: implement a Comparable interface

On 7 May 2013 09:17, Thomas Anderson zeln...@gmail.com wrote: It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. I wrote https://wiki.php.net/rfc/comparable a couple of years ago — there's a patch there

Re: [PHP-DEV] idea: letting the line number and file name be set via user_error

On 7 May 2013 12:24, Thomas Anderson zeln...@gmail.com wrote: I thought half the point of OOP was to abstract away the internals and as is the error messages don't make much sense unless you *do* consider the internals. Like let's say you have a bignum library and you're doing

  1   2   3   >