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
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,
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 that it
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
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
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
-1 to expect is a problem. expect is not a problem.
Le 21 octobre 2013 à 10:42, Joe Watkins krak...@php.net a écrit :
On 10/21/2013 09:57 AM, Tjerk Meesters wrote:
On Mon, Oct 21, 2013 at 4:16 PM, Michael Wallner m...@php.net wrote:
On 21 October 2013 10:13, Patrick Schaaf b...@bof.de
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
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
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
On 22 October 2013 02:08, Derick Rethans der...@php.net 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
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
machines
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 22 October 2013 10:32, Joe Watkins pthre...@pthreads.org 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
On Wed, Oct 23, 2013 at 3:20 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Andrea,
On Wed, Oct 23, 2013 at 9:26 AM, Andrea Faulds a...@ajf.me wrote:
But it already exists. Why add *another* alias? We should make
apache_response_headers() have a consistent alias, something like
15 matches
Mail list logo
