On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski z...@zend.com 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 done. Valid reasons can be performance penalties of
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 a
On 13 October 2014 08:06:16 GMT+01:00, Lester Caine les...@lsces.co.uk 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
On Mon, Oct 13, 2014 at 8:51 AM, Pierre Joye pierre@gmail.com wrote:
On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski z...@zend.com 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
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
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
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
On Oct 13, 2014 7:10 PM, Jan Ehrhardt php...@ehrhardt.nl 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
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?
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
Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
On Oct 13, 2014 7:10 PM, Jan Ehrhardt php...@ehrhardt.nl 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
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, anatol@belski.net wrote:
Hi Dmitry,
thanks for taking a look,
On Mon, October 13, 2014 13:38, Dmitry Stogov wrote:
Hi
On Oct 13, 2014 8:08 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Pierre Joye in php.internals (Mon, 13 Oct 2014 14:21:24 +0200):
On Oct 13, 2014 7:10 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
In the ext/mysql case this will be a bit uncomfortable. If you compile
PHP --with-mysql=mysqlnd
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
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
On 13 Oct 2014, at 13:55, Miloslav Hůla miloslav.h...@gmail.com 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.
On 13 October 2014 16:12, Andrea Faulds a...@ajf.me 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
On 13 Oct 2014, at 15:14, Marco Pivetta ocram...@gmail.com wrote:
On 13 October 2014 16:12, Andrea Faulds a...@ajf.me 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
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, however it isn't
On Mon, Oct 13, 2014 at 4:21 PM, Andrea Faulds a...@ajf.me wrote:
On 13 Oct 2014, at 15:14, Marco Pivetta ocram...@gmail.com wrote:
On 13 October 2014 16:12, Andrea Faulds a...@ajf.me wrote:
2. Shouldn’t it return fully-qualified class names beginning with a
backslash?
When in string
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
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
On Mon, Oct 13, 2014 at 2:45 AM, Marco Pivetta ocram...@gmail.com wrote:
On 12 October 2014 00:47, Andrea Faulds a...@ajf.me wrote:
On 11 Oct 2014, at 23:42, Rowan Collins rowan.coll...@gmail.com wrote:
func_get_args() and func_num_args(), OTOH, existed solely to support
variadics, and
to contribute to the PHP source regularly.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 13.10.2014 02:45, Marco Pivetta wrote:
On 12 October 2014 00:47, Andrea Faulds a...@ajf.me wrote:
On 11 Oct 2014, at 23:42, Rowan Collins rowan.coll...@gmail.com wrote:
func_get_args() and func_num_args(), OTOH, existed solely to support
variadics, and anything taking advantage of them
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
On 13 October 2014 20:20, Marc Bennewitz php@mabe.berlin 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
On 13 October 2014 20:47, Stas Malyshev smalys...@sugarcrm.com 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
On 13.10.2014 20:48, Marco Pivetta wrote:
On 13 October 2014 20:20, Marc Bennewitz php@mabe.berlin
mailto:php@mabe.berlin 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]:
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 is not
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 should have a
On 13 October 2014 21:18, Marc Bennewitz php@mabe.berlin wrote:
On 13.10.2014 20:48, Marco Pivetta wrote:
On 13 October 2014 20:20, Marc Bennewitz php@mabe.berlin wrote:
On 13.10.2014 02:45, Marco Pivetta wrote:
Your implementation of userland_call_user_func doesn't have the same
On 13 October 2014 21:37, Stas Malyshev smalys...@sugarcrm.com 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
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 gradually
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
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
On 13.10.2014 22:26, Marco Pivetta wrote:
On 13 October 2014 21:18, Marc Bennewitz php@mabe.berlin
mailto:php@mabe.berlin wrote:
On 13.10.2014 20:48, Marco Pivetta wrote:
On 13 October 2014 20:20, Marc Bennewitz php@mabe.berlin
mailto:php@mabe.berlin wrote:
On
... 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
38 matches
Mail list logo
