Re: [PHP-DEV] Allow dropping typehints during inheritance

On 5 February 2015 at 21:52, Levi Morrison wrote: > To chime in regarding allowing contravariant parameter types: I > struggle to find use cases for it. Theoretically it would allow a class to implement two separate interfaces that would otherwise be incompatible: interface A { function foo(

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

As much as I want scalar types I'm voting no as: i) Having this code: function foo(int $numberOfRightTurns) { $x = $numberOfRightTurns * 90; return sin(deg2rad($x)) } work or blow up depending on a setting at the top of the file is horrible. ii) Having the code that I write in userland

Re: [PHP-DEV] Annotated PHP 5->7 extension diff

On 5 February 2015 at 22:28, Rasmus Lerdorf wrote: > Any suggestions for how to handle annotating it? We could turn it into a > fake PR and mark it up using github's PR comments. I think that's a good idea. It is very easy for people to ask questions about any change that they don't understand on

Re: [PHP-DEV] Pointers to understanding code base

Lester, If you are having issues with Imagick please report them here: https://github.com/mkoppanen/imagick Not only is that the right place to report issues with unreleased versions of Imagick, but also I tend to monitor issues there more closely than I do a mailing list. > This one of the few

Re: [PHP-DEV] Reviving scalar type hints

On 16 February 2015 at 22:50, François Laupretre wrote: > it is clear that we don't have consensus on this topic. So, IMO, the RFC is > dead, whatever 2/3 or 3/4 we may have. It's okay for people to disagree about things. And we have voting to allow us to resolve those disagreements. Claiming

Re: [PHP-DEV] Reviving scalar type hints

On 17 February 2015 at 00:22, Nikita Popov wrote: > > Thank you for taking over. > > I like "use strict" and "declare as top-level only" most. That would be this no vote changed to a yes. And I'd also like to say thank you Sara for taking over. cheers Dan -- PHP Internals - PHP Runtime Develo

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

On 13 February 2015 at 23:25, Nikita Popov wrote: > Subclassing: Should there be more specific subclasses of EngineException > for particular errors? It's not obvious that any subclasses would be useful. However using the code to specify the exact type of error, rather than having to inspect the

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

On 19 February 2015 at 09:54, Dmitry Stogov wrote: > I think we may introduce the following hierarchy > the existing code that caught Exception is going to be unaffected. We could do that. But it's not obviously correct, and ought to be justified as to why it would be the correct thing to do. T

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

On 19 February 2015 at 15:46, Dmitry Stogov wrote: > Exception declares protected properties that may be used in child classes > directly. > This is not possible with interface. So, you're saying it's easier to implement? That isn't a fantastic way of making a language design decision. cheers D

Re: [PHP-DEV] Re: [RFC] Exceptions in the engine

On 19 February 2015 at 16:25, Dmitry Stogov wrote: > > we are tying to > do it with minimal breaks for our users. If we may keep compatibility, we > would prefer to keep it, Yeah - you still haven't said why choosing to extend exception rather than using an interface has fewer BC problems. > We

Re: [PHP-DEV] [RFC][Discussion] In Operator

On 20 February 2015 at 12:54, Niklas Keller wrote: > Hi internals, > > It would really make sense to vote on this RFC after there has been a > vote on https://wiki.php.net/rfc/context_sensitive_lexer. That is an understatement: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Qu

Re: [PHP-DEV] [RFC] Make empty() a Variadic

On 21 February 2015 at 07:20, Markus Fischer wrote: > On 21.02.15 06:11, Thomas Punt wrote: > From the RFC: >> Also, it will make empty() more inline with the not-too-disimillar isset(), > > Here I disagree. > > I would have assumed from the start that empty() would only return true > if *all* of

Re: [PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require

>From the RFC: > Patches and Tests > Will be prepared before vote. The implementation details may determine how some people vote. Is the patch still coming before the voting is opened? cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/u

Re: [PHP-DEV] [RFC] Script only include/require

On 25 February 2015 at 00:09, Pádraic Brady wrote: > > Your example omitted the image validation step which would have > noticed your attempt to upload a phar immediately. Add that and try > again. Image validation is no defense against this type of attack: http://php.webtutor.pl/en/2011/05/13/p

Re: [PHP-DEV] A different user perspective on scalar type declarations

On 26 February 2015 at 17:48, Zeev Suraski wrote: >> From: Theodore Brown [mailto:theodor...@outlook.com] >> 2. Strict types are important in some cases. >> >> I would *want* any value with the wrong type (even a string like > "26") >> to be flagged as an error when passed to a function expecting

[PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

Hi Internals, This email is to announce the formal opening of discussion for an RFC to clean up the behaviour of the constructors shown by several internal classes. https://wiki.php.net/rfc/internal_constructor_behaviour For reference this was discussed before https://marc.info/?l=php-internals&

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

On 1 March 2015 at 18:35, Marc Bennewitz wrote: > What are the reasons to not make this class instantiable / extendable ? That class handles database state / resources that are not exposed through the userland classes. It's correct in my opinion for it to not be extendible or instantiable. Obviou

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

On 1 March 2015 at 22:05, Stanislav Malyshev wrote: > I'm not sure why this RFC assumes the exception is much better than > returning null. > > It is a long standing tradition in PHP that operations that can be > expected to fail - like fopen().. do not produce > fatal errors but instead return

Re: [PHP-DEV] Question/comment about the Array to String conversion RFC

On 2 March 2015 at 14:24, Zeev Suraski wrote: > https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates > from our guidelines of deprecating features first, and removing them > later; > > Should we not go through this deprecation cycle, even if may feel anxious > to get rid of thi

Re: [PHP-DEV] [VOTE] Exceptions in the engine

On 9 March 2015 at 11:04, David Zuelke wrote: > Why not wait with the merge until a consensus emerges regarding Throwable? The patch for engine exceptions is large - the longer that it is left unmerged, the more difficult it will be to do and people's time is valuable. It also delays finding bugs

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

On 11 March 2015 at 16:45, Zeev Suraski wrote: > I think that going through a transition period ... that ultimately results > in one, consistent language behavior This RFC is explicitly saying that there is stuff that will be need to be changed in the future. Why would anyone upgrade from PHP 5.6

Re: [PHP-DEV] Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count")

On 10 March 2015 at 15:02, Anthony Ferrara wrote: > > Can we please come down to a single RFC, with a single vote yes/no? > It's easier to understand, easier to manage and has less possibility > of gaming. While I generally agree, in the case where there is a small detail that needs to be addres

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

Voting no due to: i) Having conversion rules be difference in userland to internal functions. You list 'Single Mode' as a benefit of this RFC, but it's only single mode if you gloss over this difference. This is a massive cognitive load, and will be one of those issues that catches users out agai

Re: [PHP-DEV] [VOTE] Make empty() a Variadic

On 12 March 2015 at 09:58, Thomas Punt wrote: > Hey PHP Internals, > I'm not entirely sure why > people are against it - and no one seems to want to debate it either. I think these were covered in the discussion phase, but I will reiterate the reasons I voted against it for clarity. > The falsy

Re: [PHP-DEV] Safe execution timeout handling

On 11 March 2015 at 21:44, Dmitry Stogov wrote: > Hi, > > Improvement ideas are welcome... Hi Dmitry, The idea was raised before of having both soft and hard limits for the memory consumption and time limits, and to trigger a user defined callback when the soft limit was reached. This would be

Re: [PHP-DEV] static constructor

Patrick Schaaf wrote: > But that has proven, in the past, a fountain of joy wrt. > placement, with variations needed for APC and opcache, and general frustration > all around. Is there a bug report for the problems? OPCache shouldn't have side-effects on the code. cheers Dan On 12 March 2015 a

Re: [PHP-DEV] A plea for unity on scalar types

On 14 March 2015 at 15:05, Lester Caine wrote: > Just what is being added which PHP5 will actually baulk at? > The code base I will be running myself with PHP7 is PHP5.4 with E_STRICT > etc. clean code. For the RFC https://wiki.php.net/rfc/scalar_type_hints_v5 that is on the edge of passing ther

Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls

On 15 March 2015 at 06:59, Marcio Almada wrote: > Hi, > > I received some requests to update the RFC with more information about BC > breaks + possible minor adjustments regarding dynamic function calls. Please can you stop abusing the RFC process? This RFC is attempting to change the language.

Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator

On 15 March 2015 at 00:54, Niklas Keller wrote: > Morning, > > I'd like to announce that I'll open the vote for the in operator later that > day. > You can find the RFC here: https://wiki.php.net/rfc/in_operator We've discussed this elsewhere and the RFC is still lacking one thing - any justific

[PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes

Hi List, The 'Constructor behaviour of internal classes' RFC is now in voting. Please note, it's the coding standard that is being voted on. If anyone thinks I've implemented the changes in a way that is less awesome then there is no reason the changes couldn't be improved. Additionally, while wr

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

Hi Zeev, On 11 March 2015 at 18:48, Zeev Suraski wrote: > Rest assured that if I see that they both seem to be failing as we near the > end of the voting time, I'll retract the Coercive STH RFC - and I'll > actually vote in favor of the dual mode RFC, People sometimes tell me that they think th

Re: [PHP-DEV] [RFC][VOTE] In Operator

Hi Niklas, To reiterate and explain my no vote: The RFC is still lacking one thing - any justification of why this deserves being a new piece of syntax, rather than just being a function implemented either internally, or even better in userland PHP. The equation is not just "will PHP be better

Re: [PHP-DEV] About declare(strict_types = 1)

On 16 March 2015 at 09:05, Xinchen Hui wrote: > Hey: > I don't like strict_types at all.. > And you would never be forced to use them. But you're voting against allowing anyone else to use them. :-( cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http

Re: [PHP-DEV] About declare(strict_types = 1)

On 16 March 2015 at 11:49, Pavel Kouřil wrote: >>> > > Seriously, think about it for a while - when some setting that changes > how code behaves was a good idea? The problem is that there are two irreconcilable camps - some people want weak STHs, other people want strict STHs. This RFC gives bo

Re: [PHP-DEV][RFC][VOTE][RESTART] Strict Argument Count On Function Calls

On 16 March 2015 at 02:31, Marcio Almada wrote: > There was no need to update the BC break section. The only minor change was > the addition of the following section: > Yeah, really strong -1 on this one, even after the modification. Now that the RFC only covers static calling, all of the code i

Re: [PHP-DEV][RFC][VOTE] Strict Argument Count On Function Calls

On 15 March 2015 at 19:19, Marcio Almada wrote: > Hi >> It's also going to be impossible for people to try the patch out, or >> to measure it for performance hit. >> > > Performance has never been an issue with this RFC. You probably meant "bc > break" not "performance hit", and the suggested chan

Re: [PHP-DEV] Dual Mode STH

Thank you Zeev. On 16 March 2015 at 14:35, Xinchen Hui wrote: > Unecessary for everybody, one or two change from no to yes will make it pass. > :) Although not necessary, it would reduce the level of drama, which would be a good thing. cheers Dan -- PHP Internals - PHP Runtime Development M

Re: [PHP-DEV] [VOTE] Reserve even more type hints

On 16 March 2015 at 06:44, Sara Golemon wrote: > The voting period for the "Even More" type hints reservation RFC is now open. > Hi Sara, There's been a little bit of traffic on the list in the past few days; I don't think your RFC has received enough cogent discussion. In particular the keywor

Re: [PHP-DEV] Vote process change proposal

I dislike the lobbying, and think some of the allgeged abusive back-channel communications are wildly out of order, but I would be against this change. There have been a couple of instances in the past few weeks where someone has voted in a particular way. When asked why they voted like that, the

Re: [PHP-DEV] Question/comment about the Array to String conversion RFC

On 19 March 2015 at 17:14, François Laupretre wrote: > As you may have noticed if you had a look at the RFC or twitter, I have > decided to follow people's suggestion. > Please note that the switch from E_DEPRECATED to fatal error won't require > any new RFC/discussion/vote > as the fatal erro

Re: [PHP-DEV] Question/comment about the Array to String conversion RFC

Hi Zeev, On 19 March 2015 at 17:49, Zeev Suraski wrote: > Technically, we're not allowed to move from from a working feature into a > removed one without a deprecation phase. Please can you point me to where this is written down? Please also show me where it says that this rule cannot be over-r

Re: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?

On 19 March 2015 at 20:26, Eric Stenson wrote: > PHP Internals folks-- > > We're doing some performance work in WinCache, and we're finding that some > frameworks > are...uh...enthusiastically using file_exists(), is_file() and is_dir() > functions on > files/directories that don't exist. Every

Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes

On 26 March 2015 at 20:19, Dmitry Stogov wrote: Hi Dmitry, > however the patch looks a bit surprising to me. > We have special function to do this - zend_ctor_make_null() and some tricks > in the VM. > I made just a quick look over your patch but didn't find any references to > them. Surprisin

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

On 29 March 2015 at 12:28, Gints Murans wrote: > What happened to this RFC? This is a really great idea for php. The 'Skip Params' RFC (https://wiki.php.net/rfc/skipparams) went to vote and was declined. The 'named params' RFC (https://wiki.php.net/rfc/named_params) author has been working on st

[PHP-DEV] [RFC][ACCEPTED] Constructor behaviour of internal classes

This was approved by a vote of 32 - 1. Dmitry said that he would like to review and possibly polish the patch before it is committed. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes

Hi Dmitry, Your approach is definitely a better one, and I have no objection to it whatsoever. Sorry, I was too busy to look deeply at each class but I can't see any problems. Nikita Popov wrote: > does that mean that the same code using strict_types=1 mode will start > throwing TypeException in

Re: [PHP-DEV] Backwards compatibility with set_exception_handler callback and type hints

Hi James, On 31 March 2015 at 21:51, James Gilliland wrote: > By design, \EngineException does not extend \Exception so code doesn't > accidentally catch this special type of exception. ... > > I don't know if this is all acceptable and/or by design but it is awkward > so I wanted to bring it to

[PHP-DEV] Deprecate setlocale?

Hi, I'd like to get people's feedback for the idea of making setlocale be either deprecated and to be removed eventually or just increasing the warning level against people using it. The short version of why we should do this is that setlocale breaks things. It is a process wide operation, that i

Re: [PHP-DEV] Deprecate setlocale?

On 1 April 2015 at 18:27, Marc Bennewitz wrote: > > Functionality not related to locale should not be effected by this global This is issue is that that the locale affects all of the C library that use it, which includes printf(); > -> The following bug reports are valid bugs and should be res

Re: [PHP-DEV] Deprecate setlocale?

On 1 April 2015 at 18:58, Stanislav Malyshev wrote: > Hi! Stanislav Malyshev wrote: > Library should not assume it runs in C locale, Because it is not thread-safe, it is not safe for libraries to alter the locale. I can't see any workaround to make this 'just work' - when printf cannot be relie

Re: [PHP-DEV] PHP 5.5.24RC1 is available for testing

Hi Julien, I am unsure of the timing windows for things being committed to being in a release, but it seems unfortunate to not have this included: https://github.com/php/php-src/commit/86f983bd3ea13def42e36842e03f785d02d40a7f cheers Dan -- PHP Internals - PHP Runtime Development Mailing List T

Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version

Ferenc Kovacs wrote: > this would also eliminate > the confusion, that something is present in 5.6.27 but not in > 5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will > land in 5.5.41). I think the solution to this is pretty clear, as Rowan put it: Rowan Collins wrote: > - On

Re: [PHP-DEV] Deprecate setlocale?

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 thread-safe-setlocale.(h/cpp) files > for Zend. Ok, that'

Re: [PHP-DEV] Deprecate setlocale?

Adam Harvey wrote: > What about just adding another function: setlocale_global(), or similar? Do you mean setlocale would become the thread safe one, and setlocale_global() would be the current behaviour? If so, that would be a BC break for the small number of people who are deliberately using set

Re: [PHP-DEV] New RFC draft "static class constructor"

Hi Johannes, On 13 April 2015 at 13:37, Johannes Ott wrote: > Hi, > > finally I managed to do my first RFC draft. > > https://wiki.php.net/rfc/static_class_constructor > > I hope I have done everything correct so far and I'm looking forward to > your feedback on it. Here is some feedback then:

Re: [PHP-DEV] New RFC draft "static class constructor"

On 14 April 2015 at 17:39, Johannes Ott wrote: > Am 14.04.2015 um 16:33 schrieb Dan Ackroyd: > >> Here is some feedback then: >> Johannes Ott wrote: > But in the new draft (v0.4) I'm preparing at the moment I'll try to > formulate the trigger "first c

Re: [PHP-DEV] clear_env default in php-fpm

On 23 April 2015 at 12:13, Mathieu Rochette wrote: > I didn't find much information about this change (even finding about > |clear_env| is not that easy when search for "php fpm env var") so I don't > know if there is others reason than BC. It looks like it wasn't discussed that much. The PR has

Re: [PHP-DEV] Adding "numeric" type hint

On 30 April 2015 at 02:17, Yasuo Ohgaki wrote: > Current PHP: Search query failure. > New PHP type hint: Fatal error because foreign key is out of PHP int range. There may be some confusion; NikiC is still doing some work to tidy up the EngineExceptions. When that is finished passing a variable o

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

On 15 May 2015 at 14:38, Xinchen Hui wrote: > Hey: > > as described in https://bugs.php.net/bug.php?id=69640&thanks=1 > > instead of fixing it by exam the error type, I'd prefer to > disallow initializing a engine exception from user land.. How would that work when people want to write

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

On 15 May 2015 at 17:12, Xinchen Hui wrote: >> How would that work when people want to write unit/integration tests >> to test the behaviour of a module when an EngineException is thrown? >> >> If you can't create a certain type of exception, it would mean that >> some code is basically untestable

Re: [PHP-DEV] trigger GC before memory limit is exhausted

Hi Christopher, On 15 May 2015 at 23:14, Christoph Becker wrote: > Hello internals, > > today I have been pointed to bug #60982[1], which appears to be an > unpleasant limitation. > It sure is! > I wonder why the GC is not triggered when the memory limit is exhausted, To hopefully point you in

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

On 16 May 2015 at 17:00, Ryan Pallas wrote: > Why do you want to test parse exceptions? Lint your code before you run it > and you won't have any. ... maybe I'm missing something > obvious, Yeah, there's been a misunderstanding. I'm not talking about wanting to test whether my code generates par

Re: [PHP-DEV] Bug #69640 Unhandled EngineExceptions thrown from userland do not produce any output

On 15 May 2015 at 14:38, Xinchen Hui wrote: > I'd prefer to > disallow initializing a engine exception from user land.. > like if you try to initialize a engine/type/parser exception, an E_ERROR > of: >what do you think? Someone reminded me that TypeExceptions are almost certainly going

Re: [PHP-DEV] [VOTE] Exceptions in the engine

On 18 May 2015 at 15:39, Levi Morrison wrote: > > I wouldn't group > TypeException in the same subtree as ParseException, for instance. One > happens at compile time and the other at run time, which means the > intent in what you catch is probably quite different. TypeException is also different

Re: [PHP-DEV] trigger GC before memory limit is exhausted

On 19/05/2015 00:07, Christoph Becker wrote: > What happens if the soft limit is exhausted, but the GC can free only a > little memory? That might trigger the GC shortly afterwards again and > again. The usual way to stop this sort of flapping is to set the point at which the alarm gets reset to

Re: [PHP-DEV] trigger GC before memory limit is exhausted

On 19 May 2015 at 14:28, Rowan Collins wrote: > Dan Ackroyd wrote on 19/05/2015 14:08: >> >> * When gc_collect_cycles is called (and potentially other functions), >> at the end of that function check whether the amount of memory being >> used is less than reset le

Re: [PHP-DEV] RFC - making the Exception class abstract

Hi Kevin, Kevin Bradwick wrote: > Too many times have I seen developers throwing Exceptions when what they > really needed was something that gave it context like > InvalidArgumentException or RuntimeException. > > Yes, I agree this is something to tackle at code review (and I do) but > I feel PHP

Re: [PHP-DEV] hasType() for internal function parameters?

Levi Morrison wrote: > One thing I really want to work towards in the future is consistency > between user-land and internal functions. There are currently multiple > observable differences. +1, as they say. This is the goal we should be aiming for. Having differences between userland and intern

Re: [PHP-DEV] Re: Typed Arrays in Scalar Types RFC

Tim Bezhashvyly wrote: > Please either throw stones at me or give me enough karma to post it. Sorry, I have neither the ability to give karma, nor a convenient pile of stones. Christoph Becker wrote: > Note that there is already , which has > been declined. The

[PHP-DEV] Revert unapproved language change, was: Fix division by zero to throw exception (round 2)

On 4 July 2015 at 20:56, Sherif Ramadan wrote: > > I'm proposing that we reconsider removing the warning from floating point > division and here's why. Wait what? I don't remember an RFC about the behaviour changing. Did someone ninja commit a change to the language? Well it sure looks like

[PHP-DEV] PCRE jit security hole WAS PCRE JIT stack size limit

On 23 July 2015 at 11:07, Christoph Becker wrote: > PHP7 supports PCRE's JIT compilation of patterns by default, which > mostly works fine. However, there are issues when the matching exceeds > the JIT stack limit, see bug #70110[1]. So to summarise and bring more people's attention to this con

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

Thomas Nunninger wrote: > - "scalar parameter casting" should just be a convenience for coding: > > function foo( (int) $i, (string) $s ) > { > } > >is the same as: > > function foo( $i, $s ) > { >$i = (int) $i; >$s = (string) $s; > } > >or perh

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

$enabledValue is the string 'true', that it should convert it to the boolean true, and so make the function happy. So that allows no E_CAST being generated, as there has been no implicit cast, only an explicit conversion somewhere in the DIC. cheers Dan On 17 July 2014 13:43, Thomas Nun

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

the type-hint information is not available outside the function for the first one. " On 17 July 2014 19:29, Dan Ackroyd wrote: > Hi Thomas, > >> Perhaps I miss your point. But what is the difference to current behavior if >> you do not know about the types? > > No

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fix bug #67064 => Countable interface inconsistency

Hi Remi, Thanks for the PR. I'll merge it as soon as I've been able to test it, as the class should respect the definition of the method in the interface. Regarding the change in behaviour, I think the patch https://bugs.php.net/patch-display.php?bug=67064&patch=bug67064-BC&revision=1402667581 sh

Re: [PHP-DEV] [VOTE] Move the phpng branch to master

Hi, It would be good if people announced that they were going to open things to vote with a warning, rather than just throwing the voting open. The RFC is nowhere complete in it's details for people to make rational decisions. e.g. the section on 'RFC impact' has this for the impact on extensions

Re: [PHP-DEV] [VOTE] Move the phpng branch to master

perhaps that's > what prevented you from seeing it. > > I believe it's impractical to keep shared codebases for extensions between > PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong... > > Zeev > >> -Original Message- >> From: Dan A

Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736

> How about delaying that warning until the headers are sent? I don't think there would be any benefit to that. The only possible scenarios are: i) People sending duplicate headers by accident. When they see the error, they should fix their code, so the error goes away. ii) People who are delibe

Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast

Hi Andrea, When you re-open the voting, please can you have an option that is 'Yes - without numeric typehint' ? Although I like the idea of the RFC, having a type-hint that matches multiple scalar types seems distinctly weird to me. It really needs a separate case making for it, separate from t

Re: [PHP-DEV] [RFC] Exceptions in the engine

Stas wrote: > The only issue I think we need to discuss is catch(Exception $e). Now it > would catch much more than before, if we do no changes. It's not clear why would that be an issue - can you specify what the problem would be? Also, if we changed `catch(Exception $e)` to not catch all excep

Re: [PHP-DEV] [RFC] Exceptions in the engine

Patrick wrote: > I would love to be able to catch, at toplevel. with an error handler or > otherwise, both the memory limits exceeded and time limit exceeded cases. +1, as the kids today say. I don't think that it should require any new code - we already have the ability to extend the memory limi

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

Hi, Wouldn't this RFC be almost instantly deprecated if the Return Type Declarations RFC ( https://wiki.php.net/rfc/returntypehinting ) is accepted? cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736

Florian wrote: > On the PR of the setcookie patch > to become compliant with the HTTP RFC, >There are some facts: > >- the current way does not follow the HTTP RFC. Please stop saying this, it isn't true. >From rfc6265: > Servers SHOULD NOT include more

Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736

Andrea wrote: >Perhaps it would be worth ditching any attempts to change setcookie() (just >keep it around for backwards-compatibility), and to instead add a new >function, function family, or indeed class for cookie handling. > >Thoughts? Any idea what such an API might look like? I think this

Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736

On 2 November 2014 15:10, Rowan Collins wrote: > Wait, what does session handling have to do with any of this? Sorry, I completely failed to write what I was trying to say there. I meant that like the session handling functions and setcookie are similar in that: * They don't feel that nice to u

Re: [PHP-DEV] PHPDBG scope

Hi, Derick wrote: > I asked him what the original scope of phpdbg was,... > And I very much agree that the above bullet points, The original scope of a project and what it should be in the future are not related always related. Please don't pretend that they're the same thing. Derick wrote: > I'

Re: [PHP-DEV] Bugfest

Levi wrote: >> ...and what to do with feature requests? Stanislav Malyshev wrote: > if it's clear what is being asked than just leave them alone, Would it be appropriate to close issues that are clear, but can easily be done in userland e.g. https://bugs.php.net/bug.php?id=64639 Leaving an issu

Re: [PHP-DEV] [RFC] Add cyclic string replacements

Hi François, The RFC is missing one thing if nothing else; a reason for why this functionality would be so much better implemented in the core than in userland code. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Top 10 Pecl extensions PHP7 compatibility

On 14 January 2015 at 21:21, Michael Wallner wrote: > * imagick Most of the work was done while it was still called NG: https://github.com/danack/imagick/tree/phpng . Which means that branch probably won't work against master as there have been other small changes. btw It would be great if there

Re: [PHP-DEV] Top 10 Pecl extensions PHP7 compatibility

On 16 January 2015 at 01:58, Rasmus Lerdorf wrote: > The closest we have at this point is: > >https://wiki.php.net/phpng-upgrading > > If people > here could skim it and fix anything that isn't current it would help. Thanks. I think the TSRM changes need to be added, which could be copied fro

Re: [PHP-DEV] Re: Top 10 Pecl extensions PHP7 compatibility

On 16 January 2015 at 00:03, Pierre Joye wrote: > It is also important to note that I would like to push the usage of install > from git/other VCS in the near term, using pickle, and use the website only > for the meta info but not (or much less) for hosting the releases. As well as that, I think

[PHP-DEV] Class constructor behaviour

Hi, I've been going through some bug reports, and have found there are several bad behaviours related to class constructors that ought to be corrected, but could only be done at a major version. The bad behaviours are: Constructors returning null --- Several classes in PH

Re: [PHP-DEV] Class constructor behaviour

On 17 January 2015 at 16:04, Rowan Collins wrote: > The difference is that AFAIK all the exceptions returned by OOP extensions > right now are of classes specific to that extension, whereas this would be a > global engine-thrown exception. Sorry - I wasn't clear. I didn't mean they should throw

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

On 20 January 2015 at 20:09, Marc Bennewitz wrote: > Pros & Cons > > _Named Parameters:_ > pro: > - readability (If caller is not required to call as assoc array) > - not an option for inheritance > con: > - paramter skipping is a side product with possible edge cases > - Adds var

Re: [PHP-DEV] PHP7 Homework for everyone reading this list

On 22 January 2015 at 21:07, Lester Caine wrote: > imagick is now available? Not yet. I'll try to finish it off before the end of the weekend. Most of the work was done earlier, but I need to add the changes for the Native TLS. btw this request to update the PHPNG upgrading guide is still open:

Re: [PHP-DEV] [RFC] Vote results for default ctors RFC

On 25 January 2015 at 11:26, Peter Cowburn wrote: > That's what the mailing list threads are for, right? If someone has already said a reason on the list for why an RFC should be voted no, when someone else agrees with that reason it's not common for them to email, as it could be viewed as gener

[PHP-DEV] imagick on PHP 7 was Stepping stones to a working php7 ...

On 26 January 2015 at 00:02, Lester Caine wrote: > /imagick ... need to get a copy to work with Imagick is now working on 7; you will need to use the PHP 7 branch from https://github.com/mkoppanen/imagick/tree/phpseven Opening any issues you might find on Github would probably get them resolved

Re: [PHP-DEV] imagick on PHP 7 was Stepping stones to a working php7 ...

On 26 January 2015 at 21:06, Lester Caine wrote: > I'm getting a > unknown type name ‘smart_str’ after failing to find php_smart_str.h > because my php7 build has php_smart_string.h. Apologies - this was caused by the filename being changed in the PHP src, and me compiling against the version lef

Re: [PHP-DEV] [RFC] [VOTE] pecl_http

On 28 January 2015 at 22:50, Andrey Andreev wrote: > You're voting "no" because the FIG can't agree yet? > They've been discussing this for *at least* an year and iirc the first > PSR-7 coordinator gave up on it because he no longer believed in the > end result. What does that tell us? That some

Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference

On 21 January 2015 at 04:39, Thomas Bley wrote: > In userland it is sometimes necessary to extend PHP's notices/warnings with > additional information (e.g. username from session, stack trace, etc.) Why can't you just use in the error handler function to write the exact message you want? http:/

  1   2   3   4   5   6   7   >