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 properties as part of their p
On 25 February 2016 at 14:19, Dan Ackroyd wrote:
> On 25 February 2016 at 18:16, Adam Harvey wrote:
>>
>> am I right
>> that this is equivalent to the following?
>>
>>$injector->delegate('FooInterface', function (...$args) { return new
> FooImpl
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
> constant).
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 with Auryn beyond glanci
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 entirely (as I also said l
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
> to do that :)
One
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!
> Let me know what you
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
>> closing a waiting-on-submitter PR. 2 w
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
> to fix since it came down to
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:
https://github.com/php/web-php/commit/4ec6
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 (which I don't think is the case) -
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 variations on what express
On 9 November 2015 at 13:46, Derick Rethans wrote:
> On Thu, 5 Nov 2015, Niklas Keller wrote:
>
>> I discovered today that anonymous class names contain a null byte
>> right after "class@anonymous". I don't think class names should
>> contain non-printable characters.
>>
>> How about removing that
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
> accurate.
I voted -1 for t
(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' instead in
> C
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 have
>> had its day soon anyway. So IM
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:
> http://git.php.net/?p=php-src.
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
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 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 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 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 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 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 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 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 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 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 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 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
(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 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
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
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
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:
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
>
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 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 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
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 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 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 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 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 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 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
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 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
(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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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 }
>>
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 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 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 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 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 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 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 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 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 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 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
-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 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
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 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 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 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 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 23 September 2013 08:03, Chris Wright 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 PHP could
unser
On 19 September 2013 17:41, Pierre Joye 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, everything is good.
>
On 19 September 2013 17:31, Pierre Joye wrote:
> On Thu, Sep 19, 2013 at 2:41 PM, Adam Harvey 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 — that would a
On 19 September 2013 10:52, Daniel Lowrey 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 case that
On 6 September 2013 13:01, Dan Ackroyd 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 you have a t
On 6 September 2013 12:12, Dan Ackroyd 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
>> type...
>
> Wo
On 6 September 2013 09:39, Nikita Popov 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. I haven't looked
On 30 August 2013 08:23, Nikita Popov 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 the
variadic RFC,
On 31 August 2013 03:21, Nikita Popov 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 all those pa
On 22 August 2013 05:10, Tjerk Meesters wrote:
> On 22 Aug, 2013, at 6:58 PM, Yasuo Ohgaki wrote:
>> I realized that not many users are using "more entropy" parameter
>> Therefore, I made
>>
>> Request #65501 uniqid(): More entropy parameter should be true by default
>> https://bugs.php.net/bug.p
(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 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
> a defined b
On 20 June 2013 14:36, Julien Pauli wrote:
> On Wed, May 15, 2013 at 3:54 PM, Julien Pauli 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.
>>
>> I see the do
On 26 May 2013 21:05, Stas Malyshev 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 enough water
On 24 May 2013 08:26, Ferenc Kovacs wrote:
> On Fri, May 24, 2013 at 3:09 PM, Nikita Popov 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.
>> Exceptions are basically everythi
On 23 May 2013 17:14, Stas Malyshev 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.
Adam
1 - 100 of 238 matches
Mail list logo
