On 22/10/2013 07:10, Yasuo Ohgaki wrote:
Hi all,
Any comments patch for this RFC?
Better E_NOTICE message is welcome.
I'm a native English speaker, how about "Calling crypt() without giving
a salt will not produce strong password hashes."?
It doesn't necessarily say you will produce a stro
> > Thumbs up for the idea as well, but I don't think we can live with the
> > implementation. BTW, that's a bit of a grey area but I think that
> > even if an idea is accepted, if there's no reasonably clean
> > implementation available for it, I don't think it can go in.
> >
> > Zeev
>
> As said
On Wed, Oct 23, 2013 at 3:20 AM, Yasuo Ohgaki wrote:
> Hi Andrea,
>
> On Wed, Oct 23, 2013 at 9:26 AM, Andrea Faulds wrote:
>
> > But it already exists. Why add *another* alias? We should make
> > apache_response_headers() have a consistent alias, something like
> > getresponseheaders(). Then we
On 22 October 2013 10:32, Joe Watkins wrote:
> On 10/22/2013 06:20 PM, Adam Harvey wrote:
>> I agree that something to replace the eval-based assert() would be
>> good. What if the new syntax simply respected assert_options(), and
>> assert_options() was extended to support an explicit ASSERT_EXCE
https://medium.com/building-potluck/be7ebb17deff
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 21 Oct 2013, Bob Weinand wrote:
> I have started the vote for extended keyword support RFC:
>
> https://wiki.php.net/rfc/keywords_as_identifiers
Just to explain why I voted "no". I think the idea is good, but what I
see from the patch is that it adds a *lot* of hand written state
machi
On 22 October 2013 02:08, Derick Rethans wrote:
> I'm pretty convinced that expectations *without* exceptions are a good
> idea, as using assert (which is really eval) is a nasty thing that
> should be replaced, but IMO exception throwing should not be part of
> this feature.
I agree that somethi
On 10/22/2013 11:30 AM, Pierre Joye wrote:
> I did not vote yet, however I agree with Derick. A cleaner solution
> would be better. We have lived with this restriction for some time
> already and we may as well delay this RFC until we have a viable
> technical solution. If anyone feels motivated en
On 10/21/2013 09:42 PM, Andrea Faulds wrote:
On 21/10/2013 21:36, rpar...@yamiko.org wrote:
This proposal sounds a lot like exceptions to me or am I missing
something :/
Could we do something like throw new expectation($expects, $message);
Er, T_EXPECT will be essentially a clone of Java and
Hi all,
Without 'true', session_regenerate_id() will not delete old session data
which may contain sensitive data. It was made to 'false' by default for
users relying on the bug. (PHP 4.x, IIRC)
Almost all users should call session_regenerate_id() with 'true' parameter.
Therefore, I would like to
Can someone with Zend karma take a look at this ?
https://github.com/php/php-src/pull/479/files
Replace invalid code with a proper #error
> This code creates a nasty error as mentioned in bugs #31131, #37062
> Patch taken from Debian's PHP package: 044-strtod_arm_fix
I would have merged myself,
Since this would throw exceptions, could it look like (or be) a
final/abstract (although PHP doesn't allow that combo for some reason)
class with static methods?
Assert::isTrue($expr, $msg);
That syntax is already valid (so of course there are BC issues) and I
don't know how practical it is to op
On 21/10/2013 21:36, rpar...@yamiko.org wrote:
This proposal sounds a lot like exceptions to me or am I missing
something :/
Could we do something like throw new expectation($expects, $message);
Er, T_EXPECT will be essentially a clone of Java and Python's assert
statement, but not called as
Matthew Leverton wrote (on 21/10/2013):
final/abstract (although PHP doesn't allow that combo for some reason)
Final means "cannot be sub-classed", abstract means "must be
sub-classed"; the combination would make no sense. Specifically, it
would allow completely illogical code like "final abs
-1 to "expect is a problem". expect is not a problem.
> Le 21 octobre 2013 à 10:42, Joe Watkins a écrit :
>
>
> On 10/21/2013 09:57 AM, Tjerk Meesters wrote:
> > On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner wrote:
> >
> >> On 21 October 2013 10:13, Patrick Schaaf wrote:
> >>> Am 21.10.201
On 10/21/2013 02:27 PM, Hochstrasser Christoph wrote:
Hi Derick,
This is again an RFC that does not even attempt to argue for its
usefulness. "This functionality was meant to replace the assert() API
that currently exists in PHP, because of problems replacing it in a
compatible manner". This do
On Fri, 18 Oct 2013, Joe Watkins wrote:
> Evening Chaps,
>
> Following on from discussion regarding assertion API in PHP, the
> following RFC is now up for discussion:
>
> https://wiki.php.net/rfc/expectations
>
> Please do point out any missing sections or information, so tha
17 matches
Mail list logo
