Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.
It's not clear why would that be an issue - can you specify what the
problem would be?
Also, if we changed `catch(Exception $e)` to not catch all
On Tue, Oct 7, 2014 at 10:55 AM, Dan Ackroyd dan...@basereality.com wrote:
Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.
It's not clear why would that be an issue - can you specify what the
From: Dan Ackroyd [mailto:dan...@basereality.com] ,Sent: Tuesday, October 07,
2014 10:55 AM
Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.
It's not clear why would that be an issue - can you
Hi Nikita,
I very like the idea.
Actually, it's a long time desired php feature that many big php users miss.
They don't like to show 500 response in any case.
Also +1 for removing ability of silent E_RECOVERABLE_ERROR bypass :)
I think that few things may be improved
1) I'm not sure if
On Tue, Oct 7, 2014 at 11:51 AM, Christian Stoller stol...@leonex.de
wrote:
From: Dan Ackroyd [mailto:dan...@basereality.com] ,Sent: Tuesday, October
07, 2014 10:55 AM
Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than
On 06.10.2014 23:53, Nikita Popov wrote:
Hi internals!
During the PHP 5.6 development cycle I have proposed an RFC [1] that
suggested the use of exceptions instead of fatal errors in the engine. At
the time the proposal was declined, because the change was judged too
intrusive for a minor
Lars Strojny wrote (on 06/10/2014):
Hi Nikita,
On 06 Oct 2014, at 23:53, Nikita Popov nikita@gmail.com wrote:
[...]
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with
Hi,
currently the 5.6 release schedule is not in sync with 5.4 and 5.5 which is
a bit inconvenient (it is easier to sync between the RMs if they are
targetting the same dates with their release, etc.) plus if we keep that
way, it will be a huge PITA when we have to do co-ordinated release
On Tue, Oct 7, 2014 at 4:08 PM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
currently the 5.6 release schedule is not in sync with 5.4 and 5.5 which
is a bit inconvenient (it is easier to sync between the RMs if they are
targetting the same dates with their release, etc.) plus if we keep that
Hi!
How is it better than:
$idx3 = $_POST['idx1']['idx2']['idx3'];
?
Regards,
Florian Margaine
Le 7 oct. 2014 18:05, Mathias Grimm mathiasgr...@gmail.com a écrit :
Hi,
I would like to suggest something for php like a class I am using
https://github.com/mathiasgrimm/arraypath
The reason
default value and existence of index checking.
I not a huge change, its a good change and very handy.
?php$post = array(
'user' = array(
'basicInformation' = array(
'name'= 'Mathias',
'surname' = 'Grimm'
),
));
// normal php way$sName=
This is handy just for programmers using recommended php.ini settings for
development (error_reporting = E_ALL and display_errors = On).
People using @, display_errors = Off or any other sort of sorcery don't
have such problems.
On Tue, Oct 7, 2014 at 5:14 PM, Mathias Grimm
On Tue, Oct 7, 2014 at 9:05 AM, Mathias Grimm mathiasgr...@gmail.com
wrote:
Hi,
I would like to suggest something for php like a class I am using
https://github.com/mathiasgrimm/arraypath
The reason is to access arrays like this:
$idx3 = ArrayPath::get('idx1/idx2/idx3', $_POST,
Great! That solves 75% of the problem.
Still accessing index using / (or other separator) would be very handy
$c = $_POST::path('a/b/c', 'def')
$c = $_POST::('a/b/c', 'def')
$c = $_POST@('a/b/c', 'def')
$c = $_POST::at('a/b/c', 'def')
I am not really creative now, but the part I would like to
For international user this makes more sense because the ' or the '' are
sensitive keys that needs two interactions instead of just one...
so for typing something like $_POST['asasdasd']['asdasd']['asdasd'] is
sometimes a bit annoying but it could be solved having 2 keyboard layouts
(my case)
As
On Tue, 2014-10-07 at 17:05 +0100, Mathias Grimm wrote:
Hi,
I would like to suggest something for php like a class I am using
https://github.com/mathiasgrimm/arraypath
The reason is to access arrays like this:
$idx3 = ArrayPath::get('idx1/idx2/idx3', $_POST, 'myDefaultValue');
what
That would cause some problems indeed. But you could scape as in other
strings.
at('a/\/b') not nice but we have the same for every string
On Tuesday, October 7, 2014, Johannes Schlüter johan...@schlueters.de
wrote:
On Tue, 2014-10-07 at 17:05 +0100, Mathias Grimm wrote:
Hi,
I would like to
Am 07.10.2014 um 18:05 schrieb Mathias Grimm mathiasgr...@gmail.com:
Hi,
I would like to suggest something for php like a class I am using
https://github.com/mathiasgrimm/arraypath
The reason is to access arrays like this:
$idx3 = ArrayPath::get('idx1/idx2/idx3', $_POST,
On 07.10.2014 14:15, Ferenc Kovacs wrote:
yes, this was also suggested before, but that will be also a BC break for
those people already using the name of the new parent class (
https://github.com/search?l=phpq=EngineExceptiontype=Codeutf8=%E2%9C%93
for example).
which can be still an ok
On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins rowan.coll...@gmail.com wrote:
Lars Strojny wrote (on 06/10/2014):
Hi Nikita,
On 06 Oct 2014, at 23:53, Nikita Popov nikita@gmail.com wrote:
[...]
As such I'm re-proposing this RFC for inclusion in PHP 7:
Hi!
yes, this was also suggested before, but that will be also a BC break
for those people already using the name of the new parent class
(https://github.com/search?l=phpq=EngineExceptiontype=Codeutf8=%E2%9C%93
for example).
This btw looks like a bigger issue (though many of them are
Hi!
1) I'm not sure if cacth(Exception $e) should catch engine and parser
exceptions. May be it's better to introduce interface or common parent
class Catchable and then make Exception, EngineException and
ParseException implement it. In case user would like to catch all the error
at once
On Tue, Oct 7, 2014 at 12:15 PM, Johannes Schlüter johan...@schlueters.de
wrote:
On Tue, 2014-10-07 at 17:05 +0100, Mathias Grimm wrote:
Hi,
I would like to suggest something for php like a class I am using
https://github.com/mathiasgrimm/arraypath
The reason is to access arrays like
Hi!
a little correction: 5.5.18 is expected next week (not in two weeks) and as
5.4 is in security fix mode, 5.4.34 will only happen when we have security
fixes to release.
Yes, time has passed since we started to discuss it :) 5.4/5.5 (and now
5.6) is expected on October 16th (tags go out on
On 7 October 2014 18:52:35 GMT+01:00, Levi Morrison le...@php.net wrote:
On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
As an example where a specific exception would be useful, but a
generic one
would not, consider a fluent interface which sometimes bugs out and
I would also argue that
you should never, in any language, catch a NPE. The only time you
should catch an NPE is if you are catching all exceptions, such as in
a FastCGI daemon that will cleanly shutdown afterwards.
If you're not allowed to catch it, why make it an exception? Benefits such as
On 07/10/2014 21:07, Levi Morrison wrote:
I would also argue that
you should never, in any language, catch a NPE. The only time you
should catch an NPE is if you are catching all exceptions, such as in
a FastCGI daemon that will cleanly shutdown afterwards.
If you're not allowed to catch it,
In every project I have worked on in the last few years, I've
implemented this. If I have an array that I can't be sure is well
formed and need to get a value at any depth without triggering
expensive notices, the recommended way today is to check if each value
is set and is an array:
Hi!
* opcache
For opcache I guess that'd be Dmitry probably.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I’ve addressed bug #68128 with the following PR:
https://github.com/php/php-src/pull/865
As usual, I went in fixing one thing and ended up changing more until the
results started to make sense.
I would appreciate another pair of eyes to glance over the changed code :)
Also, I’m hoping to
This request seems to be more in the realm of having XPath type support for
arrays, likewise people have also attempted to do this with JSON. It does
seem like it could be valuable to some degree, however, I don't necessarily
believe it belongs in the core. This seems much better for a PECL
31 matches
Mail list logo
