On 5 February 2015 at 13:06, Yasuo Ohgaki 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 RFC. I'l
On 6 February 2015 at 04:14, Andrea Faulds 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 noise, but I
On 11 February 2015 at 06:59, Paul Dragoonis wrote:
> On Mon, Feb 9, 2015 at 10:29 PM, Anatol Belski
> wrote:
>> ext/mssql 17:13
>
> Did you accidentally miss out mssql? it resultes in significant resistance
> to leave core, such as mcrypt and ignoring mathematical numbers, from a
>
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: https:
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 wrote:
> Another issue: it allows comparing an object to non-objects (even
> though the stated goal is only to compare two objects
On 19 February 2015 at 01:09, Joe Watkins 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 awesome, particularly the
On 20 February 2015 at 04:54, Niklas Keller 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
March 15 to be
(Please don't top post!)
On 20 February 2015 at 11:31, François Laupretre 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, as RFC i
On 16 January 2015 at 09:16, Nikita Popov 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 the ereg front in
On 5 March 2015 at 05:39, Jan Ehrhardt 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:
>
> http://git.php.net/?p=pecl/text/ereg.git;a=blob;f=
On 5 March 2015 at 12:21, Pierre Joye 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 and mysql: it would
On 11 March 2015 at 14:28, Bob Weinand 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:
>
> https://wiki.php.net/rfc/basic_sc
On 2 April 2015 at 12:24, Dan Ackroyd wrote:
> On 2 April 2015 at 16:01, Keyur Govande 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 fairly easy to refactor the thre
On 8 April 2015 at 08:16, Anthony Ferrara 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 zend_string req
On 28 April 2015 at 15:10, Patrick ALLAERT wrote:
> Le mar. 28 avr. 2015 à 20:42, Kalle Sommer Nielsen 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
>> with userland, but as currently
On 22 June 2015 at 14:10, Stanislav Malyshev 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 release
On 22 June 2015 at 16:05, Ángel González 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 override, but
On 23 July 2015 at 11:47, Christoph Becker wrote:
> 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, although it's at least in the spirit of
what
On 11 August 2015 at 09:46, Christoph Becker 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?
CentOS/RHEL 5 provi
On 13 August 2015 at 04:35, Christoph Becker 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 all the
On 19 August 2015 at 07:20, Björn Larsson 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 this is an oversight
(Resurrecting a very old thread. Sorry about the thread necromancy.)
On 8 September 2011 05:20, Rasmus Lerdorf wrote:
> On 09/07/2011 02:12 PM, Stas Malyshev wrote:
>> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up
>> itimer implementation at least up to kernel 10.8.0, Ma
On 3 February 2012 12:05, Stas Malyshev wrote:
>> For me at least, tests/func/005a.phpt is the last failing test on
>> PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
>> pre-5.4.0 to help get cleaner test suite results.
>
>
> I really wouldn't want to hold the release for an
On 6 February 2012 04:37, Tom Boutell wrote:
> Deprecate and then remove, or just leave it in. "Make it optional
> forever" just generates more nonportable PHP code. Ick.
Huge +1 to that.
Given the existence of preg_replace_callback() (as Stas noted above),
my preference is for deprecation and t
On 3 February 2012 12:15, Adam Harvey wrote:
> On 3 February 2012 12:05, Stas Malyshev wrote:
>>> For me at least, tests/func/005a.phpt is the last failing test on
>>> PHP_5_4 on my OS X machine, so it would be nice to get this cleared up
>>> pre-5.4.0 to help
On 8 February 2012 04:09, Stas Malyshev wrote:
>> Specifically, how about the attached patch (also available at
>> http://www.adamharvey.name/patches/osx-max_execution_time-test-patch.diff,
>> in case the mailing list decides to strip it)? This only patches the
>> test to XFAIL this test on OS X,
On 17 February 2012 18:54, Ondřej Surý wrote:
> Little nag (with patch) to not forget to update 5.3.11 changelog with
> 5.3.10 changes.
The patch doesn't appear to have made it, but I've merged the 5.3.10
NEWS into the PHP_5_3 NEWS. Thanks for the reminder. :)
Adam
--
PHP Internals - PHP Runtim
On 25 February 2012 04:02, Gustavo Lopes wrote:
> On Fri, 24 Feb 2012 20:57:50 +0100, Stas Malyshev
> wrote:
>
>>> If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be
>>> included? This would reduce any negative user sentiment that "PHP 5.4
>>> doesn't even support the latest
Hi all,
Google are running the Summer of Code again this year, and Dan Brown
and I have tentatively agreed to act as organisation administrators if
we can get an application together. We have a week from today to
apply, but before we can, we need updated ideas. Our old ideas list is
at https://wik
On 2 March 2012 10:00, Adam Harvey wrote:
> Google are running the Summer of Code again this year, and Dan Brown
> and I have tentatively agreed to act as organisation administrators if
> we can get an application together. We have a week from today to
> apply, but before we can, we
On 2 March 2012 09:56, Philip Olson wrote:
> Please clarify whether or not get_magic_quotes_gpc() and
> get_magic_quotes_runtime()
> are deprecated, because I do not think they are. Deprecated means people
> should not
> use them while writing new code, but they are perfectly sensible functions.
On 2 March 2012 21:05, Gustavo Lopes wrote:
> Fair enough. Option #1 seems the most appropriate then. The others seem too
> drastic to implement with such short notice.
+1. We can't drop bug fixes immediately without warning, and I don't
think the overhead of backporting security fixes is too one
On 2 March 2012 21:34, Simon Schick wrote:
> One or two years is way to short if you'd ask me. A major release should be
> supported with all kind of bug fixes for min. 3 years after a new release
> has been brought out. Specially if it's a wide-spread language like PHP that
> has been implemented
On 9 March 2012 00:11, Remi Collet wrote:
> Le 08/03/2012 09:03, Michael Wallner a écrit :
>> Sorry for the delay, but I already explained the issue in
>> the bug report: https://bugs.php.net/bug.php?id=61291
>
> Thanks, for the explanation.
I'm still concerned about the idea that the output of a
On 27 March 2012 09:55, Yasuo Ohgaki wrote:
> http://www.php.net/mailing-lists.php
>
> At the bottom of this page, http://www.ezmlm.org/ is refereed.
> However, it seems this domain is dead.
It looks like the domain has expired. Along with probably ten thousand
other people, I'll ping djb (off-
On 3 April 2012 09:46, Rasmus Lerdorf wrote:
> On 04/02/2012 06:35 PM, Charlie Somerville wrote:
>> I've created a pull request (https://github.com/php/php-src/pull/33) that
>> changes json_encode to fall back to ASCII for strings that are not valid
>> UTF-8.
>>
>> I ran into an issue in a produ
On 4 April 2012 10:02, Alan Knowles wrote:
> PHP enforces rules like $this can not be used in a method marked 'static'.
> So why not flag methods (and internal functions) with a flag that indicates
> they can throw things. Since PHP is not a compiled language we can not pick
> up 'all' of the pote
On 10 April 2012 15:30, Yasuo Ohgaki wrote:
> "allow_url_include" and "template_mode" is similar to me.
>
> allow_url_include: enable only when url include is needed.
> template_mode: enable only when template mode is needed.
>
> allow_url_include prevents RFI which may result in critical sec
On 17 April 2012 11:42, wrote:
> Just b/c there are rarely any women at all that participate on this list,
> could we at list maintain a facade of gender neutrality? I seriously can't
> believe that you used the word "him". What about "her"? Yeah, "her" as in
> myself and every other woman
On 18 April 2012 06:40, Kris Craig wrote:
> Forgive me if this has been addressed before, but I was wondering: Have we
> ever considered maintaining an RPM for PHP dependencies for each version
> branch? The are legitimate reasons why people prefer to build PHP manually
> instead of building fro
On 18 April 2012 06:54, Stas Malyshev wrote:
> create_query("deleted=0", "name",,, /*report_errors*/ true);
I like it. At the risk of bikeshedding, can we have a token rather
than just a series of commas — say reusing the default keyword so it
would look like this instead:
create_query("deleted=
Account granting folks,
On 30 July 2012 10:01, Brandon Sky wrote:
> I am Brandon Sky Pimenta. I want to have a PHP development account because I
> want to:
* Maintain and translate php.net and PHP's
> documentation
* Become more advanced with PHP's bugs
> and feature
On 30 July 2012 16:02, Lester Caine wrote:
> Moving people from 5.2 is probably going to be as bad as killing off PHP4
> and 4.6% of sites are still using that! But the main problem starting to
> happen now is that developers are upgrading projects to use 5.3 and 5.4
> features, but simply assumin
On 2 August 2012 12:30, Kris Craig wrote:
> First we'll need to consolidate the information regarding when each version
> was EOL'd. Are they all in news announcements, or are they scattered
> between announcements, listserv threads, etc? If we're going to do this,
> we may as well cover as many
On 2 August 2012 13:00, Adam Harvey wrote:
> On 2 August 2012 12:30, Kris Craig wrote:
>> First we'll need to consolidate the information regarding when each version
>> was EOL'd. Are they all in news announcements, or are they scattered
>> between announceme
On 2 August 2012 15:56, Peter Cowburn wrote:
> On 2 August 2012 07:35, Adam Harvey wrote:
>> Thoughts? (Do we even want to auto-fill this from $OLDRELEASES, or
>> would we rather have a manual array?) Specific notes on
>> vulnerabilities to add to branches? Better versio
On 2 August 2012 16:51, Morgan L. Owens wrote:
> On 2012-08-02 20:42, Peter Cowburn wrote:
>> The details on things being "obsoleted" should be in the migration guides.
>>
> Then that would be where the links go, in a similar manner to the Changelog
> links.
I've added links to the migration guid
On 2 August 2012 16:58, Adam Harvey wrote:
> On 2 August 2012 16:51, Morgan L. Owens wrote:
>> On 2012-08-02 20:42, Peter Cowburn wrote:
>>> The details on things being "obsoleted" should be in the migration guides.
>>>
>> Then that would be whe
On 15 August 2012 18:15, Nikita Popov wrote:
> As already pointed out repeatedly, argument typehints serve the
> purpose of defining an interface. No, they are not required to run the
> code, that's true. But they still serve an important purpose for
> object oriented programming (and, just to mak
On 3 September 2012 17:36, Andrew Faulds wrote:
> Ryan McCue wrote:
>>What about ISO8601 with the Olson timezone suffixed?
>>
>>2012-09-02T18:17:36+0100 (Europe/London)
>>2012-09-02T18:19:05+0100 (Africa/Niamey)
>>
>
> Sounds good.
If we're going to invent arbitrary non-standard formats,
On 3 September 2012 19:54, Will Fitch wrote:
> On Mon, Sep 3, 2012 at 5:45 AM, Adam Harvey wrote:
>> I just don't see how we can choose a sensible default format for
>> users. Sometimes you want ISO 8601. Sometimes you want whatever your
>> locale's customary dat
--enable-zend-multibyte: just output the BOM to stdout without any
special handling. It's entirely possible that I've just missed a
Unicode-related option there, though.
Adam
[1] http://bugs.php.net/bug.php?id=22108
--
Adam HarveyPEAR Profile: <htt
I'm a developer on pear/Auth and pear/Config.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2 October 2013 10:57, Christopher Jones 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 to see float/double c
> On 02.10.2013, at 10:59, Michael Wallner 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 $_POS
On 8 October 2013 06:46, Michael Wallner 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 stable rel
On 22 October 2013 02:08, Derick Rethans 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 that somethi
On 22 October 2013 10:32, Joe Watkins 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 t
On 16 July 2014 23:16, Tjerk Meesters wrote:
> On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
>
>> Hi Tjerk,
>>
>> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters > > wrote:
>>
>>> Why should `password_verify()` work on a hash that wasn't generated with
>>> `password_hash()`? The fact tha
-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 think
On 6 August 2014 12:32, Ferenc Kovacs wrote:
> On Wed, Aug 6, 2014 at 8:35 PM, Sara Golemon 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 move the language forwa
On 21 August 2014 08:30, Derick Rethans 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 do so. Chang
On 8 September 2014 07:56, Christoph Becker 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 not sure we
On 8 September 2014 17:07, Andrea Faulds wrote:
>
> On 8 Sep 2014, at 23:58, Adam Harvey 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,
On 16 September 2014 11:34, Andrea Faulds 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: https://wiki.php.net/rfc/isset_
On 19 September 2014 02:58, Chris Wright wrote:
> On 18 September 2014 20:29, Kris Craig 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()
>> defaults to "MX". Can anybody e
On 19 September 2014 10:51, Kris Craig wrote:
> On Fri, Sep 19, 2014 at 10:24 AM, Adam Harvey 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 l
On 22 September 2014 04:32, Derick Rethans 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 anything els
On 25 October 2014 03:15, Rowan Collins 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 enabled, but
On 27 October 2014 18:29, Sebastian Bergmann 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.
>
> Sho
On 28 October 2014 05:32, Stas Malyshev 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 include/branches.inc,
On 11 November 2014 04:11, Robert Stoll 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 }
>>
My -1 is pretty much the same as Levi's:
On 19 November 2014 13:57, Levi Morrison 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 already
> exists
On 20 November 2014 18:06, Andrea Faulds wrote:
>
>> On 21 Nov 2014, at 00:45, Adam Harvey wrote:
>>
>> On 19 November 2014 13:57, Levi Morrison wrote:
>>> - The RFC does not address how this is different from
>>> FILTER_VALIDATE_* from ext/filter. I know
On 21 November 2014 07:36, Ferenc Kovacs 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 release.
> 5.4.0 h
On 24 November 2014 at 14:21, Sara Golemon wrote:
> On Mon, Nov 24, 2014 at 2:09 PM, Andrea Faulds 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 the de-facto encoding
On 24 November 2014 at 14:35, Andrea Faulds wrote:
>
>> On 24 Nov 2014, at 22:30, Adam Harvey 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
On 25 November 2014 at 10:36, Sara Golemon wrote:
> On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison 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
> missed this) If so
On 26 November 2014 at 08:49, Ferenc Kovacs 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 https://git
On 12 December 2014 at 10:07, Levi Morrison 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 that would
On 12 December 2014 at 23:19, Zeev Suraski 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 about
generati
On 15 December 2014 at 08:51, Derick Rethans 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, and it *
On 15 December 2014 at 16:09, Andrea Faulds wrote:
> The RFC can be found here: https://wiki.php.net/rfc/php57
Thanks for the taking the initiative on this.
On timing: I think we should release 5.7 in August (12 months after
5.6), rather than lining it up with 7.0. This gives us the opportunity
On 16 December 2014 at 10:38, Stanislav Malyshev 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
>> https://wiki.php.net/rfc/pa
On 16 December 2014 at 13:18, Andrea Faulds 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 only mig
On 16 December 2014 at 14:00, Zeev Suraski 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
plenty of a
On 16 December 2014 at 14:19, Zeev Suraski 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
>
On 31 December 2014 at 12:27, Andrea Faulds 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 like to th
On 5 January 2015 at 18:39, Xinchen Hui wrote:
> On Tue, Jan 6, 2015 at 2:04 AM, Tim Düsterhus 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 documentation already
(cross-posting to php-webmaster as well)
On 7 January 2015 at 04:52, Scott Arciszewski wrote:
> Would it be possible for php.net to publish a cryptographically signed
> (e.g. openssl_sign() with a RSA private key kept offline) list in a
> pre-defined location (e.g. /stable_versions.txt) so that s
On 8 January 2015 at 01:39, Markus Fischer 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 systems th
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 wrote:
<+1 on everything I snipped>
> Examples of good use-ca
On 8 January 2015 at 10:24, Remi Collet 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 inconsistent, I add
On 14 January 2015 at 11:15, Marc Bennewitz 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?
That was in
On 15 January 2015 at 17:35, Pierre Joye wrote:
>
> On Nov 26, 2014 1:39 AM, "Adam Harvey" wrote:
>>
>> On 25 November 2014 at 10:36, Sara Golemon wrote:
>> > On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison wrote:
>> >> https://wiki.php.net/rfc/r
On 17 January 2015 at 18:04, Andrea Faulds 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 "de
On 20 January 2015 at 07:09, Kristopher 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
> change be made, regardless o
On 20 January 2015 at 12:54, Marc Bennewitz 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 "parent::sta
On 22 January 2015 at 00:56, Benjamin Eberlei wrote:
> On Wed, Jan 7, 2015 at 8:33 PM, Benjamin Eberlei
> wrote:
>
>> Hello everyone,
>>
>> After discussion I am putting the RFC on turning gc_collect_cycles into a
>> function pointer to vote:
>>
>> https://wiki.php.net/rfc/gc_fn_pointer
>>
>> Vot
On 3 February 2015 at 03:11, Anatol Belski 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 and ext/mcrypt: whil
1 - 100 of 238 matches
Mail list logo
