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

Le Thu Feb 05 2015 at 21:15:45, Andrea Faulds a écrit : Good evening, > > 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. > > I’d like to make sure that everyone voting understands the RFC fully. > P

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

Le Fri Feb 13 2015 at 12:34:29, Zeev Suraski a écrit : > > On 13 בפבר׳ 2015, at 13:13, Andrea Faulds wrote: > > Hi, > > On 13 Feb 2015, at 09:37, Patrick ALLAERT wrote: > > > Voted "no" because of the reasons already mentioned by a bunch of others >

Re: [PHP-DEV] Scalar Type Hints v0.4

Hi Sara (and thanks for continuing the work!) Le Tue Feb 17 2015 at 23:04:20, Sara Golemon a écrit : [...] > 2) Define a way to enable "strict mode" (we'll be weak by default). > [...] > 3) Tighten up coersion rules for weak mode. i.e. "10 dogs" for an int > is a violation, but "10" is accepta

Re: [PHP-DEV] Scalar Type Hints v0.4

Le Wed Feb 18 2015 at 18:35:02, François Laupretre a écrit : > > De : Patrick ALLAERT [mailto:patrickalla...@php.net] > > ini_set("coercion_reporting", COERCION_ERROR); // Fail in case of > > potentially bad coercion > > > > foo(7); > >

Re: [PHP-DEV] Scalar Type Hints v0.4

Le Wed Feb 18 2015 at 19:10:54, Sara Golemon a écrit : > On Wed, Feb 18, 2015 at 7:34 AM, Patrick ALLAERT > wrote: > > Regarding 2) and 3): > > An option might be to implement "weak mode" only and configure the > coercion > > rules "reporting"

[PHP-DEV] (off topic) Array to string conversion (Was: Re: [PHP-DEV] Scalar Type Hints v0.4)

Le Thu Feb 19 2015 at 00:38:25, François Laupretre a écrit : > This is definitely not the same case as generating a notice on array to > string (and why did you generate a notice instead of E_DEPRECATE, we would > be rid of this crap now). > I haven't decided that without discussing [1] it. E_D

Re: [PHP-DEV] Scalar Type Hints v0.4

Le Thu Feb 19 2015 at 00:38:25, François Laupretre a écrit : > > > Why can't strictness follow that path? > > Because strictness is not the overall objective the PHP language is aiming > to. I cannot agree more with that. > If it was the case, your mechanism would be fine, but deprecating ZPP

Re: [PHP-DEV] Scalar Type Hints v0.4

Le Wed Feb 18 2015 at 19:10:08, François Laupretre a écrit : > > De : Patrick ALLAERT [mailto:patrickalla...@php.net] > > > > The biggest advantage, IMHO, is that you get the exact same result > whether > > you do: > > > > foo((int) $val

[PHP-DEV] Re: (off topic) Array to string conversion (Was: Re: [PHP-DEV] Scalar Type Hints v0.4)

2015-02-19 12:26 GMT+01:00 François Laupretre : > Hi Patrick, > > I know you didn’t decide it alone, but the right solution, IMO, would have > been to E_DEPRECATE nonsense conversions. That’s what we are currently doing > for ZPP conversions (https://wiki.php.net/rfc/zpp-conversion-rules). I also >

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

Le mer. 25 févr. 2015 à 12:16, Xinchen Hui a écrit : Hey: > > On Tue, Feb 24, 2015 at 12:06 AM, François Laupretre > wrote: > > Hi, > > > > Starting the vote for https://wiki.php.net/rfc/array-to-string. > > > > Please note that, while the initial RFC proposed both options of either > > fully su

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

Le lun. 2 mars 2015 à 13:39, Patrick ALLAERT a écrit : > Le mer. 25 févr. 2015 à 12:16, Xinchen Hui a écrit : > > Hey: >> >> On Tue, Feb 24, 2015 at 12:06 AM, François Laupretre >> wrote: >> > Hi, >> > >> > Starting the vote for https://w

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

Le lun. 2 mars 2015 à 15:24, Zeev Suraski a écrit : > All, > > > > 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; It’s addressed in the RFC – but I’m a bit worried that this opens > the door

Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion

Le jeu. 5 mars 2015 à 23:20, Pascal Martin, AFUP a écrit : > Le 23/02/2015 17:06, François Laupretre a écrit : > > Starting the vote for https://wiki.php.net/rfc/array-to-string. > > Hi, > > We talked about this with other people at AFUP and a great majority of > us agrees that the current behavi

[PHP-DEV] Pedantic errors (Was: Re: [PHP-DEV] [RFC][VOTE] Improve array to string conversion)

Le lun. 23 févr. 2015 à 17:06, François Laupretre a écrit : > Hi, > > Starting the vote for https://wiki.php.net/rfc/array-to-string. > > Please note that, while the initial RFC proposed both options of either > fully supporting the feature, or disabling it, the voting choices are now : > > - eit

Re: [PHP-DEV] Make zend_parse_parameters emit E_RECOVERABLE_ERROR

Le lun. 1 sept. 2014 à 20:13, Andrea Faulds a écrit : > > On 1 Sep 2014, at 17:29, Chris Wright wrote: > > > It's also worth noting that the "return NULL on zpp failure" > > convention is not followed to the letter, I have seen places that > > RETURN_FALSE - I can't remember exactly where I have

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

Hello, Le ven. 6 mars 2015 à 00:44, Marcio Almada a écrit : > > You are right about this. I'll setup a yes/no vote + a vote to decide > between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this > is just a detail but maybe it's very important to others, so better to let > each vo

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

2015-03-10 16:02 GMT+01:00 Anthony Ferrara : > Patrick, > > My viewpoint is that options in an RFC are dangerous. I would much > rather have a single RFC, with a single vote (yes/no). I think we > should be discouraging the options as much as possible. > > The reason is simple: an RFC should be an

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Hello, Le lun. 2 mars 2015 à 00:03, Marcio Almada a écrit : Hi, internals > > I'm moving the "Strict Argument Count" RFC into discussion phase: > > RFC: https://wiki.php.net/rfc/strict_argcount > PR: https://github.com/php/php-src/pull/1108 > > Many different opinions were collected during resea

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

Le mar. 10 mars 2015 à 19:29, Marcio Almada a écrit : > Hi, > > 2015-03-10 11:39 GMT-03:00 Patrick ALLAERT : > > Hello, >> >> Le ven. 6 mars 2015 à 00:44, Marcio Almada a >> écrit : >>> >>> You are right about this. I'll setup a y

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

Le lun. 9 mars 2015 à 13:45, Michael Wallner a écrit : > Hi, I’d like to start vote on RFC:continue_ob — any objections? > > https://wiki.php.net/rfc/continue_ob > > > Regards, > Mike > No objections. It didn't really require an RFC IMO, but it doesn't hu

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Le mar. 10 mars 2015 à 21:04, Marcio Almada a écrit : > > > 2015-03-10 12:31 GMT-03:00 Patrick ALLAERT : > >> Hello, >> >> Le lun. 2 mars 2015 à 00:03, Marcio Almada a >> écrit : >> >> >> I'm globally +0.5, however I have some concerns

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Le mer. 11 mars 2015 à 22:44, Marcio Almada a écrit : > 2015-03-11 6:27 GMT-03:00 Lester Caine : > > > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote: > > > Most of the examples being shown are examples of simple bad programming > > practice that needs fixing anyway, and I would exp

Re: [PHP-DEV] Reclassify E_STRICT notices

Hi Nikita, Le dim. 22 févr. 2015 à 23:31, Nikita Popov a écrit : Hi internals! > > I would like to propose reclassifying our few existing E_STRICT notices and > removing this error category: > > https://wiki.php.net/rfc/reclassify_e_strict > > As we don't really have good guidelines on when

Re: [PHP-DEV] Reclassify E_STRICT notices

Le ven. 13 mars 2015 à 10:33, Patrick ALLAERT a écrit : > Hi Nikita, > > Le dim. 22 févr. 2015 à 23:31, Nikita Popov a > écrit : > > Hi internals! >> >> I would like to propose reclassifying our few existing E_STRICT notices >> and >> removing this erro

[PHP-DEV] [RFC] Improved Error Callback Mechanism

Hi Internals, This email is to inform you that Olivier and I have opened for discussion a new RFC in order, for PHP extensions authors, to hook more easily into the default error handler callback: https://wiki.php.net/rfc/improved_error_callback_mechanism There is zero new feature for the users,

Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count

Le ven. 13 mars 2015 à 14:39, Lester Caine a écrit : > On 13/03/15 09:02, Patrick ALLAERT wrote: > > It also depends on your perception of E_STRICT. This level has been > > introduced in 5.0 without being part of E_ALL in order to, among other > > things, avoid too much

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

Le mer. 18 mars 2015 à 10:56, Pavel Kouřil a écrit : > Hello, > > how will these examples work btw? > > // a.php > declare(strict_types=1); > function foo($fn) { > $fn("1"); > }; > > // b.php > require 'a.php'; > foo(function (int $a) { return $a * 2; }); > > > > // c.php > function foo($f

Re: [PHP-DEV] "strict_types" should be renamed "raise_type_error". WAS: About declare(strict_types = 1)

Le lun. 16 mars 2015 à 21:34, Matthew Leverton a écrit : > (Although the irony of using =1 instead of =true isn't lost on me!) > Yes, I mentioned[1] that funny aspect earlier. 0 or 1 is explicitly required in order to update the boolean behind it while true/false generates a fatal error with "s

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

Hey, Le dim. 15 mars 2015 à 01:54, Niklas Keller a écrit : > 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 > > There was a small change: If the haystack is a string, integers are n

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

Hi Dennis, Le mar. 28 avr. 2015 à 18:33, Dennis Birkholz a écrit : > > just to satisfy my personal curiosity: how can this RFC target 7.0 which > had the feature freeze over a month ago? Should it not be 7.1 just to > treat all contributors equal? > We are fully aware of the feature freeze and h

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

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 is, we are in feature freeze and it > creates a bad prec

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

Le mer. 29 avr. 2015 à 03:19, Pierre Joye a écrit : > On Apr 29, 2015 5:38 AM, "Adam Harvey" wrote: > > > > On 28 April 2015 at 15:10, Patrick ALLAERT > wrote: > > > Le mar. 28 avr. 2015 à 20:42, Kalle Sommer Nielsen a > écrit : > > > > >

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

Le mer. 29 avr. 2015 à 10:57, Kalle Sommer Nielsen a écrit : > I would love to see more work toward identifying issues in PHP7, and > hopefully we can get that once we release the first alpha. > The issue targeted here is "two extensions overriding php_error_cb can't live side by side" and that

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

Le jeu. 30 avr. 2015 à 01:32, Stanislav Malyshev a écrit : > Hi! > > > The issue targeted here is "two extensions overriding php_error_cb can't > > live side by side" and that issue exists since PHP 4.0. Should a bug > report > > be opened? > > I'm not sure why can't they live side by side. Sin

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

Le jeu. 30 avr. 2015 à 02:26, Stanislav Malyshev a écrit : > Hi! > > > You can cast your vote on the Wiki [1] and the according patch is > > available as a Pull Request [2]. > > > > Vote will be open for two weeks, counting from today. > > > > I think the idea of this RFC is nice but it needs a b

Re: [PHP-DEV] php 7/git buid on linux/64: fatal error @ 'Installing PEAR environment';

Le mer. 10 juin 2015 à 17:05, a écrit : > hi > > I'm building PHP7 on linux/64 > > git checkout PHP-7.0.0 > cd PHP-7.0.0 > git log | head > commit dbf30365aa15b9044d75b8f77db570bf8fdf2726 > Merge: 9cb8cb4 5ff259e > Author: Fe

Re: [PHP-DEV] php 7/git buid on linux/64: fatal error @ 'Installing PEAR environment';

Le mer. 10 juin 2015 à 17:15, Patrick ALLAERT a écrit : > Le mer. 10 juin 2015 à 17:05, a écrit : > >> hi >> >> I'm building PHP7 on linux/64 >> >> git checkout PHP-7.0.0 >> cd PHP-7.0.0 >> git log | head >>

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

Le mer. 10 juin 2015 à 17:20, Peter Cowburn a écrit : > On 28 April 2015 at 14:24, Olivier Garcia wrote: > > > Dear Internals, > > > > The "Improved Error Callback Mechanism" RFC is now in voting phase. > > > > You can cast your vote on the Wiki [1] and the according patch is > > available as a

[PHP-DEV] Very strange error message

Hello list, Today I am facing a rather strange PHP error message on a production system using PHP 5.4.41 with APC: [09-Jul-2015 15:06:43 Europe/Brussels] PHP Fatal error: Access to undeclared static property: Stash\Item::$/opt/app/a373/apache-pro/htdocs/vendor/tedivm/stash/src/Stash/Interfaces/I

Re: [PHP-DEV] Very strange error message

Hi Kalle, Le jeu. 9 juil. 2015 à 17:30, Kalle Sommer Nielsen a écrit : > Hi Patrick > > > Any clue of what happened? PHP bug, APC one? Memory corruption? Bad karma > > or planets wrongly aligned? > > At first it sounds like an APC issue, is it reproducible without? APC > never fully supported 5.

Re: [PHP-DEV] Very strange error message

Hi Andreas, Le jeu. 9 juil. 2015 à 17:35, Andreas Heigl a écrit : > Hi Patrick. > > Am 09.07.15 um 16:58 schrieb Patrick ALLAERT: > > Hello list, > > > > Today I am facing a rather strange PHP error message on a production > system > > using PHP 5.4.41 wit

Re: [PHP-DEV] Bug #54514

2011/12/7 Sebastian Bergmann : >  Can somebody look into https://bugs.php.net/bug.php?id=54514 please? >  This causes issues for CLI tools implemented in PHP that are invoked >  through Apache Ant, for instance, and need to know the PHP interpreter >  that is running them. > >  See https://github.c

Re: [PHP-DEV] [RFC]Call for voting about const array/string dereference

2011/12/13 Nikita Popov : > This can't go into PHP 5.4.0 in any case, because it is a feature > addition and the release is already in RC. +1 @Laruence Can you remove the voting widget? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

2011/12/24 Pierre Joye : > hi Ilia, > > Right but there is a clear BC break here. And yes I really don't like > how datetime deals with that but it is how it is, and it is certainly > the only case where it fails (or almost). > > On Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky wrote: >> Introduc

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

2011/12/27 Ilia Alshanetsky : > I think the REQUEST_TIME semantics of returning float should remain as is. > > -1 for adding further environment variables. As mentioned earlier, I don't like this option very much but at least it solves the BC problem. Do you have any other proposal to share? Oppo

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

2011/12/27 Pierre Joye : > On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans wrote: > >> Ah, that one. I got lost between all the commas and thought he meant an >> RFC for changing REQUEST_TIME from int to float :-) > > :) > > Which name should we use? > > a) REQUEST_TIME_FLOAT > b) REQUEST_TIME_MSE

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

2011/12/27 Ilia Alshanetsky : > The change is inside 5.4 version which adjust breaks BC. I don't follow you here Ilia. As per https://wiki.php.net/rfc/releaseprocess: * "Backward compatibility must be respected with the same major releases, for example from 5.2 to 5.6." * Going from x.y.z to x.y+

Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4

2012/1/6 André Rømcke > > On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs wrote: >> >> >> >> On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT >> wrote: >>> >>> 2011/12/27 Ilia Alshanetsky : >>> > The change is inside 5.4 ve

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

+1: It does make sense to me for the same reason as Stas mentioned. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New Array function - limited push

2012/2/14 Pedro Pereira : > Hi. I'm Pedro and I'm from Portugal. > > I've been working with php for a while but only now i decided to try my > luck and propose a new array function that will become handy for many > people :) > > This function adds new elements to the end of an array but limits the

Re: [PHP-DEV] Small question about performance

2012/3/15 Nikita Popov : > If I am understanding the text correctly it is saying that >    $f1 = f1(); >    $f2 = f2($f1); >    $f3 = f3($f2); > is using more memory than >    $f3 = f3(f2(f1())); > > For me this doesn't make any sense. In the latter case PHP will also > create temporary variables t

Re: [PHP-DEV] Re: [RFC] skipping optional parameters

2012/4/18 Matthew Weier O'Phinney : > My one comment, which others have raised, is readability of multiple > commas -- TBH, at first glance it has the appearance of a mistake. I > think those suggesting a keyword such as "default" make a good point in > this regard -- it makes it 100% clear that yo

Re: [PHP-DEV] RFC: Property get/set syntax

2012/4/20 Stas Malyshev : > How these would work with isset - what !empty($this->Hours) return? What > would happen if you do unset($this->Hours)? What happens if you do > $this->Hours++ or sort($this->Hours) (assuming $Hours is an array)? > These things need to be defined in the RFC too. My sugge

Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()

Hi, 2012/4/12 Nikita Popov : > PS: I added isset() too, to address the consistency concerns mentioned on IRC. I would have voted +1 if it didn't contain the isset() change. None of the examples used in the isset_with_expr.phpt test seems logic to me. Care to explain the consistency concerns here

Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()

2012/5/1 Ferenc Kovacs : > On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov > wrote: > - both isset and empty are language constructs, which many people use > almost interchangeability, changing one of them in a way that the same > expression works with one of them, but blows up with a parse error se

Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()

2012/5/3 Lester Caine : > Anthony Ferrara wrote: >> >> I voted for the ability to use an expression for isset() as well, >> since I agree with Ferenc, it's a matter of consistency.  Sure, the >> use-case for isset() is definitely weaker than for empty(), but at the >> same token they are definitely

Re: [PHP-DEV] RFC proposal - Syntactic sugar for cloning

2012/6/29 Amaury Bouchard : > Hello everybody, > > It's the first time I write on the internals mailing-list, so let me > introduce myself quickly. I'm a french and canadian CTO, working in Paris. > I lead some PHP projects (mainly the Temma framework and FineFS data > replication system). > I begi

Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class names to scalars

2012/9/14 Dmitry Stogov : > Finally, may be SOMETHING::__CLASS__ is a bit more clear than > SOMETHING::class. That is the reason why I voted "no", but more because of the token used than the feature. I previously stated that I preferred __CLASS__ as well to be more in line with what we currently h

Re: [PHP-DEV] Re: Why does $_REQUEST exist?

2009/5/15 Michael Shadle > > On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham wrote: > > > bc? all the reasoning in the world won't justify it to 1 million businesses > > running php 4 code which is reliant on $_REQUEST behind the scenes. > > > > although it would generate a tonne of freelance work

[PHP-DEV] APM

Hi list, First, I'd like to apologize if the subject of this mail is somewhat off-topic. Davide Mendolia and me are currently working on: "Alternative PHP Monitor" (APM - http://code.google.com/p/peclapm/) which consist of three parts: - a PHP extension which has as a goal of capturing "events" (

[PHP-DEV] ext/ldap for PHP6

Hi list, Having done some PHPT tests on ext/ldap [1] with Davide Mendolia at the Testfest, we realized that the extension wasn't ready in PHP 6. In attachment I put a patch that enables all LDAP tests [1] to "PASS" using PHP6. As it is my first patch here, could you please revise it and give me y

Re: [PHP-DEV] APM

27;s for current situation or con's for implementing this at MINIT? The only thing I see now is the ability to make the extension active on a request basis rather than globally. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtim

Re: [PHP-DEV] APM

the callback function at application level isn't manageable when you don't have the control of the applications, this is why we started as an extension that could be plugged, transparently, to PHP. Triggered error could then be forwarded using SNMP, mailing, syslog, etc. with additional

[PHP-DEV] CVS Account Request: patrickallaert

Main reason is writing phpt tests and contribute to the php-qa team. Zoe Slattery suggested me to ask for CVS access. I will also submit patch on internals ML for review and commit them (only if accepted!) I may consider writing extension(s) too (see APM), but for now they are hosted on code.goo

[PHP-DEV] [PATCH] ext/ldap: PHP 6 & bug #48441

48441.patch.txt All of them should be committed to HEAD (a) and (c) should be committed in addition to PHP_5_3 and PHP_5_2 (with adaptations). You can test them with: http://testfest.php.net/repos/testfest/BelgiumUG/ext/ldap/tests/ Thanks for your feedback :) Cheers, -- Patr

Re: [PHP-DEV] New to the PHP internals and I want to help

Hi Martin, Not sure it can help you, but you may found the following link interesting: http://phpbuilder.com/manual/en/internals.php Cheers, Patrick 2009/6/19 Martin Wernstahl : > Hi! > > I'm an 18 years old student from Sweden with an interest in > programming, particularly in solving more > co

Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency

2014-09-25 9:42 GMT+02:00 Dmitry Stogov : > Hi, > > The vote is opened at > https://wiki.php.net/rfc/fix_list_behavior_inconsistency > > Thanks. Dmitry. > Hi, I'm in favor of disabling for consistency as well, however, I wish a warning would be emitted. Not only it would tell me that I have a po

Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency

2014-09-25 17:27 GMT+02:00 Patrick ALLAERT : > 2014-09-25 9:42 GMT+02:00 Dmitry Stogov : > >> Hi, >> >> The vote is opened at >> https://wiki.php.net/rfc/fix_list_behavior_inconsistency >> >> Thanks. Dmitry. >> > > Hi, > > I'm

Re: [PHP-DEV] New Standardized HTTP Interface

2014-10-30 19:23 GMT+01:00 Sherif Ramadan : > Hello Internals, > > I've been meaning to write up a full-blown RFC for introducing a new > standardized HTTP interface for PHP core for some time now. I figure now > with PHP 7 on the road map this might be a good time to start this > discussion since

Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()

2014-11-04 20:48 GMT+01:00 Dmitry Stogov : > I agree with Nikita. > Adding an extra argument for one particular security related case looks > weird. Same opinion here. Unfortunately, I can't propose something more robust instead, but I have the feeling that this RFC tries to solve the symptoms of

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

Le Wed Nov 19 2014 at 9:31:50 AM, Julien Pauli a écrit : > On Wed, Nov 19, 2014 at 5:15 AM, Yasuo Ohgaki wrote: > > Hi all, > > > > On Wed, Nov 19, 2014 at 8:11 AM, Levi Morrison wrote: > > > >> I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If > >> accepted, methods with the s

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

Le Wed Nov 19 2014 at 10:57:39 PM, Levi Morrison a écrit : > > - PHP suffers a lot from function bloat and this RFC provides > multiple functions that do the same thing but differ only in how they > handle errors. A simple validation of "can this be safely cast to an > integer without dataloss?"

Re: [PHP-DEV] 64-bit performance improvement by reducing zend_op size.

Hi, 2014-12-10 16:27 GMT+01:00 Dmitry Stogov : > Hi, > > Please, review the following patch > https://gist.github.com/dstogov/fba2cc621ef121826efe Looks good, but Isn't ZEND_EX_USE_RUN_TIME_CACHE always defined to 1 with your patch? Regards, Patrick -- PHP Internals - PHP Runtime Development M

Re: [PHP-DEV] [RFC] Improve array to string conversion

Le Sun Jan 11 2015 at 14:30:42, F & N Laupretre a écrit : > Hi, > > A new RFC for PHP7 : https://wiki.php.net/rfc/array-to-string > > Not implemented yet, but the PR is available for comments : > https://github.com/php/php-src/pull/991 > > Regards > > François > Just for the record, when I imple

Re: [PHP-DEV] [RFC] Implement a LoggerInterface to PHP

Hi, 2012/11/8 Florin Razvan Patan : > Hello, > > > After a talk on the Symfony framework here: > https://github.com/symfony/symfony/issues/5911 > Long story short, the point that @Seldaek suggestion to have a common > interface for loggers > actually makes sense and the best way to have it would b

Re: [PHP-DEV] RFC: ext/mysql deprecation

nsion to pecl do we pull the warnings back out? Surely it makes no > sense to move an extension out of core to pecl and spew E_DEPRECATED > warnings to people who explicitly choose to install it. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: ext/mysql deprecation

2012/11/12 Adam Harvey : > Hi everyone, > > I've written an RFC to cover deprecating ext/mysql in PHP 5.5: > https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft > deprecation in the documentation purely via a straw poll on Internals, > I presume this will end up needing to go to a

[PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)

2012/11/12 Adam Harvey : > Hi everyone, > > I've written an RFC to cover deprecating ext/mysql in PHP 5.5: > https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft > deprecation in the documentation purely via a straw poll on Internals, > I presume this will end up needing to go to a

Re: [PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)

2012/11/16 Rasmus Lerdorf : > On 11/16/2012 02:18 AM, Patrick ALLAERT wrote: >> In eZ Publish CMS, we have recently removed [1] support for the mysql >> handler in favour of the mysqli one and as such, we have no more >> mysql_*() functions calls except for the above use cas

Re: [PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)

2012/11/16 Rasmus Lerdorf : > On 11/16/2012 09:32 AM, Patrick ALLAERT wrote: >> 2012/11/16 Rasmus Lerdorf : >>> On 11/16/2012 02:18 AM, Patrick ALLAERT wrote: >>>> In eZ Publish CMS, we have recently removed [1] support for the mysql >>>> handler in favour

[PHP-DEV] zend_ce_aggregate

Hi, What is the "zend_ce_aggregate" zend_class_entry? It looks like it has been introduced by helly in PHP 5.0 but the purpose is not clear to me. Maybe a WIP related to the object aggregation functions we had in PHP 4? Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscr

Re: [PHP-DEV] zend_ce_aggregate

Just figured it out now thanks to http://lxr.php.net/xref/PHP_5_4/Zend/zend_interfaces.c#582 Thanks Nikita. 2012/11/25 Nikita Popov : > On Sun, Nov 25, 2012 at 3:45 PM, Patrick Allaert > wrote: >> >> Hi, >> >> What is the "zend_ce_aggregate" zend_c

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

2012/11/28 Lester Caine : > There is no 'objection' to deprecating the extension, but adding > E_DEPRECATED to the code is problematic since that should NOT be present in > a PECL version of the code? Sorry, but removing the E_DEPRECATED notice when moved to PECL is not part of the proposed RFC an

Re: [PHP-DEV] The built-in PHP web server is very cool!

2012/12/19 Raymond Irving : > Hi William, > > Why not? Thank you for the kind words Raymond (which should be addressed to Moriyoshi Koizumi), but as mentioned on: http://php.net/manual/en/features.commandline.webserver.php: * It has never been created for anything else than development purpose onl

Re: [PHP-DEV] Purpose of voting

2013/1/28 Zeev Suraski : >> What should we be voting on when voting on an RFC: on the RFC proposed >> feature, or on the patch itself? > > I think it should be exclusively on the concept. We never vote about code > changes anywhere - including when we refactor existing parts. Why would > we vote

Re: [PHP-DEV] Purpose of voting

2013/1/28 Derick Rethans : > Both the idea and implementation needs to be sound. If not, I vote "no" > (and that also means "no" when it makes APC's life harder). This is a bit unfair. APC is just one byte code caching mechanism out there, even if it's the mostly used or most performing one (and e

Re: [PHP-DEV] File system watcher/monitoring

2013/2/14 Ivan Enderlin @ Hoa : > I have written: “On Linux, we have inotify (available in PHP through > pecl/inotify)”, so yup, I know for inotify :-). I propose to gather all > these API and give a proper one to the end-user. If you are doing so, I would suggest you to create this as a C library

Re: [PHP-DEV] PHP 5.5 upcoming roadmap

2013/2/15 Julien Pauli : > Hello everyone, > > As you may know, Zend recently open sourced ZendOptimizer+ with a PHP > Licence. > We are planning to merge it to PHP5.5 Core (discussions on Mailing lists > and IRC) and have it bundled with PHP5.5 final release stable. Correct me if I am wrong, but

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

2013/2/19 Sara Golemon : > Opening RFC to allow trailing comma in function call argument lists > > https://wiki.php.net/rfc/trailing-comma-function-args > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php I'm all for it! Waiting for t

Re: [PHP-DEV] [RFC] Short syntax for anonymous functions

2013/2/19 Marcello Duarte : > Inspired by Sara, here is another RFC, I finally got around to draft: > > https://wiki.php.net/rfc/short-syntax-for-anonymous-function > > Please feedback, > -- > Marcello Duarte BC break detected: The {} would probably be a closure that is not assigned to anything

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

2013/2/19 Nikita Nefedov : > Hmm, I agree about grepping, but how often do you do it? Actually, last time > I grepped php files was half a year ago I think, when I had just ssh > connection and didn't want to mount sshfs. But usually there's IDEs that can > statically analyze your code and let you

[PHP-DEV] Error/Exception handlers chaining (Was: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5)

2013/2/28 Derick Rethans : > On Thu, 28 Feb 2013, Anthony Ferrara wrote: > >> It appears that xdebug is borking generator exception handling. Without >> xdebug the following two tests pass, but with it they fail: >> >> Generator::throw() where the exception is caught in the generator >> [Zend/test

Re: [PHP-DEV] Re: Merging O+ into 5.5

2013/3/15 Dmitry Stogov : > Hi, > > For now, I'm trying subtree merging (See http://git-scm.com/book/ch6-7.htmland > https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html > ) > > You may see the result at https://github.com/dstogov/php-src/tree/PHP-5.5/ > > This is not an

Re: [PHP-DEV] Proposal: new magic methods for Object references.

2013/3/19 Matīss Roberts Treinis : > Proposal: > > Two additional magic methods for PHP objects - > > __refer(void): > > Refer method is called whenever object's identifier is assigned to > variable, if such method is present. > Example: > > $foo = new Bar; > $bar = $foo; //__refer invoked > > Retu

Re: [PHP-DEV] Method check - Can someone create a RFC for it?

2013/3/20 Carlos Rodrigues : > Hi, > > I'd like to suggest a new functionality for PHP. I don't know the > internals, and i can't create a patch implementing this. I'm writing > here in case someone likes this idea and write a RFC. > > We've had a problem recently where one of our developers forgot

Re: [PHP-DEV] Improve Warning when loading Zend Ext as PHP module

2013/4/3 Johannes Schlüter : > Hi, > > with opcache being bundled I expectr to see multiple bugs like #64568 > where users are trying to load opcache as PHP module (using extension= > in php.ini), I tried to improve the error message a bit. > > In > https://github.com/johannes/php-src/commit/a13012

Re: [PHP-DEV] [RFC] Class instances counter

2013/4/10 Frank Liepert : > Hello internals, > > again an update on the RFC, see https://wiki.php.net/rfc/instance_counter: > > - added support for object as argument > - added support for array argument (indexed array with class names) > - added more code examples > > > -- > PHP Internals - PHP Ru

Re: [PHP-DEV] Continued try blocks

2013/4/30 Pierre Joye : > hi, > > On Tue, Apr 30, 2013 at 7:54 PM, Stas Malyshev wrote: > >>> You may have a lib/object/chunk of code which raises exceptions, because >>> its developer thought some error is not recoverable; but when you use >>> it, you don't want to break your program's execution.

Re: [PHP-DEV] [VOTE] Class instances counter

2013/5/6 Sebastian Bergmann : > On 04/30/2013 10:04 AM, Frank Liepert wrote: >> Voting starts as of now and ends on 7th May, 2013. > > I voted -1; not because I do not think the feature is useful > but because I think it belongs in an extension such as Xdebug and > not in PHP itself. Seriously,

Re: [PHP-DEV] Announcing RFC 'Anonymous Catches'

2013/6/25 Nikita Popov : > but I'm against the generic catch{} statement. I'm sharing Nikita's opinion, with the difference of a bit more enthusiasm on leaving off the variable as it could make it more obvious that there is no intention in using the variable, and that no memory should be kept for

  1   2   3   >