> 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 PE
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
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
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:
http://3v4l.o
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, why
>> 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
On 7 October 2014 18:52:35 GMT+01:00, Levi Morrison wrote:
>On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins
>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
>returns
>> NULL. If wrapped in
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 Tue, Oct 7, 2014 at 12:15 PM, Johannes Schlüter
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 this:
> >
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
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=php&q=EngineException&type=Code&utf8=%E2%9C%93
> for example).
This btw looks like a bigger issue (though many of them are n
On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins wrote:
> Lars Strojny wrote (on 06/10/2014):
>
>> Hi Nikita,
>>
>> On 06 Oct 2014, at 23:53, Nikita Popov wrote:
>> [...]
>>>
>>> As such I'm re-proposing this RFC for inclusion in PHP 7:
>>>
>>> https://wiki.php.net/rfc/engine_exceptions_for_php7
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=php&q=EngineException&type=Code&utf8=%E2%9C%93
> for example).
> which can be still an
Am 07.10.2014 um 18:05 schrieb Mathias Grimm :
> 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');
>
>
> Re
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
wrote:
> On Tue, 2014-10-07 at 17:05 +0100, Mathias Grimm wrote:
> > Hi,
> > I would like to suggest something
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');
w
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)
A
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
On Tue, Oct 7, 2014 at 9:05 AM, 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');
>
>
>
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
wrote:
> default val
default value and existence of index checking.
I not a huge change, its a good change and very handy.
array(
'basicInformation' => array(
'name'=> 'Mathias',
'surname' => 'Grimm'
),
));
// normal php way$sName=
isset($post['user']['basicInforma
Hi!
How is it better than:
$idx3 = $_POST['idx1']['idx2']['idx3'];
?
Regards,
Florian Margaine
Le 7 oct. 2014 18:05, "Mathias Grimm" a écrit :
> 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 ar
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');
Regards,
Mathias
On Tue, Oct 7, 2014 at 4:08 PM, Ferenc Kovacs 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
> way, it wi
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
containi
Lars Strojny wrote (on 06/10/2014):
Hi Nikita,
On 06 Oct 2014, at 23:53, Nikita Popov 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 the primary
difference
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 mi
On Tue, Oct 7, 2014 at 11:51 AM, Christian Stoller
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 before, i
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 "cact
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
On Tue, Oct 7, 2014 at 10:55 AM, Dan Ackroyd 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
> problem would be?
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 excep
32 matches
Mail list logo
