On 30/03/15 15:16, Zeev Suraski wrote:
Personally I think we should go for ‘dynamic’ when we document it, as this
is the common way to refer to this behavior (dynamic languages). We could
also consider going for ‘lax’ or ‘lenient’ as the opposite of ‘strict’,
although I think we can easily do
On Tue, Mar 31, 2015 at 3:02 PM, Tony Marston tonymars...@hotmail.com wrote:
Nikita Popov wrote in message
news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4asxhu4n_jia+40oy_gum...@mail.gmail.com...
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
I was never happy
On Mon, Mar 30, 2015 at 4:16 PM, 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
Hi Dan,
any update? should I commit it?
or do you see any problems?
Thanks. Dmitry.
On Mon, Mar 30, 2015 at 7:06 PM, Dmitry Stogov dmi...@zend.com wrote:
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
Nikita Popov wrote in message
news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4asxhu4n_jia+40oy_gum...@mail.gmail.com...
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
Stanislav Malyshev wrote on 30/03/2015 23:10:
Hi!
If an organisation has standardised on an old version of PHP, there's a
By old you're meaning current stable, I presume.
No, current stable is 5.6.x; people have been talking about backporting
to 5.5.x (which has 2 months of active support
Hi Jakub,
On Mon, Mar 30, 2015 at 5:45 PM, Jakub Zelenka bu...@php.net wrote:
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 )
Excellent.
That is a stellar response Dan, Thanks for being so clear. I had a feeling
that this might be the case so we'll have to work around it.
Just for clarity and posterity I provided the simplest test case in the
original email not the actual problem. In Drupal this isn't just one place
though becase,
Am 31.03.2015 22:45 schrieb Rowan Collins rowan.coll...@gmail.com:
- Up until the first release candidate of x.y.0, small features can be
added to both the most recent live branch and the new branch being prepared
for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and
7.1-pre).
-
Hi Dmitry,
Your approach is definitely a better one, and I have no objection to
it whatsoever.
Sorry, I was too busy to look deeply at each class but I can't see any problems.
Nikita Popov wrote:
does that mean that the same code using strict_types=1 mode will start
throwing TypeException
Hi James,
On 31 March 2015 at 21:51, James Gilliland neclim...@gmail.com wrote:
By design, \EngineException does not extend \Exception so code doesn't
accidentally catch this special type of exception. ...
I don't know if this is all acceptable and/or by design but it is awkward
so I wanted
Andrey Hristov wrote on 31/03/2015 16:02:
Currently in MT environment the task of data separation is pushed to
the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that
the data is not stored by using TLS but other mechanism and
cooperative multitasking is not something that can't
Le 31/03/2015 15:56, Daniel Lowrey a écrit :
HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
exists. The protocol impacts the actual HTTP server and has nothing to do
with the SAPI runtime which is simply handed information about the HTTP
request once the server parses
HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
exists. The protocol impacts the actual HTTP server and has nothing to do
with the SAPI runtime which is simply handed information about the HTTP
request once the server parses it. The protocol used to communicate those
On Monday, March 30, 2015, Christoph Becker cmbecke...@gmx.de
javascript:_e(%7B%7D,'cvml','cmbecke...@gmx.de'); wrote:
It appears to me that all of these suggestions may hide the fact that
the arguments are converted to the hinted types. So perhaps converting
type hints might be a good name.
On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat greg...@luni.fr wrote:
Le 31/03/2015 15:56, Daniel Lowrey a écrit :
HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
exists. The protocol impacts the actual HTTP server and has nothing to do
with the SAPI runtime
this ain't exactly true. Currently in MT environment the task of data
separation is pushed to the TSRM by using TLS. Now, if TSRM is
reimplemented in a fashion that the data is not stored by using TLS but
other mechanism and cooperative multitasking is not something that
can't be done.
The
Pavel,
Hello,
I would definitely stick with weak; it is common naming used across
many languages and textbooks.
Also, why is the strongly typed mode named strict anyways? If
anything should change, it should be strict to strong, so PHP doesn't
look like a special snowflake.
Strong has a
Hi!
- Up until the first release candidate of x.y.0, small features can be
added to both the most recent live branch and the new branch being
prepared for release (so, right now, 5.6.x and 7.0-pre; next summer,
7.0.x and 7.1-pre).
- Once a new x.y.0 release is ready, x.y-1.z releases should
Le 31/03/2015 16:40, Daniel Lowrey a écrit :
The issue here is this: the web SAPI is historically the most stable thing
about PHP. Supporting things like message push and multiplexing would
require a fundamental change in what the web SAPI is. You would have to
junk the entire model and create
On Tuesday, 31 March 2015, 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
Hi,
On 31.03.2015 17:40, Daniel Lowrey wrote:
On Tue, Mar 31, 2015 at 10:11 AM Grégory Planchat greg...@luni.fr wrote:
Le 31/03/2015 15:56, Daniel Lowrey a écrit :
HTTP/2 is entirely outside the scope of the PHP web SAPI as it currently
exists. The protocol impacts the actual HTTP server and
All,
Ever since we introduced password_hash() in 5.5, I've been watching
its usage as much as possible. I've setup google alerts and such, as
well as auditing implementations I've found on github to try to
understand how it's used.
One thing has become abundantly clear to me: the salt option is
I'd vote yes on this one, if it were an RFC. Please expedite this
deprecation for 7.0.
Can we also deprecate MCRYPT_RAND? I opened an RFC for that a long time ago
and just remembered it.
Hi!
The problem is always a definition question, a very subjective question.
Fortunately, we can discuss it, we're not limited to blindly following
predefined set of rules.
I do not really buy the I am stuck with x.y as one has the same
problem already. And he has barely a 2 years window to
On Tue, Mar 31, 2015 at 8:49 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Ever since we introduced password_hash() in 5.5, I've been watching
its usage as much as possible. I've setup google alerts and such, as
well as auditing implementations I've found on github to try to
I think deprecating it is a good idea, and looking at the documentation it
does mention that not providing it is the intended option; so it isn't a
complete surprise for it to become deprecated.
On 31 March 2015 at 19:49, Anthony Ferrara ircmax...@gmail.com wrote:
All,
Ever since we
Nicolas Oelgart wrote:
On 31 Mar 2015, at 20:49, Anthony Ferrara ircmax...@gmail.com wrote:
So I'd like to hear your thoughts about raising E_DEPRECATED when the
salt option is specified in 7.0, with ultimately removing the option
in a later version.
+1
I'd even go as far as adding a
Am 31.03.2015 um 19:09 schrieb Grégory Planchat:
Possible solutions would be :
1. About multiplexing :
1.a. integrate php-uv in the core in its current form and let
developers implement their own protocol layer
1.b. transform some project like ReactPHP into an extension (using
Zephir
On 31 Mar 2015, at 21:32, Christoph Becker cmbecke...@gmx.de wrote:
Nicolas Oelgart wrote:
On 31 Mar 2015, at 20:49, Anthony Ferrara ircmax...@gmail.com wrote:
So I'd like to hear your thoughts about raising E_DEPRECATED when the
salt option is specified in 7.0, with ultimately
On 31.03.2015 18:26, Rowan Collins wrote:
Andrey Hristov wrote on 31/03/2015 16:02:
Currently in MT environment the task of data separation is pushed to
the TSRM by using TLS. Now, if TSRM is reimplemented in a fashion that
the data is not stored by using TLS but other mechanism and
cooperative
On Tue, Mar 31, 2015 at 7:49 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Ever since we introduced password_hash() in 5.5, I've been watching
its usage as much as possible. I've setup google alerts and such, as
well as auditing implementations I've found on github to try to
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev smalys...@gmail.com
wrote:
This is a straw man as far as the points I made are concerned. I'm
talking about the risk of switching from 5.5 to 5.6, which is pretty
low.
Switching to 5.6 would be useless since what is being propose it to
Sorry for the double reply, but I wanted to pick up on one particular point.
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
That's not quite how it works; the distro package maintainers
maintain a
sort of forked version of upstream code, combining a
hi Nikita,
I don't care about this a lot. I reworked this patch just because it missed
few details, and then found and fixed mistake in ext/intl.
If you think TypeException is better (I think this makes sense), please
implement it on top and commit.
Thanks. Dmitry.
On Tue, Mar 31, 2015 at 11:07
Hi,
I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
support in any threads on internals nor the wiki. I'm aware that HTTP is
the responsibility of the underlying web server, but there are new
*important* features to consider.
I know the feature list for PHP7 is now
De : Zeev Suraski [mailto:z...@zend.com]
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.
What about
hi,
ps: please keep the xyz wrote, makes harder to read your replies without it
On Wed, Apr 1, 2015 at 2:57 AM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
The problem is always a definition question, a very subjective question.
Fortunately, we can discuss it, we're not limited to
On 31 March 2015 21:23:56 GMT+01:00, Andrey Hristov p...@hristov.com wrote:
So, if Zend can be optimized to quickly clean the execution
environment,
and easily switch between them, we can have a giant leap towards
concurrent non-blockable PHP. The idea is simple - the Zend environment
should be
On 1.04.2015 00:31, Rowan Collins wrote:
On 31 March 2015 21:23:56 GMT+01:00, Andrey Hristov p...@hristov.com wrote:
So, if Zend can be optimized to quickly clean the execution
environment,
and easily switch between them, we can have a giant leap towards
concurrent non-blockable PHP. The idea
No objections here either.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
So testing out PHP 7 I triggered an \EngineException() in Drupal 8. For
various reasons that don't really matter here Drupal uses
set_exception_handler() to provide its own exception handler. What is
important is that the methods used by that handler type hint \Exception for
their arguments. The
On 3/31/15 8:31 AM, Grégory Planchat wrote:
Hi,
I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
support in any threads on internals nor the wiki. I'm aware that HTTP is
the responsibility of the underlying web server, but there are new
*important* features to consider.
On Mon, Mar 30, 2015 at 6:06 PM, Dmitry Stogov dmi...@zend.com wrote:
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.
Hi!
That's not quite how it works; the distro package maintainers maintain a
sort of forked version of upstream code, combining a well-tested
upstream release with a set of patches, many of which will be backported
fixes from newer releases. So the current package in Ubuntu 14.04 LTS
[see
Le 31/03/2015 23:45, Larry Garfield a écrit :
On 3/31/15 8:31 AM, Grégory Planchat wrote:
Hi,
I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
support in any threads on internals nor the wiki. I'm aware that HTTP is
the responsibility of the underlying web server, but
hi,
On Tue, Mar 31, 2015 at 8:31 PM, Grégory Planchat greg...@luni.fr wrote:
Hi,
I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
support in any threads on internals nor the wiki. I'm aware that HTTP is the
responsibility of the underlying web server, but there are
47 matches
Mail list logo
