Unsuscribe
On 18 July 2014 15:10, Andrea Faulds wrote:
>
> On 18 Jul 2014, at 12:31, Jon Arano wrote:
>
> >>
>
> Were you meaning to say something?
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
Hi David,
On Mon, Jul 21, 2014 at 2:53 PM, David Muir wrote:
> Prehashing with sha512 means it is no longer blowfish. It is now a
> non-vetted DIY algorithm. The whole point of password_hash is to avoid this
> type of thing, and should be clearly discouraged in the documentation.
>
I agree. It'
On Jul 20, 2014 11:13 PM, "Derick Rethans" wrote:
>
> On Sun, 20 Jul 2014, Andrea Faulds wrote:
>
> >
> > On 20 Jul 2014, at 00:26, Andrea Faulds 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 can
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 blatan
On 21/07/2014, at 10:04 AM, Yasuo Ohgaki wrote:
> Hi Anthony,
>
> I want to finish and close this issue.
>
> On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki wrote:
>
>> Also, Deprecating crypt() without first discussing it (and having an
>>> RFC to vote on) is not cool (and has been reverted)
Thanks! It worked
On Mon, Jul 21, 2014 at 11:20 AM, Tjerk Meesters
wrote:
>
>
>
> On Mon, Jul 21, 2014 at 11:12 AM, Aaron Lewis
> 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 ou
On Mon, Jul 21, 2014 at 11:12 AM, Aaron Lewis
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.
>
>for(zend_hash_internal_pointer_reset_ex(ht, &pos);
>
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;
Hi Anthony,
I want to finish and close this issue.
On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki wrote:
> Also, Deprecating crypt() without first discussing it (and having an
>> RFC to vote on) is not cool (and has been reverted):
>>
>> http://svn.php.net/viewvc/phpdoc/en/trunk/reference/string
On Sun, Jul 20, 2014 at 2:46 PM, Zeev Suraski wrote:
> > On 21 ביול 2014, at 00:29, Nikita Popov 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 pa
> On 21 ביול 2014, at 00:29, Nikita Popov 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
> explanation of the ge
> On 20 ביול 2014, at 18:40, Peter Cowburn 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 conclusion that the
On 20 Jul 2014, at 22:28, Nikita Popov 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 time a number of p
On Sun, Jul 20, 2014 at 11:13 PM, Derick Rethans wrote:
> On Sun, 20 Jul 2014, Andrea Faulds wrote:
>
> >
> > On 20 Jul 2014, at 00:26, Andrea Faulds 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’v
On 20 Jul 2014, at 22:13, Derick Rethans 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 Faulds
http:/
On Sun, 20 Jul 2014, Andrea Faulds wrote:
>
> On 20 Jul 2014, at 00:26, Andrea Faulds 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
> sufficien
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
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 18 Jul 2014, at 14:09, Andrea Faulds 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 is NULL,
On Jul 20, 2014, at 8:39 AM, Peter Cowburn 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
> befitting an RFC
> On 20 ביול 2014, at 18:51, Andrea Faulds 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 - but
On 20 Jul 2014, at 00:26, Andrea Faulds 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 in favou
On 20 Jul 2014, at 16:43, Andrea Faulds wrote:
>
> On 20 Jul 2014, at 16:39, Peter Cowburn 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 s
On 21 May 2014 07:24, Pierre Joye wrote:
> On Tue, May 20, 2014 at 8:34 PM, David Soria Parra 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 week or two and then vot
On 29 June 2014 11:40, Timm Friebe 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 authors to
>
On 20 Jul 2014, at 16:39, Peter Cowburn 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 how naming the rele
On 20 July 2014 00:26, Andrea Faulds 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 PHP 6 i
On 20 Jul 2014, at 15:54, Ferenc Kovacs 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 of the c
2014.07.20. 14:43, "Andrea Faulds" ezt írta:
>
>
> On 20 Jul 2014, at 08:33, Sebastian Bergmann 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?
On 14 Jul 2014, at 17:25, Anthony Ferrara 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 considered for thi
On 20 Jul 2014, at 14:11, Andrea Faulds 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 that
alia
On 18 Jul 2014, at 14:09, Andrea Faulds wrote:
> On 18 Jul 2014, at 06:02, Theodore Brown 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 Morrison's "Declaring Nu
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
On 20 Jul 2014, at 13:58, Zeev Suraski 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 discussions too.
> > 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
On 20 Jul 2014, at 08:33, Sebastian Bergmann 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 signatures?
On 20 Jul 2014, at 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 :)
Great, we actually have a case now!
> I'm sure people will have comments and may
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 u
38 matches
Mail list logo
