On Fri, 5 Apr 2019 at 09:03, Claude Pache wrote:
>
> That begs the question: why is this invalid for function calls?
At least in part, because if we ever wanted to add a standard
_toArray() method, like we have __toString(), it would be quite a
massive BC break if we already made it so that PHP a
Hello,
there is some trace of absolutism in every statements:
first;;; saying php is a highly dynamic is not not fact but a sorry ***
excuse; ain't part of engineering ; admitting php5 is a load of idiotic
mistakes yes; I like people going for reality not ideology; with facts you
can work with id
Afternoon internals,
Abolish Short Votes is now in voting:
https://wiki.php.net/rfc/abolish-short-votes
Cheers
Joe
On Fri, Apr 5, 2019 at 1:25 PM G. P. B. wrote:
> I'm all for it however isn't a 2/3 majority required for all RFCs now?
>
> Oh, indeed. Hadn't noticed that get voted on. Neat! Have updated RFC to
reflect. Thanks!
You're listing libsodium versions 0.15 and 0.13 there, but it should
be 1.0.15 and 1.0.13.
Maybe for everyone's reference: Ubuntu 16.04 LTS comes with no
libargon2, and with libsodium 1.0.8; 18.04 LTS comes with libargon2
and with libsodium 1.0.16.
Debian Stretch has 1.0.11, and 1.0.17 in backpor
On Fri, 5 Apr 2019 at 19:52, Sara Golemon wrote:
> I was originally planning to just do this since I thought it'd be
> non-controversial, but while implementing I discovered some gotchas, so I'm
> putting it to the group for discussion. Please give attention to the
> "Backward Incompatible Chang
I was originally planning to just do this since I thought it'd be
non-controversial, but while implementing I discovered some gotchas, so I'm
putting it to the group for discussion. Please give attention to the
"Backward Incompatible Changes" section.
https://wiki.php.net/rfc/sodium.argon.hash
-
>
> Yes, I think we are rapidly approaching the limit where to make the
> language stricter, we need an official static analysis tool, like Hack has,
> rather than trying to do everything at run-time.
It might even be possible to build this into OpCache somehow, so that if
> you pre-analyse your
On Thu, Apr 4, 2019, at 10:46 PM, Stephen Reay wrote:
> > Discussion:
> >
> > For me, the inability to work with arrays is the big problem with the
> > second approach. I very very often am type declaring my returns and
> > parameters as `iterable`, which means I may have an array and not know
> > If the static analyser was programmable, it would be possible to
> > provide it such information, within the scope of a single code base.
>
> In the case of data returned from a database, the metadata for the
> database is another source of information relating to that data, and it
> would be u
On 05/04/2019 14:05, Robert Hickman wrote:
I think you're misunderstanding the problem: it's not that the*programmer*
doesn't know the types, it's that the*analysis tool* doesn't know them,
because the programmer hasn't told it, and currently has no way to tell it.
If the static analyser wa
On Fri, 5 Apr 2019 at 14:05, Robert Hickman wrote:
> > I think you're misunderstanding the problem: it's not that the
> *programmer* doesn't know the types, it's that the *analysis tool* doesn't
> know them, because the programmer hasn't told it, and currently has no way
> to tell it.
> >
>
> If
On Fri, 5 Apr 2019 at 13:15, Rowan Collins wrote:
>
> On Fri, 5 Apr 2019 at 12:42, Robert Hickman wrote:
>>
>> In the first case:
>>
>> function foo(callable $bar): int { return $bar(); }
>>
>> I think the value of $bar would have to fall into a set of values
>> known to the programmer, or at lea
On Fri, 5 Apr 2019 at 12:42, Robert Hickman wrote:
> In the first case:
>
> function foo(callable $bar): int { return $bar(); }
>
> I think the value of $bar would have to fall into a set of values
> known to the programmer, or at least known at some level.
I think you're misunderstanding the
In the first case:
function foo(callable $bar): int { return $bar(); }
I think the value of $bar would have to fall into a set of values
known to the programmer, or at least known at some level. The only way
I can currently think of where this would be truly unknown is if it
comes from unfiltered
On Fri, 5 Apr 2019 at 11:30, Robert Hickman wrote:
> If a static
> analyser were programmable, it could parse the SQL query and query the
> database to find out what keys exist in some_table. Thus it could
> check for references to non-existing keys.
>
That's an interesting example, but I don't
>
> The tricky part is that PHP is a highly dynamic language, so there's a lot
> of cases where the analysis can only return "maybe". My understanding is
> that this is what a lot of the work on Hack is doing: creating a language
> which looks a lot like PHP, but doesn't have as many ambiguous case
On Fri, 5 Apr 2019 at 09:57, Robert Hickman wrote:
> >
> > For instance:
> >
> > function foo(): type nothrow {
> > throw new SomethingException;
> > }
>
> Would it be possible to analyse the call graph at compile time
> (bytecode generation) and then trigger a fatal error? It wouldn't be
> p
If we didn't provide support for string keys, we can add it back later.
If we provide this feature, and later we passed named argument with a different
way to handle string keys, then it will be a huge inconsistent and difficult to
fix.
Thanks,
CHU Zhaowei
-Original Message-
From: Micha
The [original argument unpacking
RFC](https://wiki.php.net/rfc/argument_unpacking?rev=1389442371) does allow
positional arguments after unpacking, but later it's changed due to some
implement issue, see
https://github.com/php/php-src/commit/d3b484df8268f7ab31c4ac39734d4b68ce2e6159
I didn't see
pt., 5 kwi 2019 o 10:50 Rowan Collins napisał(a):
>
> The original draft discussed this, but there wasn't agreement on how
> identical keys should be handled, e.g.:
>
> $a = ['foo' => 1, ...['foo' => 2]]
>
> Should $['foo'] be 1 or 2? Cases were made for both, and it was pointed out
> that if we
On Fri, 5 Apr 2019, 09:26 Benjamin Coutu, wrote:
> Hello,
>
> I was surprised to find out that equality checks on zend_string do not
> take advantage of the fact that in many cases we have a hash key available
> that can be utilized in a quick bailout path without having to resort to a
> costly `
>
> For instance:
>
> function foo(): type nothrow {
> throw new SomethingException;
> }
Would it be possible to analyse the call graph at compile time
(bytecode generation) and then trigger a fatal error? It wouldn't be
possible for variable functions/methods though. A separate static
analyse
On Fri, 5 Apr 2019 at 09:31, Michał Brzuchalski
wrote:
> The next paragraph in MDN document is spread operator for object literals
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_object_literals
> Now JavaScript objects can be used like our ar
Hi Larry,
pt., 5 kwi 2019 o 03:55 Larry Garfield napisał(a):
>
> Advantages:
>
> * Very compact.
> * Works for both arrays and traversables
> * Would play very nicely with the proposed spread operator for iterables (
> https://wiki.php.net/rfc/spread_operator_for_array).
>
IMO not nicely cause
pt., 5 kwi 2019 o 08:56 CHU Zhaowei napisał(a):
> Here is a MDN document for spread operator in JS:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#Spread_in_array_literals
> and hope you find more useful examples.
>
The next paragraph in MDN document
> Le 5 avr. 2019 à 09:45, Stijn Peeters a écrit :
>
> Hi,
>
> If I understand correctly it is possible in this proposal to use normal
> arguments after using an unpackable argument:
>
> $arr4 = array(...$arr1, ...$arr2, 111); //valid
>
> This is something that is not possible when usi
Hi,
If I understand correctly it is possible in this proposal to use normal
arguments after using an unpackable argument:
$arr4 = array(...$arr1, ...$arr2, 111); //valid
This is something that is not possible when using argument unpacking in
function calls:
$result = someFunct
On Thu, Apr 4, 2019 at 6:44 PM Derick Rethans wrote:
> Hey,
>
> We have banned this "spam2" user from internals, but he's still being an
> ass on the bug system. Should I have a look at whether we can get him
> out of there as well?
>
Yes, please. The only reason he is not banned on bugs.php.net
On Fri, Apr 5, 2019 at 9:26 AM Benjamin Coutu wrote:
> Hello,
>
> I was surprised to find out that equality checks on zend_string do not
> take advantage of the fact that in many cases we have a hash key available
> that can be utilized in a quick bailout path without having to resort to a
> cost
Please do, it’s been long overdue
tor. 4. apr. 2019 kl. 12.44 skrev Derick Rethans :
> Hey,
>
> We have banned this "spam2" user from internals, but he's still being an
> ass on the bug system. Should I have a look at whether we can get him
> out of there as well?
>
> cheers,
> Derick
>
> --
> ht
Hello,
I was surprised to find out that equality checks on zend_string do not take
advantage of the fact that in many cases we have a hash key available that can
be utilized in a quick bailout path without having to resort to a costly
`memcmp` on the value.
I recommend to modify `zend_string_e
32 matches
Mail list logo
