Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

Hi, > ... like the hidden array element: http://3v4l.org/6uFqf > ... like the hidden object property: http://3v4l.org/RPJXH Don't know if it's related or not, but sure feels like a bug i posted a while ago: https://bugs.php.net/bug.php?id=67640 thanks! Robin -- PHP Internals - PHP Runtime Dev

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

Hi! I would say we should choose according to the following criteria: 1. Is anybody likely to use it, and if so, will dropping it impede adoption significantly? 2. Would using it get you into some trouble you can't see easily? 3. How easy it's to detect that something is broken due to BC change?

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

Hi! >> We have chosen to deprecate features, including ext/mysql. If we now >> decide not to remove some of them for 7, we may just remove the >> deprecation flag as we are going to support them for the next decade >> as well, whether we like it or not. I don't see how this follows. We may keep t

[PHP-DEV] Possibilities to fix some really poor behaviors in PHP7

... like the hidden array element: http://3v4l.org/6uFqf ... like the hidden object property: http://3v4l.org/RPJXH Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13.10.2014 22:26, Marco Pivetta wrote: > On 13 October 2014 21:18, Marc Bennewitz > wrote: > > > On 13.10.2014 20:48, Marco Pivetta wrote: >> On 13 October 2014 20:20, Marc Bennewitz > > wrote: >> >> >> On 13.10.2014 02:45, Ma

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13/10/2014 21:34, Marco Pivetta wrote: The problem always existed, and it's that it is very hard to escape from an API that is dictated by the language itself. Getting gradually rid of those APIs and making them swappable pieces simply increases the degree of freedom that we get in our applica

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13/10/2014 01:45, Marco Pivetta wrote: In general, I've always been against any non-language feature that isn't implemented with the language itself, but it's my point of view: as a simple rule of thumb (my rule, many would just say I'm crazy), if it can be implemented in PHP, then don't ad

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

Hi! > The problem always existed, and it's that it is very hard to escape from > an API that is dictated by the language itself. It is not a problem, at least not a define problem - what is "escape from an API"? Why you would want to escape from the language you're writing in? > Getting graduall

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13 October 2014 21:37, Stas Malyshev wrote: > Hi! > > > My point is that providing them as "userland implementation" even inside > > core would be more interesting than having something magic going on > > under the hood. > > It certainly may be "interesting", and nobody prevents you from writi

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13 October 2014 21:18, Marc Bennewitz wrote: > > On 13.10.2014 20:48, Marco Pivetta wrote: > > On 13 October 2014 20:20, Marc Bennewitz wrote: > >> >> On 13.10.2014 02:45, Marco Pivetta wrote: >> >> Your implementation of "userland_call_user_func" doesn't have the same >> visibility as "call

Re: [PHP-DEV] PHP 7 and json

Hi, We have 2 alternative extensions > > - - jsonc the older one, probably not perfect, but used in a lot of > downstream distributions > > - - jsond the recent one > > > I think it is time to switch ext/json to another implementation and so > make PHP really "free" again. > I think that we shoul

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

Hi! > My point is that providing them as "userland implementation" even inside > core would be more interesting than having something magic going on > under the hood. It certainly may be "interesting", and nobody prevents you from writing a blog or implementing a library doing this. However, it i

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13.10.2014 20:48, Marco Pivetta wrote: > On 13 October 2014 20:20, Marc Bennewitz > wrote: > > > On 13.10.2014 02:45, Marco Pivetta wrote: > > Your implementation of "userland_call_user_func" doesn't have the same > visibility as "call_user_func[_array]": >

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13 October 2014 20:47, Stas Malyshev wrote: > Yes, we can rewrite these functions in userland. So we can may others. > The long standing tradition of PHP in this area is to go the extra mile > for the user and actually provide helpful functions My point is that providing them as "userland im

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13 October 2014 20:20, Marc Bennewitz wrote: > > On 13.10.2014 02:45, Marco Pivetta wrote: > > Your implementation of "userland_call_user_func" doesn't have the same > visibility as "call_user_func[_array]": > http://3v4l.org/lNgub Interesting: this seems to show that it's even more magic th

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

Hi! > While rambling with some code today, I realized that `call_user_func` > behaves strangely, appearing and disappearing from stack traces depending > on versions of PHP. If there's a problem with these functions, some bug in backtrace reporting, they of course need to be fixed. However I see

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On 13.10.2014 02:45, Marco Pivetta wrote: > On 12 October 2014 00:47, Andrea Faulds wrote: > >> On 11 Oct 2014, at 23:42, Rowan Collins wrote: >> >>> func_get_args() and func_num_args(), OTOH, existed solely to support >> variadics, and anything taking advantage of them being functions rather >>

[PHP-DEV] VCS Account Request: covibe

to contribute to the PHP source regularly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

On Mon, Oct 13, 2014 at 2:45 AM, Marco Pivetta wrote: > On 12 October 2014 00:47, Andrea Faulds wrote: > >> >> On 11 Oct 2014, at 23:42, Rowan Collins wrote: >> >> > func_get_args() and func_num_args(), OTOH, existed solely to support >> variadics, and anything taking advantage of them being fun

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

Dne 13.10.2014 16:12, Andrea Faulds napsal(a): 1. I think you should also support function aliases here. Constants too would be good, but I’m not sure if they’re actually implemented as aliases (they might just be copies). The function and constant aliasing is a quite new PHP feature. I don't

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

Dne 13.10.2014 16:09, Dan Ackroyd napsal(a): Wouldn't this RFC be almost instantly deprecated if the Return Type Declarations RFC ( https://wiki.php.net/rfc/returntypehinting ) is accepted? The Return Type Declarations RFC solves problem partially. Aliases expanding is needed for many other an

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

On Mon, Oct 13, 2014 at 4:21 PM, Andrea Faulds wrote: > > On 13 Oct 2014, at 15:14, Marco Pivetta wrote: > > > On 13 October 2014 16:12, Andrea Faulds wrote: > > 2. Shouldn’t it return fully-qualified class names beginning with a > backslash? > > > > When in string context, we are typically alw

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

On Mon, Oct 13, 2014 at 3:46 PM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > Hello! > > > I've written an RFC which proposes to expose a namespace aliases/imports > for > > user-land code. > > > > https://wiki.php.net/rfc/aliases_by_reflection > > I think that this idea is good, howev

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

On 13 Oct 2014, at 15:14, Marco Pivetta wrote: > On 13 October 2014 16:12, Andrea Faulds wrote: > 2. Shouldn’t it return fully-qualified class names beginning with a backslash? > > When in string context, we are typically always talking about FQCNs, so the > leading backslash is not needed an

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

On 13 October 2014 16:12, Andrea Faulds wrote: > 2. Shouldn’t it return fully-qualified class names beginning with a > backslash? > When in string context, we are typically always talking about FQCNs, so the leading backslash is not needed and should be omitted. Marco Pivetta http://twitter.co

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

On 13 Oct 2014, at 13:55, Miloslav Hůla wrote: > I've written an RFC which proposes to expose a namespace aliases/imports for > user-land code. > > https://wiki.php.net/rfc/aliases_by_reflection Looks good, but: 1. I think you should also support function aliases here. Constants too would b

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

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

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

Hello! > I've written an RFC which proposes to expose a namespace aliases/imports for > user-land code. > > https://wiki.php.net/rfc/aliases_by_reflection I think that this idea is good, however it isn't correct to keep aliases per each class, because they are applied per scope. TokenReflection l

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

On Oct 13, 2014 8:08 PM, "Jan Ehrhardt" wrote: > > Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200): > >On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" wrote: > >> > >> In the ext/mysql case this will be a bit uncomfortable. If you compile > >> PHP --with-mysql=mysqlnd the mysqlnd-part is i

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c

bench.php should be faster as well. It must be slower because of not lucky code locality or something like that. Thanks. Dmitry. On Mon, Oct 13, 2014 at 4:40 PM, wrote: > Hi Dmitry, > > thanks for taking a look, > > On Mon, October 13, 2014 13:38, Dmitry Stogov wrote: > > Hi Anatol, > > > > > >

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

Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200): >On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" wrote: >> >> In the ext/mysql case this will be a bit uncomfortable. If you compile >> PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of >> the functionality of ext/mysql is

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

Good afternoon, I've written an RFC which proposes to expose a namespace aliases/imports for user-land code. https://wiki.php.net/rfc/aliases_by_reflection I would like to ask you to open a discussion. Kind regards, Milo -- Miloslav Hůla -- PHP Internals - PHP Runtime Development Mailing L

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

On Mon, 2014-10-13 at 14:10 +0200, Jan Ehrhardt wrote: > In the ext/mysql case this will be a bit uncomfortable. If you compile > PHP --with-mysql=mysqlnd the mysqlnd-part is in core, while a part of > the functionality of ext/mysql is used. What if mysqlnd drifts away from > supporting ext/mysql?

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

On Oct 13, 2014 7:10 PM, "Jan Ehrhardt" wrote: > > Dmitry Stogov in php.internals (Mon, 13 Oct 2014 14:29:06 +0400): > >Note, that once we move extension outside of main source tree, only > >extension maintainers (if any) will support them. > > In the ext/mysql case this will be a bit uncomfortabl

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

Dmitry Stogov in php.internals (Mon, 13 Oct 2014 14:29:06 +0400): >Note, that once we move extension outside of main source tree, only >extension maintainers (if any) will support them. In the ext/mysql case this will be a bit uncomfortable. If you compile PHP --with-mysql=mysqlnd the mysqlnd-part

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c

Hi Anatol, At first, I still saw the same big difference on Linux. bench.php ZTS - 1.340 sec, native TLS - 1.785 sec. As I understood, it must be related to incomplete changes in build scripts, related to ZEND_ENABLE_STATIC_TSRMLS_CACHE. Right? If I get it properly, main PHP binary should be comp

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

Note, that once we move extension outside of main source tree, only extension maintainers (if any) will support them. According to the voting process, I think it makes sense to vote for each feature separately. Thanks. Dmitry. On Sun, Oct 12, 2014 at 4:13 AM, Rasmus Lerdorf wrote: > > On Oc

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

On Mon, Oct 13, 2014 at 8:51 AM, Pierre Joye wrote: > On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski wrote: > >> >> For the record, I don't feel strongly about # comments, but I do think that >> we should have good reasons to actually *remove* features that are better >> than "this is how it's do

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

On 13 October 2014 08:06:16 GMT+01:00, Lester Caine wrote: >On 13/10/14 01:35, Rowan Collins wrote: >>> Because ini files use ; for comments and not #. >> >> - The behaviour of # as comments in earlier versions seems to have >been >> a side-effect of something else, rather than a deliberate featu

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

On 13/10/14 01:35, Rowan Collins wrote: >> Because ini files use ; for comments and not #. > > - The behaviour of # as comments in earlier versions seems to have been > a side-effect of something else, rather than a deliberate feature. In > fact, it was possible to have a key starting with #, but