On 14/01/2015 00:16, Andrea Faulds wrote:
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision to the RFC, so
it’d be sensible to separate discussion of the updated RFC from the v0.1 RFC.
Reading the thread at this point shows so much
On Tue, Jan 13, 2015 at 6:16 PM, Andrea Faulds a...@ajf.me wrote:
I’ve made some quite significant changes to my Scalar Type Hints RFC, and
bumped its version to 0.2.
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision to the RFC,
On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@ajf.me wrote:
Hey Levi,
Upon further thought, I’m not super-enthusiastic about this. As has been
pointed out, it’s a pretty serious BC break, whether code can be
automatically updated or not. PHP 4 constructors may be obsolete, but an
Hi Matthew,
On 15 Jan 2015, at 16:59, Matthew Leverton lever...@gmail.com wrote:
I don't like this at all. I'd prefer raising a new warning type (e.g.,
E_AUTOCAST) over this.
That error type would cause absolute chaos, unless people decided not to make
use of it. Custom error handlers are
Hey Levi,
Upon further thought, I’m not super-enthusiastic about this. As has been
pointed out, it’s a pretty serious BC break, whether code can be automatically
updated or not. PHP 4 constructors may be obsolete, but an awful lot of code
uses them.
A better solution, IMO, might be simply to
Hello Mike,
On 15 Jan 2015, at 16:55, Mike Willbanks pen...@gmail.com wrote:
I actually quite disagree with that statement.
I don’t understand. I said either approach to scalar hints will upset a large
portion of the community”. Are you not demonstrating that point, in that you
don’t like
Hello Andrea,
On Thu, Jan 15, 2015 at 8:09 AM, Andrea Faulds a...@ajf.me wrote:
Hi Zeev,
On 15 Jan 2015, at 11:56, Zeev Suraski z...@zend.com wrote:
Andrea,
I'm not sure what you're basing that assumption on. The incidental
interactions you (or anybody) may have with 'the
Hi,
On 16/01/15 03:41, Michael Wallner wrote:
Looks good.
There's another one(2) in /ext/phar/util.c:
--snip--
911if (error) {
912*error = NULL;
913}
914/* seek to start of internal file and read it */
915if (FAILURE ==
Hi Mike,
On 15 Jan 2015, at 17:07, Mike Willbanks pen...@gmail.com wrote:
I may not have described this clearly. If I make a library with a method
that states an int, the declarative syntax now makes me have to take both due
to your earlier comment on that userland would define the
On Jan 15, 2015, at 6:51 AM, Andrea Faulds a...@ajf.me wrote:
I’m not really sure this is true. I agree that strict types aren’t entirely
in keeping with the “PHP way”. However, there are plenty of people who are
against them not for that reason, but simply because they don’t work well
Hi Andrea,
On 15 Jan 2015, at 16:55, Mike Willbanks pen...@gmail.com wrote:
I actually quite disagree with that statement.
I don’t understand. I said either approach to scalar hints will upset a
large portion of the community”. Are you not demonstrating that point, in
that you don’t
Hey Levi,
On 15 Jan 2015, at 17:16, Levi Morrison le...@php.net wrote:
On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds a...@ajf.me wrote:
A better solution, IMO, might be simply to add a deprecation notice. This
would make it obvious during development if you’ve accidentally defined a
Hi Pavel,
On 15 Jan 2015, at 15:25, Pavel Kouřil pajou...@gmail.com wrote:
On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Reading the thread at this point shows so much confusion, it seems half the
people reading the spec misunderstood that the declare() line
On 15/01/2015 15:25, Pavel Kouřil wrote:
The potential issues with this are pretty real, to be honest. Simple
things like moving a method from one class to another (let's say to
parent or descendant) and getting to another typing context may cause
unpredictable behavior if the user forgets to
On 15/01/2015 16:01, Pavel Kouřil wrote:
On Thu, Jan 15, 2015 at 4:35 PM, Jordi Boggiano j.boggi...@seld.be wrote:
I mean that if someone wants strict typing they won't want to use weak hints
because that would coerce the data before they can verify it and ensure
their code is strictly typed.
On 15/01/15 17:31, Joshua Rogers wrote:
---
ext/phar/zip.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/ext/phar/zip.c b/ext/phar/zip.c
index 2a95580..2117b0e 100644
--- a/ext/phar/zip.c
+++ b/ext/phar/zip.c
@@ -1217,7 +1217,9 @@ int
On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Reading the thread at this point shows so much confusion, it seems half the
people reading the spec misunderstood that the declare() line affects
function calls only and not the API/implementation level.
As much I
Hi All,
I've been trying to compile the new patch for bug 68618
(http://git.php.net/?p=php-src.git;a=commit;h=f9ad3086693fce680fbe246e4a45aa92edd2ac35
) into php 5.6.4 . However, I'm getting this error when I try to compile it..
Do you know if there is any dependency I should take care of ?
On Thu, Jan 15, 2015 at 4:35 PM, Jordi Boggiano j.boggi...@seld.be wrote:
I mean that if someone wants strict typing they won't want to use weak hints
because that would coerce the data before they can verify it and ensure
their code is strictly typed.
Therefore the best course of action is
---
ext/phar/zip.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/ext/phar/zip.c b/ext/phar/zip.c
index 2a95580..2117b0e 100644
--- a/ext/phar/zip.c
+++ b/ext/phar/zip.c
@@ -1217,7 +1217,9 @@ int phar_zip_flush(phar_archive_data *phar, char
*user_stub, zend_long
Hi everyone,
I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If
accepted, methods with the same name as their defining class will no
longer be recognized as constructors. As noted in the RFC, there are
already many situations where we do not recognize these methods as
Not sure how that helps, since you would tag versions anyways using semver,
so if there is a master vs next/phpng branch, then they might still result
in two tags v1.0 and v2.0 and there is no way to automatically resolve this.
On Thu, Jan 15, 2015 at 3:48 PM, Jan Ehrhardt php...@ehrhardt.nl
On Thu, 15 Jan 2015 14:30:48 +0300, Arvids Godjuks
arvids.godj...@gmail.com wrote:
Hello Andrea!
Consider what a mess was register_globals and problems it had, but at
least
it was a global setting. Declare will work on per file basis, and it will
end up even more of a mess.
I think PHP
On 15/01/2015 15:31, Pavel Kouřil wrote:
On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Right now, or with only weak hints, if a library decides to implement strict
typing, they'll skip the scalar hints and check types with something like
the assert lib [1]. A user
On 15/01/2015 15:30, Benjamin Eberlei wrote:
The potential issues with this are pretty real, to be honest. Simple
things like moving a method from one class to another (let's say to
parent or descendant) and getting to another typing context may cause
unpredictable behavior if
Hi Zeev,
On 15 Jan 2015, at 14:32, Zeev Suraski z...@zend.com wrote:
Whether or not they are in the majority, a very large portion of PHP
developers would prefer strict typing. In particular, the most vocal ones
would seem to. There are also a lot of PHP developers who would prefer
weak
Hi Zeev,
On 15 Jan 2015, at 15:10, Zeev Suraski z...@zend.com wrote:
Let’s have a look. From a quick skim over the thread for v0.1:
* In favour of weak types (or the RFC anyway): Adam, Stas, yourself,
Jordi,
Pierre,
You're definitely missing Dmitry (which helped with the RFC) as well
On 15/01/15 15:51, Andrea Faulds wrote:
Let’s have a look. From a quick skim over the thread for v0.1:
* In favour of weak types (or the RFC anyway): Adam, Stas, yourself, Jordi,
Pierre,
Count me in for v0.1.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To
By the way, is there already a package that covers this bug ? (Bug 68618)
And I just found out how to recompile with the git version:
http://www.phpinternalsbook.com/build_system/building_php.html
However, we do need to apply the patch in a number and recompiling php in all
of our systems would
Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not sure how that helps, since you would tag versions anyways using semver,
so if there is a master vs next/phpng branch, then they might still result
in two tags v1.0 and v2.0 and there is no way to automatically resolve this.
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Thursday, January 15, 2015 4:51 PM
To: Zeev Suraski
Cc: rquadl...@gmail.com; Leigh; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Zeev,
On 15 Jan 2015, at 14:32, Zeev Suraski
On Thu, Jan 15, 2015 at 4:25 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Thu, Jan 15, 2015 at 4:11 PM, Jordi Boggiano j.boggi...@seld.be
wrote:
Reading the thread at this point shows so much confusion, it seems half
the
people reading the spec misunderstood that the declare() line
Hello together,
I have followed the discussion from the outside (as I am not to vote
here) but I am a (not representative) PHP developer.
I think the main problem here is that you mix two things up:
1. Scalar type hints for functions
2. Conversion rules
From what I have read, most of you agree
Julien Pauli in php.internals (Wed, 14 Jan 2015 18:53:10 +0100):
This will allow more people to help testing both PHP7 (some people may need
some of the top-10 pecl ext to run their apps) and those extensions.
Some time ago I had a discussion with Mike Wallner and others about a
naming convention
On 15/01/2015 15:10, Zeev Suraski wrote:
Except that is not the case for this proposal, which explicitly and
deliberately
prevents the directive affecting inclusion. The behaviour is impossible to
toggle at runtime, unless you’re using some weird extension which lets you
edit the flag on the
Hi Jordi,
On 15 Jan 2015, at 15:11, Jordi Boggiano j.boggi...@seld.be wrote:
On 14/01/2015 00:16, Andrea Faulds wrote:
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision to the RFC, so
it’d be sensible to separate discussion of
Hi,
On Thu, Jan 15, 2015 at 5:31 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Right now, or with only weak hints, if a library decides to implement strict
typing, they'll skip the scalar hints and check types with
On Thu, Jan 15, 2015 at 4:11 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not sure how that helps, since you would tag versions anyways using
semver,
so if there is a master vs next/phpng branch, then they might still result
On Thu, Jan 15, 2015 at 4:19 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Right now, or with only weak hints, if a library decides to implement strict
typing, they'll skip the scalar hints and check types with something like
the assert lib [1]. A user calling it with random data would *always*
For me personally, I would use strict hints for private/protected methods and
weak hints for public methods.
Regards
Thomas
Thomas Bley wrote on 15.01.2015 21:16:
What about doing both weak and strict with two different syntaxes?
public function __construct(string $name, $age as int,
On 15 January 2015 19:20:27 GMT, Andrey Andreev n...@devilix.net wrote:
Hi,
On Thu, Jan 15, 2015 at 7:13 PM, Andrea Faulds a...@ajf.me wrote:
Now from that perspective I cannot rely that I am in strict and
would have to handle the default weak even although I declared in my
class that i wanted
Many developers PHP offers dual syntax:
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
Maybe it makes sense to put this option on the ballot if it passes a vote,
it will be possible to put an end to the discus?
Hi Andrey,
On 15 Jan 2015, at 19:20, Andrey Andreev n...@devilix.net wrote:
Consider this badly designed API:
declare(strict_typehints=TRUE);
const MODE_APPEND = 0;
const MODE_TRUNCATE = 1;
const MODE_PREPEND = 2;
function write_file(string $path, int $mode, string
Hi Andrea,
On Thu, Jan 15, 2015 at 9:52 PM, Andrea Faulds a...@ajf.me wrote:
Sure, weak typing is much poorer than strict typing for error checking. Does
that mean the user should be prevented from having the choice?
Are you simply opposed to the idea of weak types in general?
I am
Hi,
I would like to call everyone's attention, specially people
contributing directly to this RFC series, to what S.A.N just said:
Many developers PHP offers dual syntax:
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
Maybe it makes sense to put this option on the
Am 15.01.2015 um 20:45 schrieb Marcio Almada:
Hi,
I would like to call everyone's attention, specially people
contributing directly to this RFC series, to what S.A.N just said:
Many developers PHP offers dual syntax:
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
What about doing both weak and strict with two different syntaxes?
public function __construct(string $name, $age as int, $cuteness as float, bool
$evil) {
string $name // strict
$age as int // weak
$cuteness as float // weak
bool $evil // strict
as Syntax is taken from SQL92.
Regards
Thomas
Am 14.01.2015 um 23:39 schrieb Andrea Faulds:
Hi Marc,
On 14 Jan 2015, at 19:01, Marc Bennewitz dev@mabe.berlin wrote:
1. Inconsistencies of ZPP and explicit casts
In my opinion it should be the same if you call a function in weak type mode
and calling a function in strict type mode with
Wouldn't this one change render all code in PEAR as broken? Is the gain
really worth it?
I understand PEAR is basically dead anyways, but for better or worse
there is still a boat load of code that is being used from it (much of
which lacks decent alternatives), and as other people mentioned
On 02/01/2015 17:04, Nikita Popov wrote:
Voting on the removal of deprecated functionality in PHP 7 is now open:
https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7#votes
As requested, I've split this up in many individual votes, only some
particularly trivial function
On 15 January 2015 20:16:54 GMT, Thomas Bley ma...@thomasbley.de wrote:
What about doing both weak and strict with two different syntaxes?
public function __construct(string $name, $age as int, $cuteness as
float, bool $evil) {
string $name // strict
$age as int // weak
$cuteness as float //
Andrey Andreev wrote:
I like both, I want to use both for different use cases and I don't
see what is it that will be bad about co-existence.
Any library author who wants strictness *will* force it on you, even
if that means writing 3x times more code.
Why would a library author want such
On Jan 15, 2015 10:24 PM, Benjamin Eberlei kont...@beberlei.de wrote:
On Thu, Jan 15, 2015 at 4:11 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not sure how that helps, since you would tag versions anyways using
semver,
Hi!
1. Strict
function bar(int $num){}
2. Lax
function bar((int) $num){}
I would rather have int $num for coercive typing - given that close to
100% of existing typed functions - namely internal functions - mean
exactly that and are actually documented with this exact syntax. Yes,
there are
I think the problem with the current rfc is:
test(42);
function test(string $a) does test((string)$a);
function test(array $a) does not test((array)$a); although casting would be
possible.
So for consistency we might change the syntax or adapt array/object type hints
with casting (BC-break).
Hi!
I’m not really sure this is true. I agree that strict types aren’t
entirely in keeping with the “PHP way”. However, there are plenty of
people who are against them not for that reason, but simply because
they don’t work well for them. Plus, I’m not sure strict typing
I would say for
Hi Thomas,
On 15 Jan 2015, at 22:25, Thomas Bley ma...@thomasbley.de wrote:
I think the problem with the current rfc is:
test(42);
function test(string $a) does test((string)$a);
function test(array $a) does not test((array)$a); although casting would be
possible.
So for consistency
On 15 January 2015 at 17:35, Pierre Joye pierre@gmail.com wrote:
On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote:
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote:
On Fri, Jan 16, 2015 at 8:14 AM, Adam Harvey ahar...@php.net wrote:
On 15 January 2015 at 17:35, Pierre Joye pierre@gmail.com wrote:
On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote:
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
On Tue, Nov 18, 2014 at 3:11
On 16/01/15 03:48, Joshua Rogers wrote:
Should the patch, perhaps be inside the spprintf() function?
That would take care of future problems, too.
Thoughts?
Ok, so, there are many many places where 'error' is not checked against
NULL. So I'm going to submit a patch that will fix this in the
Hi Levi,
On Wed, Jan 14, 2015 at 6:18 PM, Levi Morrison le...@php.net wrote:
[1]: https://wiki.php.net/rfc/return_types#vote
I read the RFC quickly and could not find closure syntax example.
function():array use ($var) {}
or
function() use ($var): array {}
which one will be the syntax?
On 16/01/2015, at 18:46, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Levi,
On Wed, Jan 14, 2015 at 6:18 PM, Levi Morrison le...@php.net wrote:
[1]: https://wiki.php.net/rfc/return_types#vote
I read the RFC quickly and could not find closure syntax example.
function():array use
Hello,
Please consider the following PHP code:
while ( CONDITION ) {
STATEMENT
}
It currently compiles to something like this for the Zend Engine:
0: CONDITION
1: JMPZ - 4
2: STATEMENT
3: JMP - 0
4: ...
This can easily be rewritten in an equivalent but much more efficient form:
0: JMP - 2
Hi,
Sorry for the late reply.
在 2015年1月15日 星期四，下午1:21，Rasmus Lerdorf 写道：
On 01/14/2015 07:24 PM, Xinchen Hui wrote:
On Thu, Jan 15, 2015 at 1:53 AM, Julien Pauli jpa...@php.net
(mailto:jpa...@php.net) wrote:
I obviously will help porting some of them.
as I remembered, memcached
Hi,
On Thu, Jan 15, 2015 at 7:13 PM, Andrea Faulds a...@ajf.me wrote:
Now from that perspective I cannot rely that I am in strict and would have
to handle the default weak even although I declared in my class that i
wanted strict mode which only affected the code inside of that file.
On 15 Jan 2015, at 19:52, Andrea Faulds a...@ajf.me wrote:
Sure, weak typing is much poorer than strict typing for error checking. Does
that mean the user should be prevented from having the choice?
Are you simply opposed to the idea of weak types in general?
Another way to put this:
On 15.01.2015 21:35, Mike wrote:
Wouldn't this one change render all code in PEAR as broken?
No.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner /
I don't think any junior-middle php developer with understand how (int) works.
Just make a test and see how many will answer (int)'asd' with 1.
Regards
Thomas
S.A.N wrote on 15.01.2015 22:18:
The main advantage of the two syntaxes:
1. Strict
function bar(int $num){}
2. Weak
function
S.A.N,
The main advantage of the two syntaxes:
1. Strict
function bar(int $num){}
2. Weak
function bar((int) $num){}
Any junior-middle PHP developer, seeing this syntax in the code can
understand how it works, without studying the documentation and without
your complex conversion
Hi!
And to hell with the consistency argument. Since when did PHP become
*that* concerned about purity and high consistency levels? Call this a
The purity part should be addressed to strict proponents - it's their
purist sensibilities that are offended by converting '23' to 23 ;) As
for
Stanislav Malyshev,
I would rather have int $num for coercive typing - given that close to
100% of existing typed functions - namely internal functions - mean
exactly that and are actually documented with this exact syntax.
[...]
As for strict, maybe it can be int! $num or something like
Stanislav Malyshev,
detriment of coercive types simply because there is no general
consensus about what strict means :)
I don't see any place for consensus and non-consensus here -
unless you want to redefine words to have arbitrary meanings so nobody
understands you, it is pretty clear
Hi!
The hole point (at least for me) for being against `function bar(int
$num){}` to achieve type coercion is that the syntactic equivalent
code `function bar(array $numbers){}` won't do any coercion - (array)
$numbers - because BC break would be too big to handle.
Having
On Nov 26, 2014 1:39 AM, Adam Harvey ahar...@php.net wrote:
On 25 November 2014 at 10:36, Sara Golemon poll...@php.net wrote:
On Tue, Nov 18, 2014 at 3:11 PM, Levi Morrison le...@php.net wrote:
https://wiki.php.net/rfc/remove_php4_constructors
Entirely +1 on removing them in PHP7.
Hi!
detriment of coercive types simply because there is no general
consensus about what strict means :)
I don't see any place for consensus and non-consensus here - unless
you want to redefine words to have arbitrary meanings so nobody
understands you, it is pretty clear what strict means -
Hi!
Even Nikic presented different versions of strict proposals on an
old article
http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html
I don't see different versions - I see one version of strict which
matches my description and which he unequivocally opposes.
On 01/14/2015 06:05 PM, Dan Ackroyd wrote:
On 14 January 2015 at 21:21, Michael Wallner m...@php.net wrote:
* imagick
Most of the work was done while it was still called NG:
https://github.com/danack/imagick/tree/phpng . Which means that branch
probably won't work against master as there
---
main/streams/plain_wrapper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/main/streams/plain_wrapper.c b/main/streams/plain_wrapper.c
index f52383d..72be0b0 100644
--- a/main/streams/plain_wrapper.c
+++ b/main/streams/plain_wrapper.c
@@ -669,7 +669,8 @@ static int
On Thu, Jan 15, 2015 at 8:56 AM, Dmitry Stogov dmi...@zend.com wrote:
ext/session and ext/json are required by most apps.
Right.
The question is: Do you see any other we must have before discussing
that any further?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
From: Joshua Rogers g...@internot.info
---
main/streams/plain_wrapper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/main/streams/plain_wrapper.c b/main/streams/plain_wrapper.c
index f52383d..72be0b0 100644
--- a/main/streams/plain_wrapper.c
+++
I don't know which ones are supported or not.
Of course we need some extension to connect to database mysql, mysqli or
pdo_mysql.
Thanks. Dmitry.
On Thu, Jan 15, 2015 at 11:03 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Jan 15, 2015 at 8:56 AM, Dmitry Stogov dmi...@zend.com wrote:
On 15/01/15 07:26, Pavel Kouřil wrote:
And yesterday I was pointed out one thing: the RFC states With this
approach, an argument is only accepted if its type is exactly the same
as the parameter.. Does this mean you cannot pass integer to a
function with float argument in the strict mode?
One
Hey:
On Thu, Jan 15, 2015 at 4:02 PM, Joshua Rogers g...@internot.info wrote:
---
main/streams/plain_wrapper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/main/streams/plain_wrapper.c b/main/streams/plain_wrapper.c
index f52383d..72be0b0 100644
---
On 15 Jan 2015, at 11:01, Andrea Faulds a...@ajf.me wrote:
Hey Dmitry,
On 15 Jan 2015, at 07:56, Dmitry Stogov dmi...@zend.com wrote:
ext/session and ext/json are required by most apps.
Actually I stopped attempts to build it when I saw compilation errors in
ext/session.
Thanks.
Hi Dmitry,
On 15 Jan 2015, at 11:11, Dmitry Stogov dmi...@zend.com wrote:
BTW: why not to wrap big integers into special IS_OBJECT?
It would keep everything working out of the box (without BIGINT), and would
allow to eliminate more than half of unnecessary changes.
In the past we made
On
15
Jan
2015,
at
0:33, Andrea Faulds a...@ajf.me:
Hi Marcio,
On 14 Jan 2015, at 18:52, Marcio Almada marcio.w...@gmail.com wrote:
We still have a BC break but now we also have code with **mutant**
behavior that might become buggy (do unexpected things) if a `declare` is
used. As a
Hey:
On Thu, Jan 15, 2015 at 6:42 AM, Andrea Faulds a...@ajf.me wrote:
Hey Dmitry,
On 14 Jan 2015, at 20:40, Dmitry Stogov dmi...@zend.com wrote:
In my opinion, version 0.1 was consistent enough.
handling two different approaches just makes mess...
We have internal function strlen(string
Hey Dmitry,
On 15 Jan 2015, at 07:56, Dmitry Stogov dmi...@zend.com wrote:
ext/session and ext/json are required by most apps.
Actually I stopped attempts to build it when I saw compilation errors in
ext/session.
Thanks. Dmitry.
Oh dear, does ext/session not build? :/
So far I've only
BTW: why not to wrap big integers into special IS_OBJECT?
It would keep everything working out of the box (without BIGINT), and would
allow to eliminate more than half of unnecessary changes.
In the past we made similar decision for closures.
Thanks. Dmitry.
On Thu, Jan 15, 2015 at 2:01 PM,
Hi,
On 15/01/15 21:49, Xinchen Hui wrote:
do you have a test script to show how to reproduce the error?
thanks
No, I don't.
But, if you run `grep -nr do_fstat main/streams/plain_wrapper.c -C3',
you can see the result is compared against '0' everywhere else it is used.
Thanks,
--
-- Joshua
On Thu, Jan 15, 2015 at 9:29 AM, Lester Caine les...@lsces.co.uk wrote:
One of the nice features of PHP when I started using it all those years
ago was that I did not have to create separate functions different types
did exist in the source data. int/float/num/double and others all needed
On 15/01/15 08:49, Pavel Kouřil wrote:
One of the nice features of PHP when I started using it all those years
ago was that I did not have to create separate functions different types
did exist in the source data. int/float/num/double and others all needed
separate handling in c/c++, and
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Thursday, January 15, 2015 12:29 AM
To: Zeev Suraski
Cc: rquadl...@gmail.com; Leigh; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Zeev,
On 14 Jan 2015, at 13:35, Zeev Suraski
Zeev Suraski wrote on 15/01/2015 11:56:
PLUS have the ability to radically
change how it behaves based on a runtime option. It's so bad that we
decided more than a decade ago that we want to refrain from ever introducing
such elements to PHP again (e.g. magic_quotes_runtime), and I'm not sure
Hi Stas,
On 14 Jan 2015, at 23:29, Stanislav Malyshev smalys...@gmail.com wrote:
I agree. Being wrong is bad, making a mistake is bad, but having split
personality language and not knowing in which world you are - or even
worse, having to deal with both worlds in the same code and being
Hi Zeev,
On 15 Jan 2015, at 11:56, Zeev Suraski z...@zend.com wrote:
Andrea,
I'm not sure what you're basing that assumption on. The incidental
interactions you (or anybody) may have with 'the community', by no way
represent the opinion of the community at large. The vast majority of
Hey Rowan,
On 15 Jan 2015, at 13:02, Rowan Collins rowan.coll...@gmail.com wrote:
Zeev Suraski wrote on 15/01/2015 11:56:
PLUS have the ability to radically
change how it behaves based on a runtime option. It's so bad that we
decided more than a decade ago that we want to refrain from
The main advantage of the two syntaxes:
1. Strict
function bar(int $num){}
2. Weak
function bar((int) $num){}
Any junior-middle PHP developer, seeing this syntax in the code can
understand how it works, without studying the documentation and without
your complex conversion tables.
Explicit is
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Thursday, January 15, 2015 4:10 PM
To: Zeev Suraski
Cc: rquadl...@gmail.com; Leigh; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Zeev,
Whether or not they are in the majority, a very
On Jan 16, 2015 7:03 AM, Pierre Joye pierre@gmail.com wrote:
On Jan 15, 2015 10:24 PM, Benjamin Eberlei kont...@beberlei.de wrote:
On Thu, Jan 15, 2015 at 4:11 PM, Jan Ehrhardt php...@ehrhardt.nl
wrote:
Benjamin Eberlei in php.internals (Thu, 15 Jan 2015 15:53:43 +0100):
Not
1 - 100 of 101 matches
Mail list logo
