On 20 January 2018 at 01:25, Andreas Hennings wrote:
> On 19 January 2018 at 16:12, Sara Golemon wrote:
> > On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker
> wrote:
> >> On 18.01.2018 at 23:58, Stanislav Malyshev wrote:
> >>
> I propose even more such operators:
> null coalesce a
> where the three lines return `false`, the third [...]
Oops, that should say "the first two lines return `true`, the third
`false`" (the point here being that they return something, as opposed to
the later three, which throw).
On 9 December 2017 at 15:13, Aidan Woods wrote:
&
I prefer the inconsistency between `$x instanceof \stdClass` and `1
instanceof \stdClass`, than adding a warning (or throwing) to `$x
instanceof \stdClass` when `$x = 1`.
I think `1 instanceof \stdClass === false` would be reasonable.
1. PHP has no means of locking a variable to a type (i.e. the
with me 🤷♂️
On 25 October 2017 at 21:22, Helmut K. C. Tessarek
wrote:
> On 2017-10-25 15:38, Aidan Woods wrote:
> > I occasionally get emails from the mailing list bot warning I'll be
> > auto-unsubscribed because messages it is sending to me are are bouncing.
> >
To throw something else on the heap of things that need fixing in the mail
servers:
I occasionally get emails from the mailing list bot warning I'll be
auto-unsubscribed because messages it is sending to me are are bouncing.
(It sends me back the bounce notification it received, so I can see that
t
Hello Internals!
I'd like to gauge a reaction on a potential RFC proposal.
As per the RFC howto, I shall state that this would be a "concept" as I
don't have anyone lined up that would implement the feature, and I'm not a
C dev myself. (Though if no one volunteers I may take this as a learning
op
o
> execute a foreach on _something_, I think this alternate method might be a
> good option.
>
> Mark
>
>
> On Wed, Jul 12, 2017 at 12:18 PM Aidan Woods
> wrote:
>
>> > IMHO the whole error supression and its operator should be deprecated
>> and
gt;
> IMHO the whole error supression and its operator should be deprecated and
> removed from language. Supressing errors is just hiding problems because
> someone didn't want to solve it. Supressing errors makes debuging very hard
> and leads to frustration.
>
> >
> &
es a lot of sense. My
> only concern/issue would be to make sure that isn't considered a
> 'suppressor' -- but it's actual intent is to skip the execution of the
> foreach to prevent the error/loop from occurring (rather than just
> suppressing an error).
>
> Che
If you were willing to accept
```
foreach ($foo as $bar) if (is_array) {
...
}
```
as a solution, then you might as well use
```
if (is_array($foo)) foreach ($foo as $bar) {
...
}
```
I wonder if this could be better achieved by expanding what the error
suppression operator `@` can do? This ent
Hi all,
It might be useful to incorporate the "retry if" condition that'll likely
arise in use of this, into the feature itself. Such that after the retry
keyword you could optionally specify a truthy value.
Then you could write something like
$retries = 5;
try {
// …
} ca
So, if I understand everything here correctly
```
interface Foo
{
public function bar(Boo $Boo);
}
```
and
```
interface Foo
{
/*
* @param $Boo, pretty please accept type Boo here
*/
public function bar($Boo);
}
```
will be equivalent in 7.2? :(
Regards,
Aidan
On 28 May 2017 at 16
> Also, given the implementation above, why does the array have to be
ksorted
> correctly to count? Specifically, why isn't this array considered vector
> like?
> $arr = [
> 1=> 1,
> 0=> 0,
> ];
I suppose the question would be, given that array (or a similar
out-of-order array), should is_
13 matches
Mail list logo
