Recently, as part of school course on optimization, I have identified a
potential optimization or feature for PHP. After looking through the
array.c file(located in etc/standard in the PHP source code), I noticed
that both the in_array and array_search are using the linear search C
function
Hi Pierre,
On Mon, Mar 30, 2015 at 11:42 AM, Pierre Joye pierre@gmail.com wrote:
On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye pierre@gmail.com
wrote:
Same effects but totally unrelated topics.
Hi Yasuo
On Mon, Mar 30, 2015 at 1:07 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
int should be fixed also.
http://3v4l.org/95dHM
We have already fix for this: JSON_BIGINT_AS_STRING ( http://3v4l.org/vYXUk
)
So option may be JSON_SCALAR_AS_STRING or
additional JSON_INT_AS_STRING.
I was
Hi internals!
There are a number of open issues with regard to the exception hierarchy
for recently introduced exception, for which I would like to open a new
thread:
* Naming and classiness of BaseException. There's an RFC to change this to
a Throwable interface:
On Mon, Mar 30, 2015 at 9:04 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Mon, Mar 30, 2015 at 11:42 AM, Pierre Joye pierre@gmail.com
wrote:
On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
I have two open PRs like that:
https://github.com/php/php-src/pull/1204
On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner m...@php.net wrote:
On 30/03/15 12:04, Ferenc Kovacs wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to
On Mar 30, 2015 6:15 PM, Michael Wallner m...@php.net wrote:
On 30/03/15 12:04, Ferenc Kovacs wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific
Voting concluded yesterday on the Generator Delegation RFC; the proposal
passed 25-0 for inclusion in PHP7.
https://wiki.php.net/rfc/generator-delegation#vote
Thanks to everyone who read the proposal and contributed either directly or
indirectly.
-Daniel
This RFC has been declined with 21 Yes votes and 26 No votes.
Regards, Niklas
2015-03-29 11:19 GMT+02:00 Pascal Martin, AFUP mail...@pascal-martin.fr:
Le 15/03/2015 20:31, Niklas Keller a écrit :
I just opened the vote for the in operator
Hi,
Discussing this RFC with other people at
All,
One thing that I think we should change is how we refer to the ‘weak’ type
hints. The word ‘weak’ has a negative ring to it, and considering this is
how the language behaves across the board it’s a pretty bad name for this
feature.
Personally I think we should go for ‘dynamic’ when we
We could
also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’,
although I think we can easily do without introducing a new word into the
vocabulary here.
From an user perspective, I'd suggest that lax would potentially carry
more negative connotations than weak. Lax
On Mon, Mar 30, 2015 at 3:10 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner m...@php.net wrote:
On 30/03/15 12:04, Ferenc Kovacs wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments
Hi Zeev,
Le 30 mars 2015 16:17, Zeev Suraski z...@zend.com a écrit :
All,
One thing that I think we should change is how we refer to the ‘weak’ type
hints. The word ‘weak’ has a negative ring to it, and considering this is
how the language behaves across the board it’s a pretty bad name
On 30 March 2015 at 15:16, Zeev Suraski z...@zend.com wrote:
All,
One thing that I think we should change is how we refer to the ‘weak’ type
hints. The word ‘weak’ has a negative ring to it, and considering this is
how the language behaves across the board it’s a pretty bad name for this
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
I was never happy about this particular hack but that said, unless we
*know* it is not used widely (and I suspect it is in Japan etc. where we
don't have a lot of visibility due to language barrier) we can't
Hey,
Imho TypeException may not be best name for
it, as it's also thrown for non-type related error conditions, like
mismatched argument count.
Would SignatureException be a more apt name for these error conditions?
-Tom
--
PHP Internals - PHP Runtime
On 30/03/15 12:04, Ferenc Kovacs wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
I have two open PRs like that:
On Mar 30, 2015 5:29 PM, Nikita Popov nikita@gmail.com wrote:
From this thread, I'd say we have a consensus to deprecate it. From the
Japanese side, both Yasuo and Masaki agree that this should be dropped and
Masaki also linked a bug report where it is stated that the original
author
of
Hi!
One thing that I think we should change is how we refer to the ‘weak’ type
hints. The word ‘weak’ has a negative ring to it, and considering this is
I would really prefer we stop calling it hints. It is misleading as it
is implying this is something which can be easily ignored if wished
Zeev Suraski wrote:
One thing that I think we should change is how we refer to the ‘weak’ type
hints. The word ‘weak’ has a negative ring to it, and considering this is
how the language behaves across the board it’s a pretty bad name for this
feature.
Personally I think we should go for
On 30/03/2015 19:50, Stanislav Malyshev wrote:
Hi!
I tend to agree that it would be easier for all parties if we stop
adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer working
on a project, and you
Am 30.03.2015 um 12:58 schrieb Thomas Punt:
Hey,
Imho TypeException may not be best name for
it, as it's also thrown for non-type related error conditions, like
mismatched argument count.
Would SignatureException be a more apt name for these error conditions?
We already have an
Hi!
I tend to agree that it would be easier for all parties if we stop
adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer working
on a project, and you noticed there's some small functionality missing
that
Hi!
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
Adding an option I think it's ok provided it's not controversial and not
an attempt to create entirely
Hi!
even agreeing upon something like adding features in a micro version
needs a format RFC and a 2/3 vote would allow us to have a conservative
default while we could still make exceptions with a clear process to follow.
I'm still not sure which problem we're trying to solve. Can someone
Zeev Suraski wrote:
One thing that I think we should change is how we refer to the ‘weak’ type
hints. The word ‘weak’ has a negative ring to it, and considering this is
how the language behaves across the board it’s a pretty bad name for this
feature.
Borrowing from C#, I would suggest the
Stanislav Malyshev wrote:
I can certainly see value in a special case for including things in both
5.6 and 7.x, both before and after 7.0 is released, but the the case for
backporting anything other than a genuine bug fix to 5.5.x right now
seems fairly weak, as will the case for backporting
Hi!
If an organisation has standardised on an old version of PHP, there's a
By old you're meaning current stable, I presume.
fair chance that the builds they are using are not from php.net, but
from their OS distribution. As has been mentioned here before, these
There are no builds on
On Mon, Mar 30, 2015 at 10:52 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
Adding an option I
-Ursprüngliche Nachricht-
Von: Lazare Inepologlou [mailto:linep...@gmail.com]
Gesendet: Dienstag, 31. März 2015 00:01
An: Christoph Becker
Cc: Zeev Suraski; PHP internals
Betreff: Re: [PHP-DEV] Re: Naming of 'weak' type hints
Zeev Suraski wrote:
One thing that I think we
On Mon, Mar 30, 2015 at 8:50 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
I tend to agree that it would be easier for all parties if we stop
adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer
Hi!
Have you considered developers targeting shared hosting? Working on an
improvement they have to wait for five years to use it is most certainly
annoying. However, introducing this feature in a revision might not
really help them at all.
Not immediately, but shared hoster much faster
Hi Dan,
The updated patch is at https://github.com/php/php-src/pull/1205
The main difference is in ext/intl.
If you don't see any problems I can commit it.
I didn't think about the classes you missed.
Thanks. Dmitry.
On Fri, Mar 27, 2015 at 7:32 PM, Dan Ackroyd dan...@basereality.com wrote:
On Mon, Mar 30, 2015 at 4:04 AM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
I have two open PRs like that:
35 matches
Mail list logo
