Re: [PHP-DEV] Built-in classes that cannot be serialized

Am 26.11.2018 um 13:35 schrieb Nikita Popov: If I can rely on classes to throw an exception when serialize() is performed (be it through zend_class_serialize_deny or in __sleep()) then, yes, I can just try it. I believe you can rely on this. Not on any specific exception type, but the fact that

Re: [PHP-DEV] Built-in classes that cannot be serialized

Am 26.11.2018 um 12:20 schrieb Nikita Popov: Apart from serialize_deny, a pretty common pattern is throwing __wakeup. See for example CURLFile. We should migrate such cases to serialize_deny though. I think it's pretty weird to explicitly implement __wakeup (signalling that yes, you can be unser

[PHP-DEV] Built-in classes that cannot be serialized

The following classes register zend_class_serialize_deny: Closure, COM, DOTNET, Generator, HashContext, Reflection, ReflectionClass, ReflectionClassConstant, ReflectionExtension, ReflectionException, ReflectionFunction, ReflectionFunctionAbstract, ReflectionGenerator, ReflectionMethod, Reflecti

Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2

Am 26.09.2018 um 15:46 schrieb Nikita Popov: I'm pleased to announce that the typed properties RFC has been accepted with 70 votes in favor and one vote against. We will work to finalize and merge the implementation in the next few days. Any update on when this will be merged? Thanks! -- PHP I

Re: [PHP-DEV] Composition over inheritance: native support for "delegating" methods?

Am 21.10.2018 um 23:42 schrieb Marco Pivetta: 1. the language already has all the tooling required to implement decorators correctly 2. the addition of a `delegate` functionality would cause more confusion for something that is already really trivial to implement/test/read ACK -- PHP Inter

[PHP-DEV] Re: [PHP-CVS] com php-src: Mark "top-level" functions.: Zend/zend_compile.c Zend/zend_compile.h

Am 19.10.2018 um 12:22 schrieb Dmitry Stogov: Mark "top-level" functions. What are top-level classes or functions? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Preloading

Am 19.10.2018 um 16:19 schrieb Sara Golemon: Thank you for everything you do. Hear, hear. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Pre proposal for "Class extension functions"

On 9/25/18 10:48 PM, Sara Golemon wrote: > I've been back-burnering this for a few days and I'm with Stas. I > don't like this proposal because it adds complexity with relatively > little benefit. I only see problems (mostly due to added complexity) and no benefits. -1 from me. -- PHP Internals

Re: [PHP-DEV] [RFC} Deprecate and Remove ext/wwdx

On 9/16/18 12:48 PM, Christoph M. Becker wrote: > Finally, I hereby put the “Deprecate and Remove ext/wwdx” RFC[1] under > discussion. +1. I have never seen this used anywhere. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GCC -foptimize-strlen and bug #76510

On 09/08/2018 01:14 PM, Christoph M. Becker wrote: > I don't think it makes sense to disable optimize-strlen > for individual files only, but I rather suggest to check whether > optimize-strlen is broken, and if so to add -fno-optimize-strlen to the > CFLAGS (etc.) Makes sense to me. -- PHP Inte

Re: [PHP-DEV] GCC -foptimize-strlen and bug #76510

On 08/04/2018 11:51 PM, Nikita Popov wrote: > More likely than not this is a bug on our side triggered by this > optimization, not a bug in GCC. A run through valgrind might reveal > something. Valgrind information has been added to https://bugs.php.net/bug.php?id=76510. Can an optimization such

Re: [PHP-DEV] [RFC] Typed Properties

As such, I think that this feature can only go into 7.3 if the release schedule is adjusted. Extending the schedule by another 2-week alpha cycle would be sufficient to land this proposal in PHP 7.3. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.ph

Re: [PHP-DEV] Strict switch statements

Am 14.06.2018 um 10:35 schrieb Nikita Popov: > It might make sense to introduce an entirely new "match" statement > that conforms a bit more with how switch-like strictures are > implemented nowadays. That is, something like > > match ($expr) { > "foo" => {...}, > "bar" | "baz" => {...}, >

Re: [PHP-DEV] [VOTE] Make compact function reports undefined passed variables

Am 09.06.2018 um 12:03 schrieb Dmitry Stogov: > They might be considered to be removed in the next major PHP version, despite > of this fix. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Parse error: Invalid body indentation level

Am 28.05.2018 um 22:16 schrieb Nikita Popov: > Good point, I have added a note in UPGRADING in > https://github.com/php/php-src/commit/c70468b8d3c1d6711da0db84cba30d87d2482e5c Thank you so much, Nikita! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php

Re: [PHP-DEV] Parse error: Invalid body indentation level

Am 28.05.2018 um 14:51 schrieb Nikita Popov: > Yes, this is an expected result under the flexible heredoc RFC. To avoid > issues, please use a heredoc label that does not occur within the string. Hmkay, so code that worked fine with PHP 7.1 and PHP 7.2 breaks with PHP 7.3. This breaking change sho

[PHP-DEV] Parse error: Invalid body indentation level

Hi! https://github.com/sebastianbergmann/diff/blob/master/tests/ParserTest.php#L79 triggers a Parse error: Invalid body indentation level (expecting an indentation level of at least 1) in /path/to/ParserTest.php on line 79 with current PHP 7.3.0-dev (master); the code in question works fine with

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

Am 10.01.2018 um 16:04 schrieb Rasmus Lerdorf: > Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen > and others are doing working on the core of PHP. I agree. IIRC, last time optional type declarations for attributes were discussed Dmitry optimized/refactored something in t

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

Am 02.01.2018 um 14:37 schrieb Chris Riley: > How useful is "scalar" as a type hint? I'm not sure it provides any benefit > over "mixed". scalar has the benefit of exluding arrays, objects, and resources. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.p

Re: [PHP-DEV] Mailing list moderation

Am 02.01.2018 um 11:49 schrieb Nikita Popov: > I would like to request a mailing list suspension for the users > tonymars...@hotmail.com and li...@rhsoft.net, who have recently been > aggressively derailing the "Scalar Pseudo-type" thread, despite requests to > moderate their participation both in

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

Am 29.12.2017 um 16:37 schrieb Nikita Popov: > Having an explicit number type also goes well with an explicit number cast. > PHP internally has a notion of a number cast (which is the basis for > arithmetic operations), but currently does not expose it. As such, number > casts currently have to be

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

Am 29.12.2017 um 18:30 schrieb li...@rhsoft.net: > "i don't see a benefit, i don't like it" are no valid reasons to do so I strongly disagree. If a majority of people do not see the benefit of a syntax change then the syntax should not be changed. A change to the syntax of PHP has a ripple effect

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

Am 26.12.2017 um 16:46 schrieb li...@rhsoft.net: > would you mind to explain this? "Foo|Bar", "array|string", etc. (still) make no sense to me. "scalar" makes sense to me although it is but an alias for "bool|float|int|string". -- PHP Internals - PHP Runtime Development Mailing List To unsubscr

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

Am 24.12.2017 um 15:34 schrieb Fleshgrinder: > I prepared a PR to add the `scalar` pseudo-type to PHP after the > discussions around adding a `mixed` pseudo-type. I strongly believe that > it makes sense to provide the most common primitive union types with > handy aliases even if we are going to a

Re: [PHP-DEV] [RFC] Mixed Typehint

On 12/20/2017 02:17 PM, li...@rhsoft.net wrote: [...] Off topic: I find it rude that you are posting to this list without providing a real name. what you are talking about are unions statet multiple times in this thread No, I was not talking about union types. What I talked about could be

Re: [PHP-DEV] [RFC] Mixed Typehint

On 12/19/2017 04:34 AM, Michael Moravec wrote: I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: https://wiki.php.net/rfc/mixed-typehint "mixed" is too unspecific. I understand the reasoning behind wanting "mixed": to express explicitly that a type declaration was not forgotten.

Re: [PHP-DEV] [RFC] Reproducible Builds Support

Am 15.12.2017 um 11:13 schrieb Jordi Boggiano: > I guess an alternative fix would be for someone to actually fix the Phar > extension so addFromString has a filemtime parameter you can pass the > desired mtime to. I have not checked whether addFile suffers from the same > issue or not, but possibly

Re: [PHP-DEV] Re: PHP 7.2 and bcmod()

Am 05.12.2017 um 13:19 schrieb Christoph M. Becker: >> Am I missing something? > > As usual, the results depend on the scale factor (which is 0 by > default); see . Thank you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.n

[PHP-DEV] PHP 7.2 and bcmod()

http://git.php.net/?p=php-src.git;a=blob_plain;f=UPGRADING;hb=refs/heads/PHP-7.2 has this to say on bcmod(): > The bcmod() function no longer truncates fractional numbers > to integers. As such, its behavior now follows fmod() rather than > the `%` operator. For example `bcmod('4', '3.5')` now ret

Re: [PHP-DEV] PHP 7.0.26 is available

Am 29.11.2017 um 10:35 schrieb Anatol Belski: > 7.0.27 is planned as the last release with the active support. Some patches > sit there to be released with this version. Thank you for the quick reply, Anatol. Do we already have a scheduled release date for PHP 7.0.27? -- PHP Internals - PHP Run

Re: [PHP-DEV] PHP 7.0.26 is available

Am 23.11.2017 um 17:40 schrieb Anatol Belski: > The PHP development team announces the immediate availability of PHP 7.0.26. > Several bugs have been fixed. All PHP 7.0 users are encouraged to upgrade to > this version. Is this the last PHP 7.0 release with bug fixes (active support for PHP 7.0

[PHP-DEV] Re: [PHP-CVS] com php-src: ext/sodium: throw exceptions instead of errors: ext/sodium/libsodium.c

Am 28.11.2017 um 13:56 schrieb Frank Denis: > Commit:c05cbd1e775fa69ed9939796a908390f2bfb4459 > Author:Frank Denis Tue, 28 Nov 2017 > 13:56:11 +0100 > Parents: c219991c77e4c68f7d62963e18a1da778de0bbe0 > Branches: PHP-7.2 > > Link: > http://git.php.net/?p=php-src.git;a=c

Re: [PHP-DEV] PHP's mail servers suck

Am 26.10.2017 um 13:31 schrieb Florian Anderiasch: > Mailing lists in general are fine, the problem at hand really is the > php.net mail infrastructure, so I'd suggest sticking to solving that > problem. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www

Re: [PHP-DEV] Strict type declarations not enforced for Reflection API invocation

Am 10.10.2017 um 18:53 schrieb Nikita Popov: > The problem are not internal function calls, the problem are callbacks. In > fact, the proposed fix does not actually fix the problem you encountered in > PHPUnit, as it is going to use the strictness mode at the reflection > call-site, not the strictn

[PHP-DEV] Strict type declarations not enforced for Reflection API invocation

https://bugs.php.net/bug.php?id=75345 is about the fact that strict type declarations are not enforced when a function or method is invoked via the Reflection API. There is a pull request that addresses this (as well as https://bugs.php.net/bug.php?id=74750) at https://github.com/php/php-src/pull/

Re: [PHP-DEV] WDDX serialization and security

Am 11.08.2017 um 15:15 schrieb Nikita Popov: > I'm wondering if it might be time to remove (i.e. deprecate and move to > PECL) the wddx extension? I have never seen it used in the wild. So +1 from me for deprecation in 7.2 and removal in 8.0. -- PHP Internals - PHP Runtime Development Mailing Li

[PHP-DEV] OBJECT_OPERATOR vs. DOUBLE_COLON

Is it intentional that the DOUBLE_COLON operator can be used on a variable that contains a reference to an object? Until yesterday I thought that only the OBJECT_OPERATOR (->) can be used on a variable that contains an object. https://3v4l.org/59Xap proved me wrong. As the deprecation / stri

Re: [PHP-DEV] PHP_OS_FAMILY and macOS

Am 13.06.2017 um 15:00 schrieb Zeev Suraski: > Yep, Mac sounds like a fairly future-proof choice, and is also consistent > with the capitalization of other options. Implemented in http://git.php.net/?p=php-src.git;a=commitdiff;h=362d2e42a02fe018a7d1261a53ff59b73fed91f6 -- PHP Internals - PHP Ru

Re: [PHP-DEV] PHP_OS_FAMILY and macOS

Am 13.06.2017 um 14:40 schrieb Derick Rethans: > Changing it surely means breaking BC? I believe we should continue to > use OSX. PHP_OS_FAMILY is new in PHP 7.2, which is not final yet. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP_OS_FAMILY and macOS

Thinking about https://github.com/sebastianbergmann/environment/issues/21 it just occured to me that PHP_OS_FAMILY currently contains "OSX". Apple renamed (last year?) their "OS X" to "macOS". Should PHP_OS_FAMILY not contain "macOS" then? Now would be the time to make that change without breaking

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

Am 12.06.2017 um 08:14 schrieb Davey Shafik: > It would be best to just kill the vote and start over. The proposal should > be for deprecation notice in 7.2 and implementation in 8.0 IMO — it should > be one vote, as doing both together should be the only option. +1 -- PHP Internals - PHP Runtim

Re: [PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

Am 07.06.2017 um 13:31 schrieb Derick Rethans: > I voted no because of the BC break. Same. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

On 05/17/2017 11:30 PM, Marco Pivetta wrote: Is Sebastian copied in here? Why can't we just use the super-battle-tested PHPUnit? It supports phpt and a ton of plugins, plus everyone uses it and is familiar with it. IMO, PHPUnit is not the right tool to test PHP itself. Yes, it supports a subse

Re: [PHP-DEV] [RFC] [VOTE] Object typehint RFC

On 05/17/2017 04:47 PM, Levi Morrison wrote: An emphatic "no" on variance for me. This is for two over-arching reasons: Thank you, Levi, for the explanation of your "no" vote on object variance. That saved me quite a bit of typing :-) -- PHP Internals - PHP Runtime Development Mailing List T

Re: [PHP-DEV] HYBRID VM

Am 03.05.2017 um 10:08 schrieb Dmitry Stogov: > Please review https://github.com/php/php-src/pull/2507 I was able to successfully run PHPUnit's own test suite using the hybrid VM. PHP 7.2 with Hybrid VM is about 4% faster compared to PHP 7.1 for this. -- PHP Internals - PHP Runtime Development M

Re: [PHP-DEV] HYBRID VM

Am 03.05.2017 um 10:08 schrieb Dmitry Stogov: > I propose a new VM instruction dispatch technique Can we add information about the VM used to phpinfo() and/or --version output? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.2 Release Managers

Am 11.04.2017 um 17:13 schrieb Joe Watkins: > Let me be the first to congratulate them: congrats you two. Hear, hear! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.2 Release Managers

On 03/28/2017 05:11 PM, Sara Golemon wrote: I keep meaning to have a go at this, and with such inspiring mentors at the ready, there's really no better time than now. +1 :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: TOKEN_AS_OBJECT for token_get_all()

Am 24.03.2017 um 00:33 schrieb Sara Golemon: > If I may bikeshed a TINY bit, I'd ask that all tokens return as > objects, rather than char|PhpToken similar to the current char|array > format we have. Yes, please. That would basically/probably/hopefully make php-token-stream superfluous. -- PHP I

[PHP-DEV] Let range() return a generator?

For me, foreach (range($low, $high) as $i) is easier to understand than for ($i = 0; $i <= $high; $i++) By easier to understand I do not only mean that the beginning of the loop marked by the foreach/range construct is easier to read. While reading the body of the loop I can be sure

Re: [PHP-DEV] Add __toArray() method to objects that would be called on cast to array

Am 15.03.2017 um 23:33 schrieb Marco Pivetta: > Also the only way to get all properties from an instance of an inheritance > tree. I use the Reflection API in https://github.com/sebastianbergmann/object-reflector/blob/master/src/ObjectReflector.php#L24 for retrieving inherited non-public attribut

Re: [PHP-DEV] generating code from AST

Am 07.03.2017 um 11:33 schrieb Derick Rethans: > Because installing an extension is too hard? No. To ensure that userland functionality that is based on compiler internals (token stream, abstract syntax tree, bytecode) does not fall out of sync with the compiler. We already have an extension that

Re: [PHP-DEV] generating code from AST

Am 07.03.2017 um 07:01 schrieb David Walker: > When/if there are changes to AST, having a tool like these in core would > require them to be updated at the same time. Exactly. > Would this concept also want to extend to a VLD-esque extension as well for > the same reasons? I'd be receptive for

Re: [PHP-DEV] generating code from AST

Am 06.03.2017 um 22:40 schrieb Sara Golemon: > https://github.com/sgolemon/astkit There's also https://github.com/nikic/php-ast. But wouldn't it be great if PHP 7.2 shipped with a built-in, enabled-by-default extension for AST operations? -- PHP Internals - PHP Runtime Development Mailing List

[PHP-DEV] Re: [PHP-CVS] com php-src: Bug Fix: Corrupted class entries on shutdown when a destructor spawns another object (C) 2017 CommerceByte Consulting: Zend/zend_objects_API.c Zend/zend_objects_AP

Am 07.02.2017 um 00:05 schrieb Dmitry Stogov: > Commit:9a8a1c9da129a72c9bf8f3392f954a9e5ca317ff > Author:Jim Zubov Mon, 6 Feb 2017 18:05:34 > -0500 > Parents: 31332d094127b6332018cd146b9becbd7566e60c > Branches: master > > Link: > http://git.php.net/?p=php-src.git;a=com

Re: [PHP-DEV] Fwd: Type Collection

Am 28.01.2017 um 17:10 schrieb Niklas Keller: > sounds like everything you want is typed arrays? I would love typed arrays. Basically Foo[] to indicate an array of objects of type Foo. IDEs such as PhpStorm as well as documentation tools already support this syntax when used in docblocks. -- PH

[PHP-DEV] PHPUnit's tests fail with PHP 7.1.2-dev

Hi! Does anybody have an idea what changed between PHP 7.1.1 and the current state of the PHP 7.1 branch that would explain https://github.com/sebastianbergmann/phpunit/issues/2454? Thanks, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.n

[PHP-DEV] Re: [PHP-CVS] com php-src: Introduced "zend_type" - an abstraction for type-hinting representation.: Zend/zend_API.c Zend/zend_API.h Zend/zend_builtin_functions.c Zend/zend_compile.c Zend/ze

On 01/13/2017 09:37 AM, Dmitry Stogov wrote: Commit:141d1ba9801f742dc5d9ccd06e02b94284c4deb7 Author:Dmitry Stogov Fri, 13 Jan 2017 11:37:46 +0300 Parents: 28391c30ca008013267592ab2a2eebce3da3f3b0 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=

Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch

Am 12.01.2017 um 08:11 schrieb Tim Bezhashvyly: > Disallow explicit call of __construct method I am baffled that this (still) works: $ cat /tmp/t.php __construct(); $ php /tmp/t.php C::__construct C::__construct $ php --version PHP 7.1.0 (cli) (built: Dec 1 2016 07:39:00) ( NTS ) Copyright (

Re: [PHP-DEV] bugsnet cleanup

Am 08.01.2017 um 07:46 schrieb Joe Watkins: > I think any bug report opened against 4 and not updated is useless. +1 > I think anything with a patch attached targeting 5 is useless, regardless > of age; they should be encouraged to open a pull request on github against > a supported branch. +1

Re: [PHP-DEV] PHP 7.1.0 GA

On 11/22/2016 07:36 PM, Joe Watkins wrote: It has taken a lot of hard work from a lot of people, so stop whatever you are doing and give those people a round of applause. /clap :-) Thanks to everyone involved! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

Am 18.10.2016 um 08:23 schrieb Sara Golemon: > I'm mostly curious about thoughts on API decisions. Can we make the constructor non-public and instead only have named constructors? * public static function createFromBinary(string $number): BigNum; * public static function createFromInteger(int $nu

Re: [PHP-DEV] Reflection API and Nullable Types

On 10/11/2016 07:27 AM, Stanislav Malyshev wrote: I hope it's string(3) otherwise we have a bug on our hands That was a copy/pasta/no-adapt mistake, my bad. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Reflection API and Nullable Types

At some point in time during the development of PHP 7.1 this code function f(?int $x) { } $f = new ReflectionFunction('f'); var_dump((string) $f->getParameters()[0]->getType()); var_dump($f->getParameters()[0]->getType()->getName()); printed string(4) "?int" string(3) "int" an

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

Am 05.09.2016 um 12:13 schrieb Derick Rethans: > You can't really ship PHP without a way to install extensions though! Why not? IMHO, PHP should not be shipped with any tool for installing PHP components (PEAR Installer, Composer, ...) or extensions (PECL Installer, ...). In my experience, peop

Re: [PHP-DEV] [RFC] orphan extensions cleanup

Am 15.08.2016 um 10:17 schrieb Kalle Sommer Nielsen: > tokenizer > Like you mentioned, I think this should be kept in the core and > possibly maintained as a part of the parser. I do write some > development tools every now and then and make use of this amazing > extension and will only want it to

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

Am 24.06.2016 um 12:20 schrieb Dmitry Stogov: > Please review the RFC https://wiki.php.net/rfc/async_signals Would this alleviate the fact that ticks are broken in PHP 7? See https://github.com/sebastianbergmann/phpunit/issues/2205 for what I use ticks for in PHPUnit. -- PHP Internals - PHP Runt

Re: [PHP-DEV] [RFC] [VOTE] Union types

On 06/14/2016 08:52 PM, Zeev Suraski wrote: > I'm personally against Union types because it makes no sense for classes, and > for scalars we're better off with dedicated solution a (e.g. "numeric"); Same reason I voted no. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning with "Too few arguments" exception

On 06/06/2016 12:07 PM, Derick Rethans wrote: >> It's a shame it didn't make it for 7.0, but in my opinion, this should now >> wait for 8.0. > I agree with that statement, and hence voted "No". Same reason I voted no. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Exception::getLine()

Am 19.05.2016 um 13:14 schrieb Rasmus Schultz: > Does this work as intended? According to https://bugs.php.net/bug.php?id=64910 it does :-( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Forbid dynamic calls to scope introspection/modification functions

Am 29.04.2016 um 11:48 schrieb Nikita Popov: > Welcome to another edition of "crazy PHP edge-cases you don't want > to know about". I love and hate these edge cases at the same time :) > I'd like to introduce a restriction that forbids performing dynamic calls > to scope introspection and modific

Re: [PHP-DEV] [VOTE][RESULTS] 7.1 RMs selection

Am 03.05.2016 um 23:36 schrieb Anatol Belski: > Congrats and godspeed, guys! Hear, hear! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Pipe Operator

Am 30.04.2016 um 01:37 schrieb Bob Weinand: > TL;DR: > -1: The |> pipe operator encourages a write-only style. I second that emotion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

On 04/21/2016 11:13 PM, Dmitry Stogov wrote: > I would like to present an RFC proposing support for native annotation. Dmitry, please use "annotation" as the name for this feature and not "attribute". We already have attributes: it's what we use to store data in objects. And while some people ca

[PHP-DEV] UUID

In PHP 7.0 we introduced random_bytes() which wraps Linux's getrandom(2) as well as Windows's CryptGenRandom() and uses /dev/urandom as a fallback. I think it would be great if we added a function that wraps /proc/sys/kernel/random/uuid [2] and, if that exists, its equivalent on Windows to make th

Re: [PHP-DEV] Final properties

Am 09.04.2016 um 12:55 schrieb Niklas Keller: > Another possible choice would be "readonly". Rather "writeonce", no? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuring assignment

Am 07.04.2016 um 14:21 schrieb Andrea Faulds: > Please tell us your thoughts. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Final properties

Am 05.04.2016 um 11:13 schrieb Marco Pivetta: > First of all: +1 to this: very useful for value objects! My thought exactly. > do we want to use `final`, or `immutable` for these properties? I have the same sentiment you have, that "final" would be confusing and "immutable" would be better.

Re: [PHP-DEV] IntlCharsetDetector

Am 05.04.2016 um 11:05 schrieb Derick Rethans: > I would advice against adding this. > > As you say, it doesn't work properly. As a matter of fact, guessing > charsets, like timezones, is not possible. You need to know which > charset something is in. If not, you need to address *that* problem.

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

On 02/18/2016 02:10 PM, Colin O'Dell wrote: I'd like to propose an RFC to deprecate and eventually remove the "var" keyword. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Traits with interfaces

Am 17.02.2016 um 15:25 schrieb Kevin Gessner: > Hello internals team! I'd like to propose an RFC to allow traits to > implement interfaces. I think that would violate "The Flattening Property" [1], meaning that the fact that a class uses a trait must not be noticable by a user of that class.

Re: [PHP-DEV] Re: CATCH in master (vs 7.0)

Am 20.12.2015 um 21:53 schrieb Nikita Popov: > For VLD you should hide the value if opline->result.num is set, similar to > what zend_dump does: Is zend_dump() callable from userland? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Added e-SSA based DFA optimisation framework (incomplete): ext/opcache/Optimizer/block_pass.c ext/opcache/Optimizer/dfa_pass.c ext/opcache/Optimizer/zend_cfg.c

Am 15.12.2015 um 09:30 schrieb Dmitry Stogov: > If I remember properly, e-SSA was introduced in this paper: "ABCD: > Eliminating Array Bounds Checks on Demand" > > http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=DD8C76953A60E6ECBC1DED02CFC8011C?doi=10.1.1.33.6934&rep=rep1&type=pdf > > Th

[PHP-DEV] Re: [PHP-CVS] com php-src: Added e-SSA based DFA optimisation framework (incomplete): ext/opcache/Optimizer/block_pass.c ext/opcache/Optimizer/dfa_pass.c ext/opcache/Optimizer/zend_cfg.c ext

On 12/11/2015 03:24 PM, Dmitry Stogov wrote: Commit:f243aaf9856fcbfdb08a59ff08f22cf48647cfc0 Author:Dmitry Stogov Fri, 11 Dec 2015 17:24:55 +0300 Parents: 5d2e287982c5986daa154fa1dae2d0be7f6965fa Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

Am 08.12.2015 um 16:14 schrieb Zeev Suraski: > I prepared an RFC that proposes to extend the support periods for PHP 5.6 Thank you for your work on this RFC, Zeev. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 5.6 life cycle

Am 07.12.2015 um 15:25 schrieb Levi Morrison: >> So, I wonder if it would not be better to wait until nearer the deadline, >> and see if we need an extension then? > > This is exactly the strategy that at least a few others in this thread > aside from myself are advocating against. Please let's ju

Re: [PHP-DEV] PHP 5.6 life cycle

Am 06.12.2015 um 19:02 schrieb Remi Collet: > so active support until Dec 2016 > and security support until Dec 2017. Dec 2016 / Dec 2017 makes sense to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.6 life cycle

Am 06.12.2015 um 17:57 schrieb Björn Larsson: > Would like to add that given 7.0 major uptake with ISP's coming next > year (at least in my region) it seems prudent to prolong 5.6 lifecycle a > little. I fear that extending support for PHP 5 will slow down adoption of PHP 7. -- PHP Internals -

Re: [PHP-DEV] PHP 5.6 life cycle

Am 06.12.2015 um 15:45 schrieb Sebastian Bergmann: > I hope that we stick to the current plan of ending support for PHP 5 "support" should have been "active support". Sorry for the noise. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, vi

Re: [PHP-DEV] PHP 5.6 life cycle

Am 06.12.2015 um 13:14 schrieb Jan Ehrhardt: > See http://php.net/supported-versions.php > > Will PHP 5.6 go into 'security fixes only' on 28 Aug 2015 with a end of > life on 28 Aug 2016? I hope that we stick to the current plan of ending support for PHP 5 on 28 Aug 2016. If we don't, then plea

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Am 04.12.2015 um 18:53 schrieb Florian Anderiasch: > I hate to say it, but not providing an official Windows build is kind of > sticking the finger to everyone using Windows for PHP (not the language) > development. Sorry, but that does not explain the special treatment of Windows. Red Hat provi

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Am 04.12.2015 um 00:09 schrieb Stanislav Malyshev: > Windows as a platform is different from Linux/Mac in several aspects True. But why does the PHP Project have to provide Windows binaries on php.net? Microsoft should be treated as any other downstream vendor: let them build their binaries on

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Am 03.12.2015 um 16:10 schrieb Julien Pauli: > We, PHP, are not distros maintainers. Well said. But why, then, do we provide Windows binaries? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Am 03.12.2015 um 12:10 schrieb Pierre Joye: > In my world, we build softwares from sources, then we may found > issues. We patch the sources to fix them and make everything work > together smoothly. Are you suggesting that PHP 7.0.0 will be changed, re-tagged, and then released without a new rel

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Am 03.12.2015 um 11:44 schrieb Anatol Belski: > IMHO offering a secure release which also fits with users expectations I would agree if this were about the release itself, PHP's sourcecode. It is not. It is about a binary. But I will shut up now. -- PHP Internals - PHP Runtime Development Mail

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Am 03.12.2015 um 09:26 schrieb Anatol Belski: > No one was talking about a "blocker", everything looks good for today. A > blocker colud be a critical issue, which by chance are often discovered > short before release by the suspects you mentioned. No such issues are known > ATM. The decision to

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Am 02.12.2015 um 09:42 schrieb Anatol Belski: >> Do the Windows builds have to be available immediately when the >> sources of PHP 7.0.0 are released? > Yes. http://git.php.net/?p=php-src.git;a=blob;f=README.RELEASE_PROCESS currently reads "Ensure that Windows builds will work before packagi

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

Am 02.12.2015 um 08:34 schrieb Anatol Belski: > A short note to this is that due to the OpenSSL release on December 3rd that > makes full sense to be included with the Windows builds, the PHP 7.0.0 > announcement will most likely appear later afternoon. Do the Windows builds have to be available

[PHP-DEV] INI_SCANNER_TYPED: New in PHP 5.6 or PHP 7?

According to UPGRADING [1], INI_SCANNER_TYPED was added in PHP 7: "- parse_ini_file(): - parse_ini_string(): . Added scanner mode INI_SCANNER_TYPED to yield typed .ini values." However, the INI_SCANNER_TYPED constant already exists in PHP-5.6 and seems to be actually used.

[PHP-DEV] Re: [PHP-CVS] tag php-src: create tag php-7.0.0RC8

On 11/25/2015 04:10 AM, Anatol Belski wrote: Tag php-7.0.0RC8 in php-src.git was created Tag: 4db85e9fedda7d177737cbfeb1cf3096cb4d3bc4 Tagger: Anatol Belski Wed Nov 25 04:10:51 2015 +0100 Log: Tag for 7.0.0RC8 Why were 569763cb1ac67f56e7743062ca8b3b7c650c1254 and 00865ae2

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