Dan Ackroyd wrote on 08/01/2016 18:36:
Apologies, it should be:
$counts[$item] = ($counts[$item] ?? 0) + 1;
Which both works, and to me, is more readable than the @ version
As with the file-manipulation functions, I think you're focussing too
much on the specific example and not on the gener
Dan Ackroyd wrote on 08/01/2016 18:44:
You're suggesting that we solve a problem in a way that pretty much
every other attempt to do has failed.
I'm not sure where you got the idea that I was suggesting anything of
the sort.
it's only by
encountering all of the small problems that you can
Hi!
> when doing something defined as invalid will be hard. If you don't want
> to count garbage, then you should use if()
>
> if (!is_garbage($key)) @$count[$key]++;
And if you want to check, just do:
if (is_garbage($key)) { throw Exception("Garbage!"); }
Except in this case you know what's g
On 8 January 2016 at 16:51, Rowan Collins wrote:
> I detect sarcasm here, and would like to hear a non-sarcastic version of
> your point.
You're suggesting that we solve a problem in a way that pretty much
every other attempt to do has failed.
I'm not going to be able to point to a single reason
Ryan Pallas wrote on 08/01/2016 18:29:
I agree with Dan on this one. Trying to use an invalid type as a key
should produce something. Your argument that its garbage and you don't
care may be valid for a specific use case, but it may also be a bug in
another case
But that has nothing to do wit
On 8 January 2016 at 18:21, Stanislav Malyshev wrote:
> Hi!
> This looks completely unreadable and I do not think it works:
> https://3v4l.org/PlAHH
> Seems to leave $counts as 1 always. But even if it didn't, I would never
> pass that on code review - it is very hard to understand what's going o
On Fri, Jan 8, 2016 at 11:21 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > $counts[$item] ?? $counts[$item] = 1 ?? $counts[$item]++;
>
> This looks completely unreadable and I do not think it works:
> https://3v4l.org/PlAHH
> Seems to leave $counts as 1 always. But even if it didn't, I would never
>
Hi!
> $counts[$item] ?? $counts[$item] = 1 ?? $counts[$item]++;
This looks completely unreadable and I do not think it works:
https://3v4l.org/PlAHH
Seems to leave $counts as 1 always. But even if it didn't, I would never
pass that on code review - it is very hard to understand what's going on
an
Dan Ackroyd wrote on 08/01/2016 16:26:
On 8 January 2016 at 15:48, Rowan Collins wrote:
It doesn't do anything to help Stas's example for instance:
@$counts[$item]++;
I think that that code is bogus since the release of PHP 7, which made
it trivial to not use the error suppression for this ca
On 8 January 2016 at 15:48, Rowan Collins wrote:
>
> It doesn't do anything to help Stas's example for instance:
>
> @$counts[$item]++;
I think that that code is bogus since the release of PHP 7, which made
it trivial to not use the error suppression for this case, while still
writing code that d
Dan Ackroyd wrote on 06/01/2016 17:12:
Work on a plan on how to migrate all internal errors/warnings to
individual exceptions. The current way of using set_error_handler to
convert warnings/errors into generic exceptions isn't good enough.
Again, you're focussing exclusively on that sub-set of
On 6 January 2016 at 18:55, Ryan Pallas wrote:
> Hi Dan,
>
> having the function name as a string will make it harder to find in an IDE
> since go to definition won't work (and since functions aren't first class
> citizens as in javascript, we can't pass a raw name AFAIK)
Yes, this is a limition
Hi Dan,
On Wed, Jan 6, 2016 at 10:12 AM, Dan Ackroyd wrote:
>
>
> // If FileException, NetworkException are thrown inside 'foo',
> // they are automatically
> // caught and execution continues to call bar()
> foo() suppress FileException, NetworkException;
> bar();
>
>
> That would allow people
On 31 December 2015 at 14:52, Junade Ali wrote:
> Hi all;
>
> I am looking to submit an RFC in order to remove the error suppression
> operator in PHP, namely the @ symbol.
>
Hi Junade,
TL:DR - I think just deprecating the silence operator without having a
plan for something better is not going
On Tue, 5 Jan 2016, Sara Golemon wrote:
> On Tue, Jan 5, 2016 at 12:24 PM, Aaron Piotrowski wrote:
>
> > Before anything can be done with the @ operator, changes will need
> > to be made to remove warnings for conditions that the code has no
> > way of checking prior to calling these functions.
On 05/01/2016 19:55, Sara Golemon wrote:
So the argument being made is that being able to disable @ suppression
means ignoring whatever value the developer/admin has set for
error_reporting.
Sure, that's what the setting would mean; just as setting
error_reporting means ignoring somebody els
On Tue, 5 Jan 2016, Sara Golemon wrote:
> On Tue, Jan 5, 2016 at 3:57 AM, Zeev Suraski wrote:
>
> >> From: Derick Rethans [mailto:der...@php.net]
> >> That's going to mean an INI setting.. that hosters could abuse.
> >> Having an INI setting like this as part of core is IMO not a great idea.
> >
On Tue, Jan 5, 2016 at 12:24 PM, Aaron Piotrowski wrote:
> Before anything can be done with the @ operator, changes will need to
> be made to remove warnings for conditions that the code has no way of
> checking prior to calling these functions.
>
I'd include pragmatism in that calculus. fopen()
> On Jan 5, 2016, at 12:22 PM, Sara Golemon wrote:
>
> On Tue, Jan 5, 2016 at 10:09 AM, Ferenc Kovacs wrote:
I don't think that would work out too well. Remember that many projects
have
error handles which convert all errors to exceptions: if you disable @
in
those proj
On Tue, Jan 5, 2016 at 11:40 AM, Rowan Collins wrote:
>> @ changes the error_reporting() level for that particular call, so those
>> custom error handler won't throw exceptions for the suppressed errors but
>> when you remove/nop @ their code would throwing stuff left and right.
>
>
> I'm lost - h
Ferenc Kovacs wrote on 05/01/2016 18:09:
sure and most projects check the error_reporting() level against the $errno
like in the manual:
if (!(error_reporting() & $errno)) {
// This error code is not included in error_reporting
return;
}
@ changes the error_reporting(
On Tue, Jan 5, 2016 at 10:09 AM, Ferenc Kovacs wrote:
>> > I don't think that would work out too well. Remember that many projects
>> > have
>> > error handles which convert all errors to exceptions: if you disable @
>> > in
>> > those projects, wouldn't their code break?
>> >
>> Nope.
>> Supresse
On Tue, Jan 5, 2016 at 6:53 PM, Sara Golemon wrote:
> On Tue, Jan 5, 2016 at 9:37 AM, Andrea Faulds wrote:
> >> How about a global "disable error suppression" setting? That way a
> >> project lead could enforce it for their codebase (and guarantee that
> >> devs "aren't lazy"), but PHP doesn't
On Tue, Jan 5, 2016 at 9:37 AM, Andrea Faulds wrote:
>> How about a global "disable error suppression" setting? That way a
>> project lead could enforce it for their codebase (and guarantee that
>> devs "aren't lazy"), but PHP doesn't lose its pragmatism?
>
> I don't think that would work out too
On Tue, Jan 5, 2016 at 3:57 AM, Zeev Suraski wrote:
>> From: Derick Rethans [mailto:der...@php.net]
>> That's going to mean an INI setting.. that hosters could abuse.
>> Having an INI setting like this as part of core is IMO not a great idea.
>
I honestly don't understand why that's a bad idea. T
Hi Sara,
Sara Golemon wrote:
On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali wrote:
I am looking to submit an RFC in order to remove the error suppression
operator in PHP, namely the @ symbol.
Forwarding a suggestion twitter/@Beryllium9:
How about a global "disable error suppression" setting?
Grzegorz Zdanowski wrote on 05/01/2016 12:27:
Before deprecating @ operator I think we should make a RFC which cover
unified setting to convert all E_* to exceptions (like
PhpWarningException). I know it's just a temporary solution, because
exception should be more specific, but it's a huge amoun
>> -Original Message-
>> From: Derick Rethans [mailto:der...@php.net]
>> Sent: Tuesday, January 05, 2016 12:57 PM
>> To: Michael Heap
>> Cc: Sara Golemon; Junade Ali; PHP internals
>> Subject: Re: [PHP-DEV] Deprecation of the Error Control Operator (@
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Tuesday, January 05, 2016 12:57 PM
> To: Michael Heap
> Cc: Sara Golemon; Junade Ali; PHP internals
> Subject: Re: [PHP-DEV] Deprecation of the Error Control Operator (@
> symbol)
>
>
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Tuesday, January 05, 2016 7:28 AM
> To: Sara Golemon; Stanislav Malyshev
> Cc: Junade Ali; PHP internals
> Subject: Re: [PHP-DEV] Deprecation of the Error Control Operator (@
> symbol)
&g
On Tue, 5 Jan 2016, Michael Heap wrote:
>
> On Tue, Jan 5, 2016 at 5:45 AM, Sara Golemon wrote:
>
> > On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali wrote:
> > > I am looking to submit an RFC in order to remove the error suppression
> > > operator in PHP, namely the @ symbol.
> > >
> > Forwarding
Sounds like the xdebug.scream or the Scream PECL extension (
https://pecl.php.net/package/scream) to me.
+1 for baking this functionality into core
On Tue, Jan 5, 2016 at 5:45 AM, Sara Golemon wrote:
> On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali wrote:
> > I am looking to submit an RFC in orde
Hi, chiming in from the side,
On Tue, Jan 5, 2016 at 12:45 AM, Sara Golemon wrote:
> Forwarding a suggestion twitter/@Beryllium9:
>
> How about a global "disable error suppression" setting? That way a
> project lead could enforce it for their codebase (and guarantee that
> devs "aren't lazy"), b
On Mon, Jan 4, 2016 at 9:45 PM, Sara Golemon wrote:
> On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali wrote:
>> I am looking to submit an RFC in order to remove the error suppression
>> operator in PHP, namely the @ symbol.
>>
> Forwarding a suggestion twitter/@Beryllium9:
>
> How about a global "dis
On Thu, Dec 31, 2015 at 6:52 AM, Junade Ali wrote:
> I am looking to submit an RFC in order to remove the error suppression
> operator in PHP, namely the @ symbol.
>
Forwarding a suggestion twitter/@Beryllium9:
How about a global "disable error suppression" setting? That way a
project lead could
On 01/04/2016 07:22 PM, Sara Golemon wrote:
> On Thu, Dec 31, 2015 at 1:10 PM, Stanislav Malyshev
> wrote:
>> I don't think it is a good idea, currently, for the following reasons:
>>
> [::snip::]
>
> It terrifies me to say this, but I completely agree with Stas. ;)
>
> I can't personally remem
On Thu, Dec 31, 2015 at 1:10 PM, Stanislav Malyshev wrote:
> I don't think it is a good idea, currently, for the following reasons:
>
[::snip::]
It terrifies me to say this, but I completely agree with Stas. ;)
I can't personally remember the last time I used @ in any production
code, but my one
Hi Bishop,
> On Dec 31, 2015, at 3:48 PM, Bishop Bettini wrote:
>
> I am -1 on removing @ for 7.x series. But, I would be in favor of all
> changes that remove unnecessary error messages or add functionality to
> better work with error messages. In my mind, those are requisite steps
> before r
Hi Bishop,
Bishop Bettini wrote:
I am -1 on removing @ for 7.x series. But, I would be in favor of all
changes that remove unnecessary error messages or add functionality to
better work with error messages. In my mind, those are requisite steps
before removing @.
I agree here.
It'd be nice i
On Thu, Dec 31, 2015 at 4:10 PM, Stanislav Malyshev
wrote:
>
> The inherent problem is that some error reporting is unneeded in some
> contexts, while welcome in others. That's the problem that needs
> solving, the syntax is secondary to it.
>
That hits the nail on the head.
When triggered erro
Hi!
> I am looking to submit an RFC in order to remove the error suppression
> operator in PHP, namely the @ symbol.
I don't think it is a good idea, currently, for the following reasons:
1. A lot of functions produce error messages which may not be important
in specific scenario, and the users
Le jeu. 31 déc. 2015 à 16:42, Dennis Birkholz a
écrit :
> Hi all,
>
> Am 31.12.2015 um 15:52 schrieb Junade Ali:
> > I am looking to submit an RFC in order to remove the error suppression
> > operator in PHP, namely the @ symbol.
>
> before you can deprecate the @ operator, there is a lot of work
Hi all,
Am 31.12.2015 um 15:52 schrieb Junade Ali:
> I am looking to submit an RFC in order to remove the error suppression
> operator in PHP, namely the @ symbol.
before you can deprecate the @ operator, there is a lot of work to do
beforehand. A lot of functions print warnings when they fail (i
On 31/12/2015 14:52, Junade Ali wrote:
I am looking to submit an RFC in order to remove the error suppression
operator in PHP, namely the @ symbol.
While few and far between, there are still valid use cases for the
suppression operator, for example when using curl
--
Mark Baker
_
|.
Hi all;
I am looking to submit an RFC in order to remove the error suppression
operator in PHP, namely the @ symbol.
I am happy to implement this, although it is merely a concept so far.
My reasons for looking to do this are:
- the error suppression operator leads to developers being lazy about
45 matches
Mail list logo
