Re: [PHP-DEV] Exposing object handles to userland

On Fri, 31 Jul 2015, Julien Pauli wrote: > Hi people. > > I've been pinged many times to add a new spl_object_id() function to PHP, > that would return the internal object handle of an object. > > Today, spl_object_hash() partially allows that, but adds many randomness to > the result, which is

Re: [PHP-DEV] Reclassify E_STRICT notices

On Thu, 30 Jul 2015, Ferenc Kovacs wrote: > On Sun, Feb 22, 2015 at 11:30 PM, Nikita Popov wrote: > > > 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 real

Re: [PHP-DEV] DateTimeInterface is not a usable interface?

On Tue, 21 Jul 2015, Marco Pivetta wrote: > I should also add that this breaking change was introduced in a patch > release (5.5.8). That wasn't good, but I don't see how it was a *breaking* change. It never worked before this change either. You now just told you're doing something inappropriat

[PHP-DEV] Re: [PHP-CVS] com php-src: Executor cleanup: fix GOTO and SWITCH VMs, remove aility to build additional PHP-5.0 compatible VM, hide executor implementation details.: Zend/zend_compile.h Zend

) Whereas in PHP 7, this ZEND_OPCODE_HANDLER_ARGS define now in a .h file I can't include (zend_execute_vm.h) — and I can't quite understand *why* you've moved that macro. cheers, Derick > On Fri, Jun 26, 2015 at 2:46 AM, Derick Rethans wrote: > > >

[PHP-DEV] Re: [PHP-CVS] com php-src: Executor cleanup: fix GOTO and SWITCH VMs, remove aility to build additional PHP-5.0 compatible VM, hide executor implementation details.: Zend/zend_compile.h Zend

Hi, this change moved: -#define ZEND_OPCODE_HANDLER_ARGS zend_execute_data *execute_data -#define ZEND_OPCODE_HANDLER_ARGS_PASSTHRU execute_data - -typedef int (*user_opcode_handler_t) (ZEND_OPCODE_HANDLER_ARGS); -typedef int (ZEND_FASTCALL *opcode_handler_t) (ZEND_OPCODE_HANDLER_ARGS); - -extern

Re: [PHP-DEV] [VOTE] JSON number to string

On Tue, 9 Jun 2015, Jakub Zelenka wrote: > Hi, > > The voting is now open: > > https://wiki.php.net/rfc/json_numeric_as_string#voting FWIW, I voted no to all of them because (as you even say in the RFC), this is probably better be solved with a JSON schema thingy. cheers, Derick -- PHP Inte

Re: [PHP-DEV] Adding weekdays to DateTime resets the time

Hi, This indeed looks like a bug - Happy to have a look at it to fix in timelib: https://github.com/derickr/timelib cheers, Derick On Mon, 4 May 2015, David Lundgren wrote: > There is actually already a bug for about this: > https://bugs.php.net/bug.php?id=54909 > > I ran into this several m

Re: [PHP-DEV] DateInterval bug

On Sun, 12 Apr 2015, Peter Lind wrote: > Hi, > > I wanted to get into PHP code development so I grabbed a random bug from > bugs.php.net. Which turned out to be https://bugs.php.net/bug.php?id=69378 > > The problem the bug report describes is that creating a diff between two > dates and then sub

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

On Mon, 16 Mar 2015, Xinchen Hui wrote: > And last comment, if there no such declare thing, I will definitely > vote yes to this RFC. > > that's why I want vote no for this, and wait for Bob's Basic STH. That will not be in PHP 7.0 though, as the deadline passed. And I can probably bet on tha

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

On Mon, 16 Mar 2015, Yasuo Ohgaki wrote: > On Mon, Mar 16, 2015 at 8:18 PM, Derick Rethans wrote: > > > On Mon, 16 Mar 2015, Xinchen Hui wrote: > > > > > On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye wrote: > > > > > > >

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

On Mon, 16 Mar 2015, Jordi Boggiano wrote: > On 16/03/2015 11:49, Pavel Kouřil wrote: > > it's similiar to the safe_mode though. Sure, it's not as bad as INI > > setting, but the "intent" is the same - a switch changing how code > > behaves. > > ini_set('memory_limit', 10); also changes how your

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

On Mon, 16 Mar 2015, Pavel Kouřil wrote: > >> This RFC will have serious consequence. We made mistake with > >> "safe_mode". The main reason it failed is "it did not force caller > >> to have responsibility to make it work as it should". This RFC does > >> the same for how declare(strict_types=

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

On Mon, 16 Mar 2015, Yasuo Ohgaki wrote: > On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye wrote: > > > On Mar 16, 2015 6:46 PM, "Yasuo Ohgaki" wrote: > > > > > > On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz > > > wrote: > > > > > > > Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki: > > > > > > >

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

On Mon, 16 Mar 2015, Xinchen Hui wrote: > On Mon, Mar 16, 2015 at 5:00 PM, Pierre Joye wrote: > > > > On Mar 16, 2015 4:29 PM, "Xinchen Hui" wrote: > >> > >> that means, I need to add a lots of (int) while I try to call a > >> function in a library which is not written by myself. > >> > >>

RE: [PHP-DEV] Voting irregularities

On Sun, 15 Mar 2015, Zeev Suraski wrote: > > I don't think it's going to far, if you have people with no clue writing > > this: > > > > https://plus.google.com/+KristianK%C3%B6hntopp/posts/ijoDNH2M8mB > > Do you know who Kristian is and how instrumental he was in the > proliferation of PHP? How

Re: [PHP-DEV] Voting irregularities

Rowan Collins schreef op 15 maart 2015 17:59:17 GMT+00:00: >On 15/03/2015 14:19, Anthony Ferrara wrote: >> All, >> >> I ran some numbers on the current votes of the dual-mode vote right >> now. There were a number of voters that I didn't recognize. So I >> decided to pull some stats. >> >> The fo

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

On Fri, 13 Mar 2015, Arvids Godjuks wrote: > At this point I have only swearing words for the proposing persons and > supporters. Certainly *that* is going to help? > It's magic_quotes and register_globals all over again, but this time > you can't fix it with some PHP code. It is not even clo

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

On Fri, 13 Mar 2015, guilhermebla...@gmail.com wrote: > I really want to understand if we're gonna allow this RFC voting or not. > That's important to reconsider my vote on STH Well, if we look at it the theoretical way, then no, we won't be able to consider this one for PHP 7: - It got announc

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

"guilhermebla...@gmail.com" schreef op 13 maart 2015 18:57:35 GMT+00:00: >+1 on this, as this is more inline with how ZPP currently works, >creating >less headaches to end users. > >On Fri, Mar 13, 2015 at 2:33 PM, Stelian Mocanita >wrote: > >> So to get it clear for everyone: the right way is f

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

On Thu, 12 Mar 2015, Thomas Punt wrote: > Hey PHP Internals, > > So there hasn't been much discussion on this RFC, and yet a lot of people have > voted -1 on it. This is a little disappointing because I'm not entirely sure > why > people are against it - and no one seems to want to debate it eit

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

On Tue, 10 Mar 2015, Patrick ALLAERT wrote: > 2015-03-10 16:02 GMT+01:00 Anthony Ferrara : > > > > 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. > > That is much more stricter than my tho

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

On Wed, 11 Mar 2015, Zeev Suraski wrote: > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > > > > function bar(float $x) > > > $foo = 1; > > > bar($foo); // will definitely fail in strict mode > > > > No, actually it won't fail in strict mode: > > https://wiki.php.net/rfc/scalar_type_hints_v5

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

On Wed, 11 Mar 2015, Zeev Suraski wrote: > The vote on the Coercive Scalar Type Hints is now open for voting. > > > > The latest version of the RFC includes changes discussed on internals@ last > week: > > 1. Accept string->bool and int->bool conversions (false->bool is not > supported) > >

Re: [PHP-DEV] [PR] DateTime::createFromImmutable() method

On Thu, 5 Mar 2015, Trevor Suarez wrote: > Good morning internals! > > I would like to propose a small addition be made to the DateTime class. > > https://github.com/php/php-src/pull/1145 When the factory method was added, we had this same discussion. And the discussions lead to the conclusion

Re: [PHP-DEV] About optimization for compiler

On Fri, 27 Feb 2015, Xinchen Hui wrote: > Hey Internals: > > I was looking Bob's switch optimization.. > > then I start to worry about where is the place optimization should > goes.. > > in generally, PHP is a interpreted language. IMO, it should > compiler the PHP codes to

Re: [PHP-DEV] [RFC] UString

On Sat, 28 Feb 2015, Rowan Collins wrote: > On 28/02/2015 06:48, Joe Watkins wrote: > > Morning internals, > > > > This is just a quick note to announce my intention to ready this RFC > > for voting next week. > > > > I know I'm a little late maybe, I was real sick most of last week, s

Re: [PHP-DEV] [RFC] UString

On Sun, 1 Mar 2015, Yasuo Ohgaki wrote: > Hi Joe, > > On Sun, Mar 1, 2015 at 7:14 PM, Yasuo Ohgaki wrote: > > >public function __construct([string $string [, string $source_codepage > > [, string $substitute_char] ]); > > One additional comment for constructor. It should have default > no

Re: [PHP-DEV] [RFC] UString

Hey Joe, I think there are a few issues with the proposal, although I like the general idea. I've had the tab with the RFC open since October... but never looked at it until now :-/. So, a few comments: - UString as a name. I think I am going to prefer "Text" as a class name. Unicode (and int

Re: [PHP-DEV] [Discussion] Last chance for case-sensitive engine

On Tue, 24 Feb 2015, Yasuo Ohgaki wrote: > On Tue, Feb 24, 2015 at 4:48 PM, Alexander Lisachenko < > lisachenko...@gmail.com> wrote: > > > There is a draft for that: https://wiki.php.net/rfc/case-sensitivity > > (mostly empty), so I decided to ask this question in the internals > > mail list. >

Re: [PHP-DEV] Reclassify E_STRICT notices

On Sun, 22 Feb 2015, Nikita Popov wrote: > 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 which type of error > should be thrown

Re: [PHP-DEV] Annotations in PHP7

On Tue, 17 Feb 2015, Dmitry Stogov wrote: > On Mon, Feb 16, 2015 at 10:57 PM, Derick Rethans wrote: > > > On Mon, 16 Feb 2015, Dmitry Stogov wrote: > > > > > hi, > > > > > > During discussion of different ways of implementing "Design by Contr

Re: [PHP-DEV] Reviving scalar type hints

On Mon, 16 Feb 2015, Sara Golemon wrote: > On Mon, Feb 16, 2015 at 2:50 PM, François Laupretre wrote: > > Once again, anyone can take over version 0.3, if it is so great. Why don't > > you do it ? > > I will play the game, stop working on my proposal, and vote 'yes' again. > > But don't ask me t

Re: [PHP-DEV] Annotations in PHP7

On Mon, 16 Feb 2015, Dmitry Stogov wrote: > hi, > > During discussion of different ways of implementing "Design by Contract" we > got an idea of using annotations. > > BTW: annotations are useful by their own and may be used for different > purposes. Support for annotations was proposed long tim

Re: [PHP-DEV] [RFC] [PRE-VOTE] Remove the date.timezone warning

On Mon, 16 Feb 2015, Yasuo Ohgaki wrote: > On Mon, Feb 16, 2015 at 2:40 PM, Stanislav Malyshev > wrote: > > > > Are you sure that "the ini file is created by the package > > > maintainer and it includes the “date.timezone” setting" is true? > > > Last time I checked it > > > > I my experience,

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

On Wed, 11 Feb 2015, Yasuo Ohgaki wrote: > Hi Markus, > > On Tue, Feb 10, 2015 at 5:59 PM, Markus Fischer wrote: > > > What constitutes "first token" in this context? > > > > Would this be detected as a PHP file? > > > > -8< > > root:x:0:0:root:/root:/bin/bash > > daemon:x:1:1:daemon:/u

Re: [PHP-DEV] [RFC][DISCUSSION] Script only includes

On Tue, 10 Feb 2015, Yasuo Ohgaki wrote: > Hi all, > > Some of you are tired with this topic, but please take a look the RFC > > [RFC] Script only includes - this is 3rd version. > https://wiki.php.net/rfc/script_only_include > > Please let me know what you like or dislike. Con: - It introduce

Re: [PHP-DEV] Remove mycrypt. Vote ends Monday

Tom Worster schreef op 8 februari 2015 15:38:15 GMT+00:00: >mycrypt was abandoned by its developers in 2007. The package in Debian >is >from 2009. It has been removed from RHEL. > >This is already unacceptable. But it would be an insult to the idea of >"security" to include mcrypt in PHP 7. > >The

Re: [PHP-DEV] [VOTE] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)

On Mon, 2 Feb 2015, François Laupretre wrote: > Opening the vote for : > > https://wiki.php.net/rfc/cyclic-replace There doesn't seem to be a voting option? In any case, there are no code examples in that RFC. I think they really ought to be part of it. cheers, Derick -- PHP Internals - PHP

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

On Mon, 2 Feb 2015, Dmitry Stogov wrote: > As I already told, in my opinion, version 0.1 was the perfect solution that > fit into PHP semantic very well. > > declare(strict_types=1); - is really weird solution. > It changes type hinting behavior per file scope, so, just to try strict > type hinti

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

On Tue, 27 Jan 2015, Nikita Popov wrote: > On Tue, Jan 27, 2015 at 7:40 AM, Matteo Beccati wrote: > > > On 27/01/2015 01:34, Bob Weinand wrote: > > > >> Hey, > >> > >> I'd like to request removal of the date.timezone warning. > >> > >> Here is the RFC: > >> https://wiki.php.net/rfc/date.timezone

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

On Tue, 27 Jan 2015, Florian Anderiasch wrote: > On 01/27/2015 07:40 AM, Matteo Beccati wrote: > > On 27/01/2015 01:34, Bob Weinand wrote: > >> > >> I'd like to request removal of the date.timezone warning. > >> > >> Here is the RFC: > >> https://wiki.php.net/rfc/date.timezone_warning_removal >

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

On Tue, 27 Jan 2015, Yasuo Ohgaki wrote: > While I can understand the reason behind opposition, but current web > is not bounded to local country. Most applications today logs time > using UTC and time stamp is converted whatever local time as needed, > isn't it? Of course, it depends on applic

Re: [PHP-DEV] [PATCH] Fix potential int overflow in date extension.

On Tue, 20 Jan 2015, Joshua Rogers wrote: > On 20/01/15 06:15, Joshua Rogers wrote: > > -- > > ext/date/lib/tm2unixtime.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > Somebody please take a look at /ext/date/lib/parse_tz.c too: > > 438timelib_sll timelib_get_current_offset(t

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

On Tue, 27 Jan 2015, Matteo Beccati wrote: > On 27/01/2015 01:34, Bob Weinand wrote: > > > > I'd like to request removal of the date.timezone warning. > > > > Here is the RFC: > > https://wiki.php.net/rfc/date.timezone_warning_removal > >

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

On Tue, 27 Jan 2015, Pierre Joye wrote: > On Jan 27, 2015 11:25 AM, "Yasuo Ohgaki" wrote: > > > > On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen > > wrote: > > > > > I think the warning is fair as it is, if it is annoying for small > > > use cases like on the CLI then simply: php -d dat

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

On Tue, 27 Jan 2015, Bob Weinand wrote: > I'd like to request removal of the date.timezone warning. > > Here is the RFC: > https://wiki.php.net/rfc/date.timezone_warning_removal > Absolutely not. cheers, Derick -- PHP Internals - PHP R

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

On Mon, 26 Jan 2015, Ferenc Kovacs wrote: > On Mon, Jan 26, 2015 at 3:45 PM, Sebastian Bergmann wrote: > > > Am 26.01.2015 um 13:56 schrieb Lester Caine: > > > how would YOU propose to replace it? > > > > I am not talking about replacing but removing. > > > I could accept that for pear (as comp

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fixes to unified stdint usage: ext/date/lib/timelib_structs.h main/php_stdint.h

On Wed, 21 Jan 2015, Anatol Belski wrote: > On Wed, January 21, 2015 11:57, Anatol Belski wrote: > > On Wed, January 21, 2015 11:17, Derick Rethans wrote: > > > >> On Wed, 21 Jan 2015, Anatol Belski wrote: > >> > >>> I'll backport it to 5.6. Also

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fixes to unified stdint usage: ext/date/lib/timelib_structs.h main/php_stdint.h

On Wed, 21 Jan 2015, Anatol Belski wrote: > I'll backport it to 5.6. Also would add the Pierre's suggestion so > those defines are only used when it's not inside PHP, as under > circumstances it could lead to different defines or conflicts. This is > easy done through the timelib_config.h inclu

[PHP-DEV] Re: [PHP-CVS] com php-src: Fixes to unified stdint usage: ext/date/lib/timelib_structs.h main/php_stdint.h

On Wed, 21 Jan 2015, Anatol Belski wrote: > On Tue, January 20, 2015 22:08, Derick Rethans wrote: > > > > This commit makes timelib include a PHP specific file. timelib also > > lives as an external library (https://github.com/derickr/timelib) > > and is used by o

Re: [PHP-DEV] PEAR and make install on master

On Mon, 19 Jan 2015, Pierre Joye wrote: > On Jan 19, 2015 5:14 PM, "Derick Rethans" wrote: > > > > On Sun, 18 Jan 2015, Sebastian Bergmann wrote: > > > > > Am 18.01.2015 um 09:40 schrieb Matteo Beccati: > > > > what's the plan, if any? &

Re: [PHP-DEV] PEAR and make install on master

On Sun, 18 Jan 2015, Sebastian Bergmann wrote: > Am 18.01.2015 um 09:40 schrieb Matteo Beccati: > > what's the plan, if any? > > Remove it? Then how would you install extensions? As there is no finished alternative, PEAR still needs to work. cheers, Derick -- PHP Internals - PHP Runtime Dev

Re: [PHP-DEV] Re: bison 3.0

On Mon, 19 Jan 2015, Pascal Chevrel wrote: > Le 11/12/2014 08:52, Sebastian Bergmann a écrit : > > > > I just updated my notebook to Fedora 21 and am no longer able to > > build PHP on it since I now have bison 3.0.2 instead of bison 2.7. > > > > bison 3.0 is blacklisted in Zend/acinclude

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

On Thu, 15 Jan 2015, Jordi Boggiano wrote: > On 14/01/2015 00:16, Andrea Faulds wrote: > > Here: https://wiki.php.net/rfc/scalar_type_hints > > > > This is a new thread because I’ve made a significant revision to the RFC, so > > it’d be sensible to separate discussion of the updated RFC from the

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

On Thu, 15 Jan 2015, Levi Morrison wrote: > On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds wrote: > > > > Upon further thought, I’m not super-enthusiastic about this. As has > > been pointed out, it’s a pretty serious BC break, whether code can > > be automatically updated or not. PHP 4 constru

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

On Sun, 11 Jan 2015, F & N Laupretre wrote: > Hi, > > A new RFC for PHP7 : https://wiki.php.net/rfc/array-to-string The voting options are missing in there. They should (probably) be: - don't change - 1st alternative - 2nd alternative cheers, Derick -- PHP Internals - PHP Runtime Developmen

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

On Wed, 7 Jan 2015, Pierre Joye wrote: > On Wed, Jan 7, 2015 at 2:14 PM, François Laupretre > wrote: > >> De : Pierre Joye [mailto:pierre@gmail.com] > >> > >> ... here, it is proposed to bundle scripts that will be executed at > >> runtime like any other script, except that nothing can be d

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

On Wed, 7 Jan 2015, François Laupretre wrote: > > De : Pierre Joye [mailto:pierre@gmail.com] > > > > ... here, > > it is proposed to bundle scripts that will be executed at runtime like any > > other script, except that nothing can be done with them, not even disable > > them if not required (

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

On Wed, 7 Jan 2015, Stanislav Malyshev wrote: > > There is currently no way to install an extension and a PHP library > > package at the same time. "pecl" can't install PHP libraries, and > > Why it needs to be "at the same time"? I don't see any use case where > it would matter if you run one

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

On Tue, 6 Jan 2015, Stanislav Malyshev wrote: > > But, if we consider the PHP code as an integral part of the > > extension, this should be avoided, as C and PHP code need to be kept > > in sync. > > Again, there is a multitude of solutions for this, all in the realm of > packaging. It's not l

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

On Tue, 6 Jan 2015, François Laupretre wrote: > > De : Pierre Joye [mailto:pierre@gmail.com] > > > 2. We have no easy way to actually release and deploy adhoc scripts, > > used by a given extension > > > > For 2., it is one of the thing I can imagine implementing in pickle. > > Or even bette

Re: [PHP-DEV] Cleaning up dangling whitespace

On Tue, 6 Jan 2015, Nikita Popov wrote: > On Mon, Jan 5, 2015 at 11:58 PM, Stanislav Malyshev > wrote: > > > The code in the PHP source repo has a lot of random dangling > > whitespace at the end of lines, which looks sloppy and produces some > > weird effects in diffs because some editors aut

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

On Mon, 5 Jan 2015, Stanislav Malyshev wrote: > > 2) Embedded text sections. It's possible to place the raw PHP code > > into the compiled .so/.dylib/.dll file and fetch it out for > > compilation at runtime. This enables easy bundling of the loaded > > I guess it is possible, but why - what's

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

On Wed, 31 Dec 2014, Stanislav Malyshev wrote: > > The issue is the class names though. E.g. see: > https://github.com/ralphschindler/zf2-db/blob/master/research/ColumnType/Integer.php That's in a namespace, so it's not actually Integer, but Zend\Db\Metadata\Type\Integer > and: > > https://g

Re: [PHP-DEV] ZEND_ENGINE_2 define

On Fri, 2 Jan 2015, Sara Golemon wrote: > > > It was deliberate, I did it. The reason for getting rid of it was because > > it makes checking ZE2 simpler, actually. I didn't want to have to do #if > > defined(ZEND_ENGINE_2) && !defined(ZEND_ENGINE_3). > > > So instead you have to do: > #if def

Re: [PHP-DEV] [RFC] Add is_cacheable() stream-wrapper operation

On Sun, 4 Jan 2015, François Laupretre wrote: > I just wrote this RFC to propose a clean way for opcode caches to > decide if a given URI is cacheable or not : > > https://wiki.php.net/rfc/streams-is-cacheable > > Please comment. I don't see why you need the define if it's always available. Ex

Re: [PHP-DEV] Line profiler for PHP

On Tue, 23 Dec 2014, Stanislav Malyshev wrote: > > The questions I have are: - Is this even possible? > > Yes, should be possible but: > 1. If you want precision, it would slow down your code a lot, as > basically you need to record timing of each opcode, which can be very > expensive. > 2. If yo

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

On Tue, 16 Dec 2014, Ferenc Kovacs wrote: > > > - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not > > > new features cancels point number one > > > > > > What else ? > > > > Do nothing is still (IMHO) the most sensible option IMHO. We're not > > seeing major compatibility bre

Re: [PHP-DEV] [RFC][VOTE] Objects as Keys

On Tue, 16 Dec 2014, Stanislav Malyshev wrote: > I'd like to initiate a vote on "objects as keys" RFC: > https://wiki.php.net/rfc/objkey I wonder why you opened voting on this, before resolving the "Open Issues": Open Issues Should SplFixedArray support object indexes? Should SplObject

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

On Sun, 14 Dec 2014, George Bond wrote: > If you wanted an upgrade path that was not Evil (in the sense of not > introducing subtle and hard-to-diagnose bugs), could you not change > the operator to be *un*associative in PHP7? That would effectively > just make concrete the discouragement/depr

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

On Sat, 13 Dec 2014, Pierre Joye wrote: > On Dec 12, 2014 9:34 PM, "Derick Rethans" wrote: > > > > On Fri, 12 Dec 2014, Julien Pauli wrote: > > > > > So the main question is : *What version will we release next year ?* > > > > &

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

On Fri, 12 Dec 2014, Ferenc Kovacs wrote: > On Fri, Dec 12, 2014 at 3:34 PM, Derick Rethans wrote: > > > > On Fri, 12 Dec 2014, Julien Pauli wrote: > > > > > So the main question is : *What version will we release next year > > > ?* > > > > &g

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

On Sat, 13 Dec 2014, Leon Sorokin wrote: > I was wondering if 7.0 could be the version to fix the long-standing > incorrect ternary associativity bug in PHP [1]. It is not a bug, as the issue's status says: "Not a bug". > This seems especially worthy of reconsideration since the Null > Coalesc

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

On Fri, 12 Dec 2014, Julien Pauli wrote: > So the main question is : *What version will we release next year ?* > > Will we have a PHP 5.7, or jump directly to a 7.0 ? > > Don't forget, that if we go for a 5.7 , then we won't have a 7.0 at > least one year later. We have accepted the timeline

Re: [PHP-DEV] libmcrypt: abandonware?

On Wed, 10 Dec 2014, Andrea Faulds wrote: > > On 10 Dec 2014, at 06:33, Remi Collet wrote: > > > > Having a dead upstream for crypto API is a critical issue :( > > > > FYI some downstream (ex RHEL) don't even provide this library. > > Already too much crypto libraries, and it will be a mess to

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

On Tue, 9 Dec 2014, Andrea Faulds wrote: > I think \x{} is misleading anyway - \xXX is always > single-byte/character, yet Unicode code points can’t be represented in > PHP strings as single bytes when encoded in UTF-8 (unless they’re > below U+0100, of course). You mean below U+0080 surel

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

On Tue, 25 Nov 2014, Dmitry Stogov wrote: > On Tue, Nov 25, 2014 at 1:00 PM, Andrea Faulds wrote: > > > > > > On 25 Nov 2014, at 08:33, Dmitry Stogov wrote: > > > > > > May be I misunderstood something, but why to introduce unicode escapes > > if PHP engine doesn't support Unicode. > > > > We d

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

On Mon, 24 Nov 2014, 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, and r

Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions

On Mon, 24 Nov 2014, Sara Golemon wrote: > While playing around with Andrea's unicode literals syntax proposal, I > was reminded of just how little of ICU is exposed. I've put up a > short proposal for adding IntlChar exporting these APIs as static > methods (with a matching non-oop interface). >

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

On Wed, 19 Nov 2014, Andrea Faulds wrote: > Good evening, > > I am putting the Safe Casting Functions RFC to a vote. > > https://wiki.php.net/rfc/safe_cast#vote > > Voting starts today (2014-11-19) and ends in 10 days’ time (2014-11-29). > > Since some things might have changed since you last

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

On Tue, 18 Nov 2014, Stanislav Malyshev wrote: > Hi! > > I'd like to propose the following RFC, which in short would allow any > method to call parent ctor (and some other methods) even if such is not > explicitly defined: > > https://wiki.php.net/rfc/default_ctor > > The reasons are outlined i

[PHP-DEV] PHPDBG scope

Hi, This is based on an email conversation between Joe Watkins and me. I asked him what the original scope of phpdbg was, and I've summarized his reply here: - PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb like commands to debug, and step through code. - Support for b

Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sun, 26 Oct 2014, Bob Weinand wrote: > > > Am 26.10.2014 um 16:09 schrieb Derick Rethans : > > > > On Sat, 25 Oct 2014, Joe Watkins wrote: > > > >> On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: > >>> On Fri, 24 Oct 2014, Bob Weina

Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sun, 26 Oct 2014, Bob Weinand wrote: > > Am 26.10.2014 um 16:22 schrieb Derick Rethans : > > > > On Sat, 25 Oct 2014, Joe Watkins wrote: > > > >> We will notify internals of our intentions to make such changes in > >> future, if we thought t

Re: [PHP-DEV] VCS Account Request: jbafford

On Tue, 28 Oct 2014, John Bafford wrote: > I would like access to edit the wiki and submit RFCs. I've given you access to the wiki's RFC space. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sun, 26 Oct 2014, Andrea Faulds wrote: > > > On 26 Oct 2014, at 15:09, Derick Rethans wrote: > > > > On Sat, 25 Oct 2014, Joe Watkins wrote: > > > >> On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: > >> > >> A few weeks a

Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sat, 25 Oct 2014, Joe Watkins wrote: > We will notify internals of our intentions to make such changes in > future, if we thought there was any chance of any feedback before today, > we would already be doing so. "We will notify internals". Really? Sadly, this phpdbg stuff is part of internal

Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sat, 25 Oct 2014, Stas Malyshev wrote: > That said, we are where we are, and I think it would be great if this > would somehow server as a starting point for developing a unified > protocol for debugging PHP. It already exists: DBGp. It's implemented by dozens of editors and plugins. cheer

Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sat, 25 Oct 2014, Leigh wrote: > On 25 October 2014 12:00, Weinand Bob wrote: > > ... > > Thanks Bob. > > So my question is: Obviously the phpdbg requirements do not map to > DBGp. However, can all of the requirements of DBGp be mapped to the > phpdbg XML? > > Going forward does the XML p

Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sat, 25 Oct 2014, Weinand Bob wrote: > Just a minor question, Derick. If you care about phpdbg, why are you > only dropping any comment about it by the time it got into php-src > repo? Yes, my mistake. I should have voted -1, but as I thought there was a conflict of interest, I stayed silen

Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sat, 25 Oct 2014, Joe Watkins wrote: > On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: > > On Fri, 24 Oct 2014, Bob Weinand wrote: > > > > > Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 > > > Author:Bob Weinand Fri, 24 Oct 2014 &

[PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Fri, 24 Oct 2014, Bob Weinand wrote: > Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 > Author:Bob Weinand Fri, 24 Oct 2014 > 19:29:50 +0200 > Parents: 53560ca06b333b71883269091f7d74c0a25e087b > c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d > Branches: master > > Link:

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

On Mon, 20 Oct 2014, Andrea Faulds wrote: > Good evening, > > I am presenting a new RFC to add a set of three functions to do validated > casts for scalar types: > > https://wiki.php.net/rfc/safe_cast > > Please read it. > > The functions return FALSE on failure instead of NULL because: > > -

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

On Sat, 11 Oct 2014, Nikita Popov wrote: > Hi internals! > > We currently have a number of deprecated features, which we likely want to > remove in PHP 7. I've created a tracking RFC listing deprecated > functionality (if I missed something, please tell): > > https://wiki.php.net/rfc/remove_

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

On Sat, 11 Oct 2014, Kris Craig wrote: > On Oct 11, 2014 1:52 PM, "Nikita Popov" wrote: > > > > We currently have a number of deprecated features, which we likely > > want to remove in PHP 7. I've created a tracking RFC listing > > deprecated functionality (if I missed something, please tell):

Re: [PHP-DEV] [RFC] Move pecl_sync to core

On Tue, 30 Sep 2014, Remi Collet wrote: > Le 30/09/2014 05:06, guilhermebla...@gmail.com a écrit : > > > > Here is a new RFC: https://wiki.php.net/rfc/sync > > Isn't this extension a bit "young" to join php core ? I'd say both that, and that the RFC is *very* minimal. THere is no rationale why

Re: [PHP-DEV] Should we dev on master then backport, or the other way?

On Fri, 26 Sep 2014, Ferenc Kovacs wrote: > On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine > wrote: > > > The question is in the title :-) > > > > As far as I know, most projects follow this convention: develop on > > the master branch, then backport the fixes/features to older > > versions

[PHP-DEV] Why break BC if you don't have to‽ (Was: Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency)

On Thu, 25 Sep 2014, Lars Strojny wrote: > On 25 Sep 2014, at 17:27, Patrick ALLAERT wrote: > [...] > > > > I'm in favor of disabling for consistency as well, however, I wish a > > warning would be emitted. > > Voted in favour of disabling as well but could easily live with the > other option

Re: [PHP-DEV] [VOTE][RFC] Integer Semantics

On Mon, 22 Sep 2014, Michael Wallner wrote: > On 2014-09-22 14:08, Andrea Faulds wrote: > > > > On 22 Sep 2014, at 12:06, Derick Rethans wrote: > > > >> I would also like to point out that, just like a 8:8 vote is not a > >> "50% majority

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

On Mon, 22 Sep 2014, Andrey Andreev wrote: > On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds wrote: > > > > On 22 Sep 2014, at 12:32, Derick Rethans wrote: > > > >> On Sat, 20 Sep 2014, Andrea Faulds wrote: > >> > >>> Perhaps I’m being unfair an

<    2   3   4   5   6   7   8   9   10   11   >