Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 automatically encased a single variable into an array, where an array was expected. > In fact, I am able to easily hack around the limitation: > > $result = someFunction(...$arr1, ...$arr2, ...[111]); // valid > > but the limitation seems just an unnecessary annoyance. Typing a couple of extra characters, to avoid needing extra magic behaviour, seems a good trade-off to me. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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 ideology; an infinite debate of nonsense with fanatics.
second;;; you can properly handling it without a preprocessor as people
trying hard to name it by going thru abusing
statements about static analysis; it's all about handling an exception
process properly; but it will require to break
compatibility as I mentioned previously.
Best.
On Fri, Apr 5, 2019 at 10:03 AM Benjamin Morel
wrote:
> >
> > 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 code, it will skip runtime checks that it can prove
> > will never fail (e.g. return type annotation on a function that always
> > returns literals).
>
>
>
> > The tricky part is that PHP is a highly dynamic language (...)
>
>
> Features like scalar type hints, return types, property type hints, and
> preloading (which makes the definition of a type-hinted class available at
> compile time), should definitely help towards skipping a lot of runtime
> checks!
>
>
> On Fri, 5 Apr 2019 at 11:37, Rowan Collins
> wrote:
>
> > 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
> > > possible for variable functions/methods though. A separate static
> > > analyser could do the same thing.
> > >
> >
> >
> > 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 code, it will skip runtime checks that it can prove
> > will never fail (e.g. return type annotation on a function that always
> > returns literals).
> >
> > 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 cases
> which
> > can't be analysed statically.
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
>
[PHP-DEV] [RFC][Vote] Abolish Short Votes
Afternoon internals, Abolish Short Votes is now in voting: https://wiki.php.net/rfc/abolish-short-votes Cheers Joe
Re: [PHP-DEV] [RFC] Provide argon2 support for password_hash() from ext/sodium
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!
Re: [PHP-DEV] [RFC] Provide argon2 support for password_hash() from ext/sodium
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 backports. On Fri, Apr 5, 2019 at 7:52 PM 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 Changes" section. > > https://wiki.php.net/rfc/sodium.argon.hash > > -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Provide argon2 support for password_hash() from ext/sodium
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 Changes" section. > > https://wiki.php.net/rfc/sodium.argon.hash > > -Sara > I'm all for it however isn't a 2/3 majority required for all RFCs now? Best regards George P. Banyard
[PHP-DEV] [RFC] Provide argon2 support for password_hash() from ext/sodium
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 -Sara
Re: [PHP-DEV] Question about adding !function_identifier
>
> 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 code, it will skip runtime checks that it can prove
> will never fail (e.g. return type annotation on a function that always
> returns literals).
> The tricky part is that PHP is a highly dynamic language (...)
Features like scalar type hints, return types, property type hints, and
preloading (which makes the definition of a type-hinted class available at
compile time), should definitely help towards skipping a lot of runtime
checks!
On Fri, 5 Apr 2019 at 11:37, Rowan Collins wrote:
> 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
> > possible for variable functions/methods though. A separate static
> > analyser could do the same thing.
> >
>
>
> 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 code, it will skip runtime checks that it can prove
> will never fail (e.g. return type annotation on a function that always
> returns literals).
>
> 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 cases which
> can't be analysed statically.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
Re: [PHP-DEV] RFC Draft: Comprehensions
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 it.
> > Using approach 2 means I suddenly really really need to care which kind of
> > iterable it is, which defeats the purpose of `iterable`. Calling methods
> > on arrays, though, I'm pretty sure is out of scope.
> >
> > Frankly were it not for that limitation I'd say I favor the chained method
> > style, as while it is more verbose it is also more self-documenting. Given
> > that limitation, I'm torn but would probably lean toward option 1. And of
> > course there's the "methods that apply to all traversable objects" thing
> > which is its own can of worms I know nothing about.
> >
> > (If someone has a suggestion for how to resolve that disadvantage, I'd love
> > to hear it.)
> >
> > Those seem like the potential options. Any further thoughts? Or
> > volunteers? :-)
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> (Sorry, sent from wrong address, sending again!)
>
> Hi Larry,
>
> I’ve mostly ignored this thread until now - I find a lot of the
> “shorter syntax” (i.e. the short closures RFC) to sound a lot like the
> arguments “I don’t like semicolons/it has to be ‘pretty'” that happen
> in other language communities.
In defense of terse syntax, it's not a question of "pretty". It's a question
of making it feasible to operate at a higher level of abstraction. Really,
generators didn't offer much of anything that couldn't be done by defining and
building an Iterator-implementing class. They're "just" syntactic sugar.
However, they allow the developer to conceptualize a problem in a different
way, and most of the machinery then falls away. That means I can now think in
terms of "call this function, then iterate the stream it gives me back" and
within the function I can just have normal logic with `yield` floating around
as needed. Anything I do there *could* be done with an Iterator class; I've
done it some weird things with Iterators before. But the ability to think in
terms of an ad-hoc stream of values really changes the way you think about the
problem, and in a very good way.
Similarly, short closures isn't about "let's make functions easier to write".
That's a side effect. They should be thought of more as a way to easily
encapsulate "apply this expression to this set of values". So the advantage is
not that
$y= 5;
array_map(fn($x) => $x*$y, $arr);
is less typing than
array_map(function ($x) use ($y) {
return $x * $y;
});
It's that in the first option you don't think about it as a function, you think
about it as an expression applied over a set. That's a higher-order mental
operation, and once you start doing that you can conceptualize the program in a
different, more higher-order, less bug-prone way.
Just like there's nothing you can do with foreach() that you can't also do with
for()... but foreach() lets you think in terms of "just do it to everything"
rather than think in terms of the machinery of iteration.
I see comprehensions the same way. At one level they're "just" short syntax
for generators, but they're more about making it possible to reason about your
logic at a higher level, in a more declarative fashion.
(There's probably a conference talk in there somewhere, from for to foreach to
iterators to generators to comprehensions, each coming up one level of
abstraction.)
> But the first example you give here, I can see the logical approach -
> as you say, it’s a currently-valid foreach statement, wrapped in square
> brackets. Would it have to be a single line to parse, or could it be
> wrapped when the condition gets longer (yes I know it could just become
> a regular generator then, I’m just wondering about what happens when
> someone adds a new line in there (in a language that historically
> doesn’t care about newlines)
The RFC specifically says whitespace is irrelevant. If you want to break a
comprehension across multiple lines, you do you. But if it's getting large
enough that it's ugly to read that way it's a good sign you may want to take a
different approach. (A defined function with real foreach statements, multiple
defined comprehensions that reference each other, etc.)
> I like the second concept a lot too, but how would this cope with for
> example: a userland class implements iterator but *also* defines a
> `filter(callback $fn): self` method for the exact same purposes were
> discussing. How is that handled?
I have no idea at the moment. :-) That would be a possible BC issue. My first
thought is that if an iterator defines filter(), map(), etc. itself then it's
overriding the defa
Re: [PHP-DEV] Question about adding !function_identifier
> > 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 useful if PHP had a means to access that data, but in reality > this is still currently an area for developing 'a single code base' > within the IDE level rather than PHP itself? > I already do this to a small extent with my code using Psalm, and intend to explore it more deeply in the future. I was just making the point that having this ability is useful, in case the PHP project were to develop a 'core' static analysis system. Specifying this information directly in the code, vs specifying it at the level of an API is, in my opinion, just an application of separation of concerns. Having an API for it allows type checking to be applied to existing dynamic code bases which make use of dynamic functionality in a statically knowable way, which cannot be expressed within the type system. And yes, I do believe that having a result set be a simple associative array is perfectly fine. I defer why to the lecture 'simple made easy', available on youtube and else ware. . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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 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 useful if PHP had a means to access that data, but in reality this is still currently an area for developing 'a single code base' within the IDE level rather than PHP itself? The question in my mind is if there is still a place for results sets returned by a database query to simply be associative array elements or whether this is now too old fashioned and each should be an object which handle the validation functions relating to it and encapsulated in an object managing the various aspects of the query results such as errors returned and the like. In place of returning 'false' when something failed? Somewhere to hang failed returns rather than simply throwing the error in the hope that something else will deal with it? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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 the static analyser was programmable, it would be possible to > provide it such information, within the scope of a single code base. > I'm not really sure what you're suggesting; the normal way to "program" a static analyzer is to add more and richer type annotations to your code, as in the over-the-top example I gave (in reality, the analyser can deduce some of the types, and the syntax needn't be quite that ugly). The problem is that PHP has a lot of features where there is currently no way to specify types (callbacks, iterators, etc), and some where it's essentially impossible to do so in a checkable way ($$foo, $foo->$bar, etc). I'm not saying it's not possible, it's just a considerable project to rewrite a dynamic language into a statically typed one, and at the moment Hack is much further into that project than PHP, partly because it has less concern about backwards compatibility. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
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 least known at some level.
>
>
>
> 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 was programmable, it would be possible to
provide it such information, within the scope of a single code base.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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 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.
To be confident the code was type safe, it would have to look like this:
function foo(callable): int { return $bar(); }
...and every call to it would have to be analysable back to a function
explicitly declared as returning int.
The same applies to exception checking: you'd need syntax for "accept any
callable that never throws", or "any callable that only throws descendants
of FooException or BarException".
Then you end up with this kind of fun:
function curryish(callable<(int, float): int throws
FooException|BarException> $callback): callable<(float): int throws
FooException|BarException> {
return fn($x) => $callback(42, $x);
}
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
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 user data, which would be a security issue, due
to allowing arbitrary function calls.
Wordpress does something like this in it's shortcode and
'action/filter' system, The set of valid function calls in that case
would be mostly defined by all calls to 'add_action' and 'do_action'
(and related functions for shortcodes) in the core and installed
plug-ins. It may be unknown in some cases if that is controlled by
user input. As above I doubt that is truly unknown as allowing
untrusted input would be a security issue.
In the second case the iterable has to come from somewhere, so it's
content would be defined by whatever that 'somewhere' is.
Getting back to the original topic, how would 'throws' interact with
exceptions raised by the php interpreter itself?
On Fri, 5 Apr 2019 at 12:12, Rowan Collins wrote:
>
> 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 think it generalises as far as
> you think: what would a "programmable analyser" do with an array of HTTP
> headers, or query-string parameters?
>
> However, I wasn't referring to dynamic *data* like this, but rather dynamic
> behaviour in the language itself. A couple of simple examples:
>
> function foo(callable $bar): int { return $bar(); }
> function foo(iterable $bar): int { foreach ( $bar as $baz ) { return $baz;
> } }
>
> In order to analyse those, you need a) the language to offer a richer type
> system (generics, derived types, etc); and b) the programmer to make full
> use of that type system, everywhere.
>
> As soon as you have code that's missing rich type information, or use a
> truly dynamic feature, that whole section of code becomes essentially
> unchecked. That's why Hack is not only adding features for richer
> (statically analysed) type annotations, but also *removing* PHP features
> which don't work nicely with them.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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 think it generalises as far as
you think: what would a "programmable analyser" do with an array of HTTP
headers, or query-string parameters?
However, I wasn't referring to dynamic *data* like this, but rather dynamic
behaviour in the language itself. A couple of simple examples:
function foo(callable $bar): int { return $bar(); }
function foo(iterable $bar): int { foreach ( $bar as $baz ) { return $baz;
} }
In order to analyse those, you need a) the language to offer a richer type
system (generics, derived types, etc); and b) the programmer to make full
use of that type system, everywhere.
As soon as you have code that's missing rich type information, or use a
truly dynamic feature, that whole section of code becomes essentially
unchecked. That's why Hack is not only adding features for richer
(statically analysed) type annotations, but also *removing* PHP features
which don't work nicely with them.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] Question about adding !function_identifier
> > 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 cases which > can't be analysed statically. > Quite a lot of code that apparently cannot be statically analysed could be if the static analyser was programmable. To give a simple example: $result = mysqli_query ($conn, 'select * from some_table'); $arr = mysqli_fetch_assoc ($result); The contents of '$arr' cannot be known using only the data provided in this code, however it's contents is statically knowable. 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. I suspect this is the case for a lot of 'non analysable code', it can only function within a known set of states, but the type system is unaware of those states. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about adding !function_identifier
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
> possible for variable functions/methods though. A separate static
> analyser could do the same thing.
>
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 code, it will skip runtime checks that it can prove
will never fail (e.g. return type annotation on a function that always
returns literals).
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 cases which
can't be analysed statically.
Regards,
--
Rowan Collins
[IMSoP]
RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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ł Brzuchalski Sent: Friday, April 5, 2019 5:01 PM To: Rowan Collins Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2 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 get named arguments, the argument spread > operator will need to work the same way as whatever is decided for arrays. > > So the current approach is to get integer keys working first, using > the same behaviour as for parameters, and then revisit string keys later. > So we're talking about providing incomplete feature now, right? I would opt to the same behaviour as ['foo' => 1] + ['foo' => 2] // where 'foo' key results in 1 But maybe this should be optional voting for that, either way, we're delivering feature which has very limited usage which can be confusing, cause I can array_merge or use + operator so why can't I use keys with spread operator if I already have them in my generator, iterable or array which came from for eg. json_decode or whatever. -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 the same limit exists for arrays, so I didn't include this rule in my RFC. Thanks, CHU Zhaowei -Original Message- From: Claude Pache Sent: Friday, April 5, 2019 4:04 PM To: Stijn Peeters Cc: CHU Zhaowei ; PHP internals Subject: Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2 > 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 using argument unpacking in > function calls: > > $result = someFunction(...$arr1, ...$arr2, 111); //invalid > > While I personally like the more permissive variety in this RFC, I think this > could be a confusing inconsistency, and for clarity's sake it would be better > to keep both instances of the unpacking syntax as consistent with each other > as possible. > > Best, > Stijn > > That begs the question: why is this invalid for function calls? In fact, I am able to easily hack around the limitation: $result = someFunction(...$arr1, ...$arr2, ...[111]); // valid but the limitation seems just an unnecessary annoyance. —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 get named arguments, the argument spread operator will need to > work the same way as whatever is decided for arrays. > > So the current approach is to get integer keys working first, using the > same behaviour as for parameters, and then revisit string keys later. > So we're talking about providing incomplete feature now, right? I would opt to the same behaviour as ['foo' => 1] + ['foo' => 2] // where 'foo' key results in 1 But maybe this should be optional voting for that, either way, we're delivering feature which has very limited usage which can be confusing, cause I can array_merge or use + operator so why can't I use keys with spread operator if I already have them in my generator, iterable or array which came from for eg. json_decode or whatever. -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com
Re: [PHP-DEV] Optimize zend_string equality check with hash key
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 `memcmp` on the value.
>
> I recommend to modify `zend_string_equal_content` like so:
>
> static zend_always_inline zend_bool zend_string_equal_content(zend_string
> *s1, zend_string *s2)
> {
> if (ZSTR_LEN(s1) != ZSTR_LEN(s2)) {
> return 0;
> }
>
> if (ZSTR_H(s1) && ZSTR_H(s1) != ZSTR_H(s2)) {
> return 0;
> }
>
> return zend_string_equal_val(s1, s2);
> }
>
> Thoughts?
>
> --
>
> Benjamin Coutu
> ben.co...@zeyos.com
>
Best idea would be to do a PR on the GitHub repo.
Best regards
George Peter Banyard
Re: [PHP-DEV] Question about adding !function_identifier
>
> 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
analyser could do the same thing.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 array with keys and I simply > don't understand why we cannot preserve keys, like in JS object literals > 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 get named arguments, the argument spread operator will need to work the same way as whatever is decided for arrays. So the current approach is to get integer keys working first, using the same behaviour as for parameters, and then revisit string keys later. Regards, -- Rowan Collins [IMSoP]
Re: [PHP-DEV] RFC Draft: Comprehensions
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 spread operator in current proposal raises an error on key preserved traversable[1]. This means example like below would fail $a = ['foo' => true, ...[foreach($_GET as $key => $value) yield $key => $value]]; // error [1] https://wiki.php.net/rfc/spread_operator_for_array#string_keys -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 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 array with keys and I simply
don't understand why we cannot preserve keys, like in JS object literals
Sample code:
JavaScript: var a = {foo: true, ...{bar: "baz"}}; // become {foo: true,
bar: "baz"}
and you can access it via a.foo or as an array dimension a['foo'] - more or
less like PHP arrays, right with key as a dimenrsion in array
Your RFC covers:
PHP: $a = [1, 2, 3, ...[4, 5, 6]]; // resulting [1, 2, 3, 4, 5, 6]
What would happen in:
a) PHP: $a = ['foo' => true, ...[4, 5, 6]]; // ??
b) PHP $a = ['foo' => true, ...['bar' => 'baz']] // error ??
Don't get me wrong I just see spread operator in function arguments a
different feature which allows working with variadic parameters,
and we're talking about the different feature here which only use the same
operator, right?
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
> 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 using argument unpacking in > function calls: > > $result = someFunction(...$arr1, ...$arr2, 111); //invalid > > While I personally like the more permissive variety in this RFC, I think this > could be a confusing inconsistency, and for clarity's sake it would be better > to keep both instances of the unpacking syntax as consistent with each other > as possible. > > Best, > Stijn > > That begs the question: why is this invalid for function calls? In fact, I am able to easily hack around the limitation: $result = someFunction(...$arr1, ...$arr2, ...[111]); // valid but the limitation seems just an unnecessary annoyance. —Claude
Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2
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 = someFunction(...$arr1, ...$arr2, 111); //invalid While I personally like the more permissive variety in this RFC, I think this could be a confusing inconsistency, and for clarity's sake it would be better to keep both instances of the unpacking syntax as consistent with each other as possible. Best, Stijn Op 4 april 2019 bij 16:15:16, CHU Zhaowei (m...@jhdxr.com(mailto:m...@jhdxr.com)) schreef: > Hi internals, > > Thanks for the people who joined the discussion of my [RFC: Spread Operator > in Array Expression](https://wiki.php.net/rfc/spread_operator_for_array). The > biggest change is I have dropped the support for string keys in v0.2 as > suggested by Côme, to make the behavior of spread operator consistent. I have > also added Q&A to explain the questions I received. > > Thanks & best regards, > CHU Zhaowei > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-DEV] Bug #77845 [Com]: Error in the comparaison (fwd)
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 is that, as
far as I'm aware, we don't really have a good method to do that with the
bug tracker not requiring accounts.
Nikita
cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>
> -- Forwarded message --
> Date: Thu, 04 Apr 2019 14:37:14 +
> From: spam2 at rhsoft dot net
> To: php-b...@lists.php.net
> X-Bogosity: No, tests=bogofilter, spamicity=0.00, version=1.2.4
> Subject: Bug #77845 [Com]: Error in the comparaison
>
> Edit report at https://bugs.php.net/bug.php?id=77845&edit=1
>
> ID: 77845
> Comment by: spam2 at rhsoft dot net
> Reported by:baklouti dot med at gmail dot com
> Summary:Error in the comparaison
> Status: Not a bug
> Type: Bug
> Package:*Compile Issues
> Operating System: ubuntu 18.04
> PHP Version:7.2.16
> Block user comment: N
> Private report: N
>
> New Comment:
>
> hell post the code you are actually using instead f**g decriptions ike "
> am not using the two cases in the same time" - switch works, full stop,
> echo what $id contains really at that moment
>
>
> Previous Comments:
>
> [2019-04-04 14:34:18] baklouti dot med at gmail dot com
>
> Yes, I try it with "case 0:" , and the same issue is happening.
>
>
> [2019-04-04 11:21:37] ka...@php.net
>
> Because `($id === 0)` is evaluated as an expression before, meaning that
> essentially the `case` statement now looks like `case 1:`. The correct way
> to do that which you are trying to would be to make your case statement
> simply look like `case 0:`.
>
> Please refer to the documentation int the future:
> https://www.php.net/manual/en/control-structures.switch.php
>
>
> [2019-04-04 11:10:25] baklouti dot med at gmail dot com
>
> Description:
>
> I am testing the value of $id to do some processing. I retrieve the
> variable $id from an array ($test) and converted to integer, for the case
> that $id = 0 when using "switch" it can't be detected and if I used the
> "if" it is working fine.
> I tried with the "==" and the "===" and also not working with "switch".
> I am not using the two cases in the same time, i tested the "if" and
> "switch"
> separately.
>
> $id = (integer)$test['id'];
>
> if ($id === 0 ) {return 1;}
>
> switch ($id) {
> case ($id === 0):
> return 2;
>
>
>
>
> Expected result:
>
> The expected result is the bloc inside the case ($id ===0) is processed.
>
> Actual result:
> --
> The actual result that it is passed for another case.
>
>
>
>
>
>
> --
> Edit this bug report at https://bugs.php.net/bug.php?id=77845&edit=1
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
[PHP-DEV] Re: Optimize zend_string equality check with hash key
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
> costly `memcmp` on the value.
>
> I recommend to modify `zend_string_equal_content` like so:
>
> static zend_always_inline zend_bool zend_string_equal_content(zend_string
> *s1, zend_string *s2)
> {
> if (ZSTR_LEN(s1) != ZSTR_LEN(s2)) {
> return 0;
> }
>
> if (ZSTR_H(s1) && ZSTR_H(s1) != ZSTR_H(s2)) {
> return 0;
> }
>
> return zend_string_equal_val(s1, s2);
> }
>
> Thoughts?
>
We usually include the hash check explicitly in situations where it makes
sense, see in particular uses of zend_string_equal_content inside
zend_hash.c (such as
https://github.com/php/php-src/blob/ade73c360cbe9d533214e8b7cb26c514c29256fb/Zend/zend_hash.c#L614).
You'll note that these comparisons use the hash from the bucket rather than
the string, for better locality. Including a hash check in
zend_string_equal_content would result in a duplicate check there.
I think it might make sense to include a hash check inside
zend_string_equals() though, which is a higher-level function. From a quick
look, only one use of this function performs it's own hash check, which
could then be dropped.
Nikita
Re: [PHP-DEV] Bug #77845 [Com]: Error in the comparaison (fwd)
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
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>
> -- Forwarded message --
> Date: Thu, 04 Apr 2019 14:37:14 +
> From: spam2 at rhsoft dot net
> To: php-b...@lists.php.net
> X-Bogosity: No, tests=bogofilter, spamicity=0.00, version=1.2.4
> Subject: Bug #77845 [Com]: Error in the comparaison
>
> Edit report at https://bugs.php.net/bug.php?id=77845&edit=1
>
> ID: 77845
> Comment by: spam2 at rhsoft dot net
> Reported by:baklouti dot med at gmail dot com
> Summary:Error in the comparaison
> Status: Not a bug
> Type: Bug
> Package:*Compile Issues
> Operating System: ubuntu 18.04
> PHP Version:7.2.16
> Block user comment: N
> Private report: N
>
> New Comment:
>
> hell post the code you are actually using instead f**g decriptions ike "
> am not using the two cases in the same time" - switch works, full stop,
> echo what $id contains really at that moment
>
>
> Previous Comments:
>
> [2019-04-04 14:34:18] baklouti dot med at gmail dot com
>
> Yes, I try it with "case 0:" , and the same issue is happening.
>
>
> [2019-04-04 11:21:37] ka...@php.net
>
> Because `($id === 0)` is evaluated as an expression before, meaning that
> essentially the `case` statement now looks like `case 1:`. The correct way
> to do that which you are trying to would be to make your case statement
> simply look like `case 0:`.
>
> Please refer to the documentation int the future:
> https://www.php.net/manual/en/control-structures.switch.php
>
>
> [2019-04-04 11:10:25] baklouti dot med at gmail dot com
>
> Description:
>
> I am testing the value of $id to do some processing. I retrieve the
> variable $id from an array ($test) and converted to integer, for the case
> that $id = 0 when using "switch" it can't be detected and if I used the
> "if" it is working fine.
> I tried with the "==" and the "===" and also not working with "switch".
> I am not using the two cases in the same time, i tested the "if" and
> "switch"
> separately.
>
> $id = (integer)$test['id'];
>
> if ($id === 0 ) {return 1;}
>
> switch ($id) {
> case ($id === 0):
> return 2;
>
>
>
>
> Expected result:
>
> The expected result is the bloc inside the case ($id ===0) is processed.
>
> Actual result:
> --
> The actual result that it is passed for another case.
>
>
>
>
>
>
> --
> Edit this bug report at https://bugs.php.net/bug.php?id=77845&edit=1
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
regards,
Kalle Sommer Nielsen
ka...@php.net
[PHP-DEV] Optimize zend_string equality check with hash key
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_equal_content` like so:
static zend_always_inline zend_bool zend_string_equal_content(zend_string *s1,
zend_string *s2)
{
if (ZSTR_LEN(s1) != ZSTR_LEN(s2)) {
return 0;
}
if (ZSTR_H(s1) && ZSTR_H(s1) != ZSTR_H(s2)) {
return 0;
}
return zend_string_equal_val(s1, s2);
}
Thoughts?
--
Benjamin Coutu
ben.co...@zeyos.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
