I took the time to rewrite the case for PHP 7. It's a complete rewrite
written by someone who actually believes that this is the right choice for
us to pick :)
I'm sure people will have comments and may want to both improve the case
for 6 and 7 - so I do recommend we give it another extra week
Am 13.07.2014 07:22, schrieb Stas Malyshev:
I think it was a mistake to introduce this term from the start and
we should stop propagating it.
What would be a better term? Optional strict typing in function and
method signatures?
--
PHP Internals - PHP Runtime Development Mailing List
To
On 20 Jul 2014, at 07:08, Zeev Suraski z...@zend.com wrote:
I took the time to rewrite the case for PHP 7. It's a complete rewrite
written by someone who actually believes that this is the right choice for
us to pick :)
Great, we actually have a case now!
I'm sure people will have
On 20 Jul 2014, at 08:33, Sebastian Bergmann sebast...@php.net wrote:
Am 13.07.2014 07:22, schrieb Stas Malyshev:
I think it was a mistake to introduce this term from the start and
we should stop propagating it.
What would be a better term? Optional strict typing in function and
method
I'm sure people will have comments and may want to both improve the
case for 6 and 7 - so I do recommend we give it another extra week of
discussions to refine the RFC, and then restart the vote.
I'd rather not put it off much longer, but people can change votes, so I
could
extend the
On 20 Jul 2014, at 13:58, Zeev Suraski z...@zend.com wrote:
I do recommend to everyone who voted before there were separate 'Case for
PHP 6' and 'Case for PHP 7' to re-read the RFC one last time to see if it
changes their mind…
I’d second this and say people should perhaps read older
On 20/07/14 07:08, Zeev Suraski wrote:
I took the time to rewrite the case for PHP 7. It's a complete rewrite
written by someone who actually believes that this is the right choice for
us to pick :)
Is '6' really such an unlucky number? Wasn't Vista essentially Windows
6? ...
I don't have a
On 18 Jul 2014, at 14:09, Andrea Faulds a...@ajf.me wrote:
On 18 Jul 2014, at 06:02, Theodore Brown theodor...@outlook.com wrote:
Another concern I have is in regard to the future. I'm looking forward to
the
possibility of specifying nullable types in a future version of PHP (see
Levi
On 20 Jul 2014, at 14:11, Andrea Faulds a...@ajf.me wrote:
double
Did I just say double? I meant float, of course. :)
The patch actually warns you if you try to do this now:
function foo(double $foo) {}
foo(1.0);
If you use one of the non-existent aliases (double), and pass the type
On 14 Jul 2014, at 17:25, Anthony Ferrara ircmax...@gmail.com wrote:
And that also hints towards a benefit of adding a numeric hint as well
(which will accept (and cast to) either an int or a float, exactly how
is_numeric_string() does internally)... Which is something that may
want to be
2014.07.20. 14:43, Andrea Faulds a...@ajf.me ezt írta:
On 20 Jul 2014, at 08:33, Sebastian Bergmann sebast...@php.net wrote:
Am 13.07.2014 07:22, schrieb Stas Malyshev:
I think it was a mistake to introduce this term from the start and
we should stop propagating it.
What would be a
On 20 Jul 2014, at 15:54, Ferenc Kovacs tyr...@gmail.com wrote:
This proposal’s scalar type hints (except for booleans) can’t really be
called “strict”. Perhaps “firm typing”? (It’s not weak, but it’s not quite
strong either)
Stas and Sebastian are talking about the unfortunate naming
On 20 July 2014 00:26, Andrea Faulds a...@ajf.me wrote:
Good evening,
It is finally time to settle this matter once and for all. What shall be
the name of the next release of PHP: PHP 6 or PHP 7?
It might be just me, but the whole RFC actually seems particularly
one-sided. The argument for
On 29 June 2014 11:40, Timm Friebe p...@thekid.de wrote:
Dear all,
a couple of weeks ago, I proposed a change to the handling of the situation
where methods are called on non-objects. Instead of an E_ERROR, the engine
would
raise an E_RECOVERABLE_ERROR, and enable framework and library
On 20 Jul 2014, at 16:39, Peter Cowburn petercowb...@gmail.com wrote:
It might be just me, but the whole RFC actually seems particularly
one-sided. The argument for PHP 6 is very short and reads half-baked. The
overwhelming majority of this very short section of the RFC is spent
describing
On 21 May 2014 07:24, Pierre Joye pierre@gmail.com wrote:
On Tue, May 20, 2014 at 8:34 PM, David Soria Parra d...@php.net wrote:
Sounds very good and 0.8% overhead is fine. Can we work on getting this
integrated into a v2 of the RFC, continue hopefully constructive
discussions for
a
On 20 Jul 2014, at 16:43, Andrea Faulds a...@ajf.me wrote:
On 20 Jul 2014, at 16:39, Peter Cowburn petercowb...@gmail.com wrote:
It might be just me, but the whole RFC actually seems particularly
one-sided. The argument for PHP 6 is very short and reads half-baked. The
overwhelming
On 20 Jul 2014, at 00:26, Andrea Faulds a...@ajf.me wrote:
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
I’ve cancelled the vote because I don’t think the case for 6 is sufficiently
fleshed out. The RFC is now massively imbalanced
On 20 ביול 2014, at 18:51, Andrea Faulds a...@ajf.me wrote:
I swear the PHP 6 section was much longer before. Did Zeev delete some of it?
Zeev must have as the only person who edited it since was him.
I’ve restored the Rationale section from before to “The Case for PHP 6”.
Yes it was me -
On Jul 20, 2014, at 8:39 AM, Peter Cowburn petercowb...@gmail.com wrote:
As for the PHP 7 section, this is by far the dominant part of the RFC. Both
in terms of physical presence, but also points and counter-points.
It also contains, IMO unnecessarily, light-hearted and jokey comments not
On 18 Jul 2014, at 14:09, Andrea Faulds a...@ajf.me wrote:
I’ve updated the RFC and patch to make int, string and double nullability
work like the other types (bool already did). If the default value isn’t
NULL, NULL isn’t accepted and you’ll get E_RECOVERABLE_ERROR. If the default
value
Hi!
What would be a better term? Optional strict typing in function and
method signatures?
Parameter typing, or typed parameters if you will. One of the options,
of course, there could be many others.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP
On 20/07/14 16:55, Andrea Faulds wrote:
Voting shall end in a week’s time on 2014-07-27.
I’ve cancelled the vote because I don’t think the case for 6 is sufficiently
fleshed out. The RFC is now massively imbalanced in favour of 7, which isn’t
really fair to the 6 side, and I don’t think we
On Sun, 20 Jul 2014, Andrea Faulds wrote:
On 20 Jul 2014, at 00:26, Andrea Faulds a...@ajf.me wrote:
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
I’ve cancelled the vote because I don’t think the case for 6 is
On 20 Jul 2014, at 22:13, Derick Rethans der...@php.net wrote:
Huh what? This is like you weren't happy with the way how the vote was
going so you cancelled it? What nonsense.
That is not why I cancelled the vote and I would appreciate it if people would
stop insinuating as much.
--
Andrea
On Sun, Jul 20, 2014 at 11:13 PM, Derick Rethans der...@php.net wrote:
On Sun, 20 Jul 2014, Andrea Faulds wrote:
On 20 Jul 2014, at 00:26, Andrea Faulds a...@ajf.me wrote:
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
On 20 Jul 2014, at 22:28, Nikita Popov nikita@gmail.com wrote:
After the vote has been started the RFC was edited by Zeev in order to
strengthen the case for PHP 7. There is nothing wrong with that, adding
additional arguments to an RFC is perfectly fine by me.
However at the same
On 20 ביול 2014, at 18:40, Peter Cowburn petercowb...@gmail.com wrote:
The argument for PHP 6 is very short and reads half-baked. The
overwhelming majority of this very short section of the RFC is spent
describing how naming the release “PHP 6” will be a problem, with a very
wishy-washy
On 21 ביול 2014, at 00:29, Nikita Popov nikita@gmail.com wrote:
However at the same time a number of paragraphs were removed that were
arguing for PHP 6, at least in part. The only thing that was left in The
case for PHP 6 was a single paragraph, of which half was really just an
On Sun, Jul 20, 2014 at 2:46 PM, Zeev Suraski z...@zend.com wrote:
On 21 ביול 2014, at 00:29, Nikita Popov nikita@gmail.com wrote:
However at the same time a number of paragraphs were removed that were
arguing for PHP 6, at least in part. The only thing that was left in The
case for
Hi Anthony,
I want to finish and close this issue.
On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Also, Deprecating crypt() without first discussing it (and having an
RFC to vote on) is not cool (and has been reverted):
Hi,
I'm trying to iterate through a hash table,
But the zend_hash_get_current_key() doesn't seem to move forward:
I'm getting duplicate output at the 'fprintf' part.
for(zend_hash_internal_pointer_reset_ex(ht, pos);
zend_hash_has_more_elements_ex(ht, pos) == SUCCESS;
On Mon, Jul 21, 2014 at 11:12 AM, Aaron Lewis the.warl0ck.1...@gmail.com
wrote:
Hi,
I'm trying to iterate through a hash table,
But the zend_hash_get_current_key() doesn't seem to move forward:
I'm getting duplicate output at the 'fprintf' part.
Thanks! It worked
On Mon, Jul 21, 2014 at 11:20 AM, Tjerk Meesters
tjerk.meest...@gmail.com wrote:
On Mon, Jul 21, 2014 at 11:12 AM, Aaron Lewis the.warl0ck.1...@gmail.com
wrote:
Hi,
I'm trying to iterate through a hash table,
But the zend_hash_get_current_key() doesn't seem to move
On 21/07/2014, at 10:04 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Anthony,
I want to finish and close this issue.
On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Also, Deprecating crypt() without first discussing it (and having an
RFC to vote on) is not
See below in blue:
I feel compelled to voice just how extremely inappropriate it seems to me
to delete the other side's argument on an RFC without any consultation.
What I proposed was that Zeev and maintain the 7 argument and Andrea
maintain the 6 argument. This effectively smells like
36 matches
Mail list logo
