Re: [PHP-DEV] Allow new Cl()->method()
In my opinion:
- the operator table docs should be updated to contain all operators (
see comment
https://www.php.net/manual/en/language.operators.precedence.php#121509 )
- "new" should have the highest absolute priority, ie. new
Cl()->method(); should be always interpreted as (new Cl())->method();,
new (Cl()->method()); is very unusual and parenthesis can be always used
to enforce the intended precedence.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
ČVUT FEL
On 3 Dec 2020 07:45, Michał Marcin Brzuchalski wrote:
Hi Michael,
śr., 2 gru 2020 o 21:03 Michael Voříšek - ČVUT FEL napisał(a):
Hi devs,
currently new Cl() must be wrapped in parentheses if that object is
further used to call it's method like (new Cl())->method().
It there any reason why not to allow new Cl()->method() ?
Based on https://www.php.net/manual/en/language.operators.precedence.php
- the "new" operator has already the highest precedence, thus there
should be no conflict.
I think that's because removing the parentheses may confuse what was the original intention of author.
class CI {
public function method() { echo 'foo'; }
}
class bar {
public function __construct() {
echo 'bar';
}
}
function CI() {
return new class {
public function method() { return 'bar'; }
};
}
(new CI())->method(); // foo
new (CI()->method()); // bar
Both ways are valid code in PHP8 with no error/warning, till PHP7.4 there was a
Parse error: syntax error, unexpected '('
in the second object construction.
Cheers,
Michał Marcin Brzuchalski
[PHP-DEV] Allow new Cl()->method()
Hi devs, currently new Cl() must be wrapped in parentheses if that object is further used to call it's method like (new Cl())->method(). It there any reason why not to allow new Cl()->method() ? Based on https://www.php.net/manual/en/language.operators.precedence.php - the "new" operator has already the highest precedence, thus there should be no conflict. With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek ČVUT FEL
[PHP-DEV] DateTimeInterface interface stub has no modify method
Intentionally? It is an issue for static analysers... With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek ČVUT FEL
Re: [PHP-DEV] Nightly builds
Thanks - via api - externally - it should be possible - https://dev.azure.com/phpazuredevops/PHP/_apis/pipelines/1/runs?orderBy=date%20desc&top=1000&api-version=6.0-preview.1 The only thing we could produce are Docker images Yes, building nightly Docker image is the intended usecase and I may help with it. Is it ok to introduce "master-passing" branch in official repo, that will be updated at the very end by CI job triggered by push to "master" branch? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek ČVUT FEL On 30 Nov 2020 16:07, Nikita Popov wrote: On Sat, Nov 28, 2020 at 12:44 PM Michael Voříšek - ČVUT FEL wrote: Hi internals, currently, as far as I know, php does not have nightly builds. By nighly I means builds/releases that are tested to pass all CI tests. This is not the case with master branch, as that branch can be failing tests. I propose to introduce "nightly" branch that will point to "the latest master head that passed all CI tests". To limit cache misses on dependent projects/builds (like docker images), I propose to update "nightly" branch no more than once per day. This will allow php comunity reliable testing of new language/engine features much more sooned until next php minor version has an alpha release. What is your opinion on this and is here someone that can implement it? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek ČVUT FEL Hey Michael, It's not entirely clear to me what you're asking for here. Is it about producing actual build artifacts? It's not possible to produce useful build artifacts for PHP, because the number of dynamically linked libraries will make them non-portable. The only thing we could produce are Docker images -- and other people already provide that service. If what you want is to just determine whether a certain commit is a good base for a nightly build, I'd suggest finding our how to query scheduled builds on Azure pipelines (builds like these: https://dev.azure.com/phpazuredevops/PHP/_build/results?buildId=13228&view=results) and check whether they pass. Note though that these will commonly fail even on good commits, because they run tests in more than 60 different configurations, and as such spurious failures are common. Nikita
[PHP-DEV] Detect if function is disabled from c ext
How can a php function can be checked from extension if that function is
disabled or not?
In php7.x, I used:
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include "php.h"
bool is_php_function_disabled(const char *func_name) {
zend_internal_function *func;
if ((func = zend_hash_str_find_ptr(CG(function_table), func_name,
strlen(func_name {
if (func->handler == ZEND_FN(display_disabled_function)) {
return true;
}
}
return false;
}
But it does not work for php8:
In file included from /usr/local/include/php/main/php.h:35,
from .../ext/libs.c:6:
.../ext/libs.c: In function 'is_php_function_disabled':
/usr/local/include/php/Zend/zend_API.h:68:23: error:
'zif_display_disabled_function' undeclared (first use in this function)
68 | #define ZEND_FN(name) zif_##name
| ^~~~
.../ext/libs.c:237:30: note: in expansion of macro 'ZEND_FN'
237 | if (func->handler == ZEND_FN(display_disabled_function)) {
Thanks for help in advance.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
ČVUT FEL
[PHP-DEV] Nightly builds
Hi internals, currently, as far as I know, php does not have nightly builds. By nighly I means builds/releases that are tested to pass all CI tests. This is not the case with master branch, as that branch can be failing tests. I propose to introduce "nightly" branch that will point to "the latest master head that passed all CI tests". To limit cache misses on dependent projects/builds (like docker images), I propose to update "nightly" branch no more than once per day. This will allow php comunity reliable testing of new language/engine features much more sooned until next php minor version has an alpha release. What is your opinion on this and is here someone that can implement it? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek ČVUT FEL
Re: [PHP-DEV] [RFC] Draft - Closure self reference
Hi everyone,
maybe a bad idea, but what about addressing the "Principle of least
astonishment" issue by allowing to specify/capture the variable after
the function is assigned:
$f = function () use ($f) {...};
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 10 Nov 2020 18:08, Dan Ackroyd wrote:
Hello internals,
For reasons, I was reviewing the conversation where adding closures to
PHP was added, and it reminded me that currently the only way for a
closure to call itself is slightly terribly, so I drafted an RFC:
https://wiki.php.net/rfc/closure_self_reference
Before I spend time on it, is there any strong reason why this is a bad idea?
cheers
Dan
Ack
Re: [PHP-DEV] [RFC] Support for ::function syntax
Hi,
what about resolving directly to Closure?
strtoupper::function === \Closure::fromCallable('strtoupper').
$this->method::function === \Closure::fromCallable([$this, 'method']).
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 8 Nov 2020 00:41, a...@php.net wrote:
Hello internals,
Looking for feedback on the idea of supporting `::function` syntax (or
`::fn`) for consistency with existing `::class` syntax:
$arr = ['apple'];
print_r(array_map(strtoupper::function, $arr));
(Apologies if this has already been discussed. Hard to search for
colon-colon-function.)
Benefits in my view are readability and potential use in static analysis.
Downsides (as implemented in proof-of-concept) are that it can be
needlessly littered in a lot of places, and that it breaks class consts
named `function`. I'd vote against it in its current state, but if people
like the general idea maybe the drawbacks can be addressed with a better
implementation.
Examples:
https://gist.github.com/adsr/2c0b9243986418af3cecf8046657304b
Proof-of-concept:
https://github.com/adsr/php-src/commit/07bb24243022ccef5823f6977d231f3535a48a07.patch
Adam
Re: [PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does not throw
Significant additional code in the engine to perform additional checks and/or name aliasing I know, but we can do very easily one thing - check and throw if overriding method has one or more named parameter on different position. On class creation time, ie. only once, no overhead per call. Then calling with named/unnamed parameters is **consistent** (or resolves to an "Unknown named parameter" error) and... We are safe! With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 28 Oct 2020 17:43, Rowan Tommins wrote: On 28/10/2020 15:14, Michael Voříšek - ČVUT FEL wrote: I agree - "it's harder to imagine a scenario in real life where". [...] If we can agree, that implementation is not guaranteed to be called with named parameters only, what real world usecase to defend this current php behaviour is left? You're thinking about this the wrong way around: the simplest implementation is to detect non-existent named parameters (which happens to include renamed parameters) at run-time; it is additional checks on top of that which need to be justified. Other approaches to the problem require at least one of: * Significant additional code in the engine to perform additional checks and/or name aliasing * Users to change existing code which works correctly, but would theoretically break if used with named parameters The advantages are almost entirely theoretical, with few realistic examples. So the "pragmatic approach" the RFC refers to concludes that the benefit of additional analysis does not outweigh its cost. Regards, -- Rowan Tommins (né Collins) [IMSoP]
Re: [PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does not throw
see https://3v4l.org/X8omS
As long as non-named parameters are supported (they always will be),
calling different implementation can produce different results when
called with named/not-named parametrs.
Let say we have interface/class X with method test(int $offset, int
$limit).
Let's extend it by test(int $limit, int $offset).
When it is called with unnamed arguments, both implementations return
the same result and satisfy the interface. But, if the purpose of the
rename is to allow to swap the parameters, what is the advantage if it
does not work with unnamed arguments?
For better names, I propose to allow rename "to never used name", thus
position is never changed and everything behave consistently across
named/unnamed params. I also propose to accept the old names, as
currently, if not used with the new names, the parameter names are not
resolved, so OOP/LSP is violated.
So my personal summary is, this behaviour is nonsense and should be not
allowed as there is no practical benefit of it.
To your example:
public function foo($str, $needle){
is something I do not propose to forbid, only the names have to be new
or match the original position in iface/parent class
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 28 Oct 2020 17:39, Chase Peeler wrote:
On Wed, Oct 28, 2020 at 11:15 AM Michael Voříšek - ČVUT FEL wrote:
I agree - "it's harder to imagine a scenario in real life where".
From php perspective, swapping parameters in inheritance SHOULD NOT be
allowed, as without named parameters the parameters are not swapped.
Also, if the parameters are typed differently, the example is even
impossible (and nowdays, typed parameters are very common, thus
"commonly impossible").
What do you mean they "aren't swapped?"
class A {
public function foo ($str1,$str2){
return strcompare($str1,$str2);
}
}
class B extends A{
public function foo($str2,$str1){
return strcompare($str2,$str);
//or
//return parent::foo($str1,$str2);
}
}
They are swapped in the above example because the code inside B::foo handles the swapping. And, maybe there is a valid reason that the developer wanted to emphasize $str2 over $str1 in the subclass.
If we can agree, that implementation is not guaranteed to be called with
named parameters only, what real world usecase to defend this current
php behaviour is left?
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Considering that parameter swapping prior to unnamed parameters has always been supported, what unique issue does it represent that requires we solve it now? Anything done to prevent it would almost certainly be a huge BC break. As for real world use-cases, I can think of a few:
1.) Developer the subclass wants to make certain parameters optional which weren't originally at the end of the parameter list
2.) Parent class broke common practices in terms of parameter order ($needle, $haystack vs $haystack, $needle) and they want their subclass to follow the more commonly used pattern.
3.) The developer of the subclass just wants them in a different order for some reason that makes sense to them. Maybe they don't need to support polymorphism. Maybe the idea is that the subclass will be used INSTEAD of the parent class and any knowledge of the parent class by other programmers isn't even necessary.
Michael Voříšek
On 28 Oct 2020 15:57, Rowan Tommins wrote:
On 28/10/2020 10:45, Michael Voříšek - ČVUT FEL wrote:
https://3v4l.org/X8omS parameters renamed, result with named parameters
is different
While it's easy to construct an example where this happens, it's harder to
imagine a scenario in real life where:
* a sub-class overloads the function with different parameter names...
* ...that overlap with the original parameter names... (i.e. the call will
succeed)
* ... but not in the same order...
* ...where calling with ordered parameters results in the expected behaviour
(i.e. it's not already incorrect code)
It seems more likely in practice that a polymorphic call assuming the
parameters are in the same order would fail where one assuming they have the
same names will succeed, e.g.:
class A {
public function search(string $needle, string $haystack) { ... }
}
class B extends A {
public function search(string $haystack, string $needle) { ... }
}
$aOrB->search("foo", "foobar"); // incorrect call on instances of B, but
allowed in every version of PHP
$aOrB->search(needle: "foo", haystack: "foobar"); // correct behaviour whether
instance of A or B :)
I agree that this scenario is very contrived. You are looking at a scenario where multiple examples of poor programming are layered on top of each other. Trying to prevent such scenarios risks going down a rabbit hole that removes a lot of freedom from the language.
Re: [PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does not throw
I agree - "it's harder to imagine a scenario in real life where".
From php perspective, swapping parameters in inheritance SHOULD NOT be
allowed, as without named parameters the parameters are not swapped.
Also, if the parameters are typed differently, the example is even
impossible (and nowdays, typed parameters are very common, thus
"commonly impossible").
If we can agree, that implementation is not guaranteed to be called with
named parameters only, what real world usecase to defend this current
php behaviour is left?
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 28 Oct 2020 15:57, Rowan Tommins wrote:
On 28/10/2020 10:45, Michael Voříšek - ČVUT FEL wrote:
https://3v4l.org/X8omS parameters renamed, result with named parameters
is different
While it's easy to construct an example where this happens, it's harder to
imagine a scenario in real life where:
* a sub-class overloads the function with different parameter names...
* ...that overlap with the original parameter names... (i.e. the call will
succeed)
* ... but not in the same order...
* ...where calling with ordered parameters results in the expected behaviour
(i.e. it's not already incorrect code)
It seems more likely in practice that a polymorphic call assuming the
parameters are in the same order would fail where one assuming they have the
same names will succeed, e.g.:
class A {
public function search(string $needle, string $haystack) { ... }
}
class B extends A {
public function search(string $haystack, string $needle) { ... }
}
$aOrB->search("foo", "foobar"); // incorrect call on instances of B, but
allowed in every version of PHP
$aOrB->search(needle: "foo", haystack: "foobar"); // correct behaviour whether
instance of A or B :)
https://3v4l.org/kgHWf renamed parameter, call with named parameters
does not succeed at all (which violated basic principe of OOP
inheritance at least)
This is the case that is explicitly discussed in the RFC:
https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance
I'm not sure what more can be said than appears in that summary, and in the
linked discussion of rejected alternatives. As the RFC says, the pragmatic
decision was taken to defer these errors to runtime.
It's worth noting that since PHP doesn't have checked exceptions, a child
method throwing an error that it's parent wouldn't is already possible and not
considered a violation: https://3v4l.org/3m7eo
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
Re: [PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does not throw
I see, guys, what is the single reason to allowing this dangerous inheritance? https://3v4l.org/X8omS parameters renamed, result with named parameters is different https://3v4l.org/kgHWf renamed parameter, call with named parameters does not succeed at all (which violated basic principe of OOP inheritance at least) With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 26 Oct 2020 15:36, Rowan Tommins wrote: On 26/10/2020 13:12, Michael Voříšek - ČVUT FEL wrote: I am writing regarding bug 80248. Currently, PHP 8 allows parameter reuse at different position, which I belive is very dangerous, as passed parameters may be passed in a different order with different object impl. Hi Michael, Yes, this was one of the most discussed aspects of named parameters. There were a few proposals for how it should work, but in the end none of them gained consensus, and Nikita decided to keep things simple. I suggest having a look at the RFC [https://wiki.php.net/rfc/named_params] and its main discussion thread [https://externals.io/message/110004] to see the pros and cons of various alternatives. Since none of these were adopted in the proposal, it's not clear that this could be considered a bug, rather than a feature change, so there'd need to be a very strong justification for re-visiting it this close to 8.0 availability. Regards, -- Rowan Tommins (né Collins) [IMSoP]
[PHP-DEV] Bug #80248 - Swapping parameter names during inheritance does not throw
Hi, I am writing regarding bug 80248. Currently, PHP 8 allows parameter reuse at different position, which I belive is very dangerous, as passed parameters may be passed in a different order with different object impl. See https://3v4l.org/X8omS , which is against OOP and LSP. I belive, we can allow parameter rename, but we should throw if "already seen parameter name is at a different position". I am not that good in C to fix this, so only reporting. I belive, we should fix this issue asap and merge into PHP 8. Also - for further discussion - I think, we can even allow parameter rename, but still allow to use the old name (which, with fix above, will always result to the same param position). Example: https://3v4l.org/kgHWf (now an error, it violates OOP/LSP again) With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek
Re: [PHP-DEV] List of attributes
Wdyt about dedicating "#" char for attributes? We can deprecate comments with "#" in 8.0 or 8.1 and in later version support attributes with "#" single character - without [] brackets, ie. support: #Attribute1 #Attribte2 public function x()... which will be equivalent to: #[ #Attribute1 #Attribte2 ] public function x()... Is there anything against excl. BC break of "#" comments? Who is for it? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 23 Oct 2020 17:52, Theodore Brown wrote: On Tue, Oct 20, 2020 at 10:13 AM Rowan Tommins wrote: On Mon, 19 Oct 2020 at 16:17, Theodore Brown wrote: In theory nested attributes could be supported in the same way with the `#[]` syntax, but it's more verbose and I think less intuitive (e.g. people may try to use the grouped syntax in this context, but it wouldn't work). Also the combination of brackets delineating both arrays and attributes reduces readability: #[Assert\All([ #[Assert\Email], #[Assert\NotBlank], #[Assert\Length(max: 100)] ])] I think you're presupposing how a feature would work that hasn't even been specced out yet. On the face of it, it would seem logical and achievable for the above to be equivalent to this: #[Assert\All( #[ Assert\Email, Assert\NotBlank, Assert\Length(max: 100) ] )] i.e. for a list of grouped attributes in nested context to be equivalent to an array of nested attributes. Hi Rowan, The problem with this is that it results in inconsistent semantics, where the number of items in an attribute group results in a different type of value being passed. I.e. if you remove two of the three attributes from the list, suddenly the code will break since the `Assert\All` attribute is no longer being passed an array. // error when Assert\All is instantiated since it's no longer being // passed an array of attributes: #[Assert\All( #[ Assert\Email, ] )] So when removing nested attributes from a list such that there's only one left in the list, you'd have to remember to additionally wrap the attribute group in array brackets: #[Assert\All( [#[ Assert\Email, ]] )] And of course when you want to add additional attributes to a group that originally had only one attribute, you'd have to remember to remove the extra array brackets. Generally speaking, having the number of items in a list change the type of the list is a recipe for confusion and unexpected errors. So I think the only sane approach is to ban using the grouped syntax in combination with nested attributes. Unfortunately, no one thought through these issues when proposing to change the shorter attribute syntax away from @@ and add the grouped syntax, and now it seems like we're stuck with a syntax that is unnecessarily complex and confusing to use for nested attributes. Unless nested attributes were limited to being direct arguments to another attribute, the *semantics* of nested attributes inside arrays would have to be defined anyway (e.g. how they would look in reflection, whether they would be recursively instantiated by newInstance(), etc). Yes, the exact semantics of nested attributes need to be defined, but this is a completely separate topic from the grouped syntax issue described above. As a user I would expect nested attributes to be reflected the same as any other attribute (i.e. as a `ReflectionAttribute` instance). Calling `getArguments` on a parent attribute would return an array with `ReflectionAttribute` objects for any nested attribute passed as a direct argument or array value. On first thought I think it makes sense to recursively instantiate nested attributes when calling `newInstance` on a parent attribute. This would allow attribute class constructors to specify the type for each attribute argument. But again, this is a separate discussion from the issue of nested attribute syntax. Kind regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Support for multi-line arrow functions
Yes, "use (*)" is perfect!
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 5 Oct 2020 11:57, Andreas Leathley wrote:
On 04.10.20 22:08, Rowan Tommins wrote:
If we added an opt-in syntax for "capture everything", we might
instead write this:
$f = function() use (*) {
$x = $y = $z = null;
}
Without re-initialising all local variables, we would no longer be
able to know if they were actually local without looking at the
surrounding scope for a value that might be captured. I am unconvinced
by this trade-off of opt-out instead of opt-in.
One use case I've seen proposed is closures which capture a large
number of variables; I would be interested to see an example where
this is the case and is not a "code smell" in the same way as
requiring a large number of parameters.
Something like "use (*)" seems like a great enhancement to me. I often
use a wrapper function for SQL transactions, something like:
```php
public function update(int $numberId, int $addressId, bool $isMainNumber
= false): void
{
$this->transaction->run(function () use ($numberId, $addressId,
$isMainNumber): void {
// Do all SQL queries for the update
});
}
```
In these cases there is a lot of redundancy because of having to import
the variables, and if a variable is added, it has to be added in two
places in a slightly different way. The following would be much nicer:
```php
public function update(int $numberId, int $addressId, bool $isMainNumber
= false): void
{
$this->transaction->run(function () use (*): void {
// Do all SQL queries for the update
});
}
```
This would also increase code readability.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: CallbackFilterIterator is leaking memory
Hi, if the dual_it is hard to fix, can we fix the memory isssues using WeakRef like here https://github.com/atk4/data/pull/737/files#diff-cc2c8bc61e741e6f1b07d0076c5036c0R51 inside php directly? Why are internal objects not correctly linked and GCable at all? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek ČVUT FEL On 23 Sep 2020 11:28, Michael Voříšek - ČVUT FEL wrote: Hi, can someone please verify https://bugs.php.net/bug.php?id=80125 and fix if possible? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek ČVUT FEL
[PHP-DEV] CallbackFilterIterator is leaking memory
Hi, can someone please verify https://bugs.php.net/bug.php?id=80125 and fix if possible? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek ČVUT FEL
Re: [PHP-DEV] __isset() and null value
Yes, this is purely to offer native/php support for it.
When implementing custom ORM etc., we do not have any control over the
class, ie. extra method for checking property existance is not possible.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek, student
On 4 Sep 2020 20:14, David Rodrigues wrote:
Maybe you just can implements your own method to check? Like your exists()
example.
Em sex, 4 de set de 2020 15:08, Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> escreveu:
Your examples provide code for checking the existance of real
properties. But how to check existance of a magic one?
The best is currently __isset(), but to comply with isset() definition,
it should not return true when the magic property has null value, thus I
belive, there is currently not way (provided by php language) to check
for existance of magic property.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 4 Sep 2020 19:23, Marco Pivetta wrote:
Heya,
On Fri, Sep 4, 2020 at 7:03 PM Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote:
isset() returns false for null
__isset() should return the same, but then if magic property with null
value exists, there is no way to detect it
Example: https://3v4l.org/GqUsh
this is currently an limitation of php
Ideally, we should introduce __exist() which should return true even if
value is null and for BC autoimplement __isset() based on it and __get,
ie.
function __isset($n) { return $this->__exist($n) && $this->__isset($n)
!== null; }
I'd endorse **NOT** checking for property existence on objects that
don't have a clearly defined interface/type: that's something for a
static
analyzer, not (usually) for runtime code.
If you still need to do that (anti-patterns such as stuffing things in
`stdClass` instances), checking if a property is defined is trivial
with
reflection:
```php
ReflectionClass(SomethingMagicAndTerriblyUgly::class))->hasProperty('foo'));
var_dump((new
ReflectionClass(SomethingMagicAndTerriblyUgly::class))->hasProperty('bar'));
var_dump((new
ReflectionClass(SomethingMagicAndTerriblyUgly::class))->hasProperty('baz'));
```
https://3v4l.org/pVC4j
Checking if a **public** property exists at runtime is done via
`array_key_exists()`, not via `isset()`:
```php
SomethingMagicAndTerriblyUgly)));
var_dump(array_key_exists('bar', (array) (new
SomethingMagicAndTerriblyUgly)));
```
https://3v4l.org/ZLSjq
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Re: [PHP-DEV] __isset() and null value
Your examples provide code for checking the existance of real
properties. But how to check existance of a magic one?
The best is currently __isset(), but to comply with isset() definition,
it should not return true when the magic property has null value, thus I
belive, there is currently not way (provided by php language) to check
for existance of magic property.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 4 Sep 2020 19:23, Marco Pivetta wrote:
Heya,
On Fri, Sep 4, 2020 at 7:03 PM Michael Voříšek - ČVUT FEL wrote:
isset() returns false for null
__isset() should return the same, but then if magic property with null
value exists, there is no way to detect it
Example: https://3v4l.org/GqUsh
this is currently an limitation of php
Ideally, we should introduce __exist() which should return true even if
value is null and for BC autoimplement __isset() based on it and __get,
ie.
function __isset($n) { return $this->__exist($n) && $this->__isset($n)
!== null; }
I'd endorse **NOT** checking for property existence on objects that don't have a clearly defined interface/type: that's something for a static analyzer, not (usually) for runtime code.
If you still need to do that (anti-patterns such as stuffing things in `stdClass` instances), checking if a property is defined is trivial with reflection:
```php
class SomethingMagicAndTerriblyUgly
{
public $foo = null;
private $bar = null;
}
var_dump((new
ReflectionClass(SomethingMagicAndTerriblyUgly::class))->hasProperty('foo'));
var_dump((new
ReflectionClass(SomethingMagicAndTerriblyUgly::class))->hasProperty('bar'));
var_dump((new ReflectionClass(SomethingMagicAndTerriblyUgly::class))->hasProperty('baz'));
```
https://3v4l.org/pVC4j
Checking if a **public** property exists at runtime is done via `array_key_exists()`, not via `isset()`:
```php
class SomethingMagicAndTerriblyUgly
{
public $foo = null;
private $bar = null;
}
var_dump(array_key_exists('foo', (array) (new SomethingMagicAndTerriblyUgly)));
var_dump(array_key_exists('bar', (array) (new SomethingMagicAndTerriblyUgly)));
```
https://3v4l.org/ZLSjq
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
[PHP-DEV] __isset() and null value
isset() returns false for null
__isset() should return the same, but then if magic property with null
value exists, there is no way to detect it
Example: https://3v4l.org/GqUsh
this is currently an limitation of php
Ideally, we should introduce __exist() which should return true even if
value is null and for BC autoimplement __isset() based on it and __get,
ie.
function __isset($n) { return $this->__exist($n) && $this->__isset($n)
!== null; }
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
Re: [PHP-DEV] Pass source object to clone like __clone($origThis)
The goal is to be able to access the original object and it's id/hash.
Usecases:
- something is associated with the object using the object id/hash and
it needs to be cloned as well
we need the original object to obtain it's id/hash for spl_object_id and
spl_object_hash methods
- bounded Closures ar associated with the original object and they needs
to be rebound to the cloned object
example:
public function __clone(self $origThis)
{
if ((new \ReflectionFunction($this->fx))->getClosureThis() ===
$origThis) {
$this->fx = \Closure::bind($this->fx, $this);
}
}
Modification of php is simple:
https://github.com/php/php-src/pull/6063/files#diff-beea8c5a8ceb318220b34b73e4ecfc98R252
we simply pass the old object as 1 parameter. I belive, passing old
object have positives and no performance nor compatibility impact. All
other current solutions require an extra property and a lot of code, as
assigning in constructor is not enough (due serialization etc.), or it
is even impossible, if object was created using reflection without
constructor.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 3 Sep 2020 18:00, Sara Golemon wrote:
On Thu, Sep 3, 2020 at 10:40 AM David Rodrigues
wrote:
Now I rethinked about what I said. Really, maybe clone is not the best
option. So maybe we can just use a method that will clone and will have
access to both informations. But I don't know if it solves the original
message.
public function getUserCopy() {
$userCopy = clone $this;
$this->copies[] = $userCopy;
return $userCopy;
}
If your goal is to track copies, then a static makes much more sense.
class AllKnowing {
private static $copies = [];
public function __construct(...) {
self::$copies[] = $this;
}
public function __clone() {
self::$copies[] = $this;
}
}
-Sara
[PHP-DEV] Pass source object to clone like __clone($origThis)
Hi, please look at https://stackoverflow.com/questions/63675888/get-original-source-instance-in-clone do you have anything against updating PHP to pass "instance before cloned" to any __clone call from php? no BC - user may accept this extra argument or declare function __clone() without any param like now With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek
Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
I like "void", as "null" can be ambiguous.
Imagine function example($a = 'default value 1', $b = 'default value 2')
{}
With "void", we can allow skipping arguments in advance to the default
pamameter value like example(void, 'test');.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 2 Sep 2020 16:24, David Rodrigues wrote:
I think "void" is a good solution and is very clear, compared to "_".
[void, void, $username] = getUserData();
Atenciosamente,
David Rodrigues
Em qua., 2 de set. de 2020 às 10:57, Dik Takken
escreveu:
On 02-09-2020 15:35, Chase Peeler wrote: Isn't the underscore an alias for gettext()?
You are right, it is. Now this does not necessarily mean that underscore
cannot be used for ignored variables. Depending on the context in which
it is used an underscore may or may not be ambiguous.
Since we are talking about using underscore in places where a variable
name is expected, there may not be any problem at all. But we should be
aware of all cases in which ambiguous syntax could emerge and identify
any issues. So thanks a lot for pointing out this possible trouble maker!
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Request for couple memory optimized array improvements
I would highly prefer php optimalization for it. ArrayKeysIterator can
not even used if the input is iterable instead of pure array.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 31 Aug 2020 23:31, Max Semenik wrote:
On Mon, Aug 31, 2020 at 11:53 PM Michael Voříšek - ČVUT FEL wrote:
Optimizing foreach (array_keys($arr) as $k) is very important, not only
because of memory, but because of speed when not all elements needs to
be iterated, like:
foreach (array_keys($arr) as $k) {
if ($k some condition) {
break;
}
}
Can an iterator be the answer? E.g.
foreach (new ArrayKeysIterator($arr) as $k) { ... }
--
Best regards,
Max Semenik
Re: [PHP-DEV] Request for couple memory optimized array improvements
Optimizing foreach (array_keys($arr) as $k) is very important, not only
because of memory, but because of speed when not all elements needs to
be iterated, like:
foreach (array_keys($arr) as $k) {
if ($k some condition) {
break;
}
}
please, can someone send a PR for this?
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 31 Aug 2020 20:13, Riikka Kalliomäki wrote:
Hello,
For the past couple years I've been working with a PHP code base that
at times deals with quite large payloads memory wise. This has made me
pay more attention to some array operations in PHP that are rather
frustrating to deal with in userland PHP, but could perhaps be
optimized more in PHP core.
A common pattern that I've seen that could dearly use PHP internal
optimization, if possible, would be:
foreach (array_keys($array) as $key) {
}
The problem with this pattern, of course, is the fact that it
needlessly duplicates the array passed to foreach, as can be seen from
this example: https://3v4l.org/MRSv6
I would be ever so grateful, if it would be possible to improve the
PHP engine to detect that fully qualified function name array_keys is
used with foreach, in which case it would simply perform a foreach
over the keys of the array without creating a copy. Optimizing this
wouldn't even require any userland changes. Not sure if the PHP engine
makes it at all feasible, though.
Of course, you could just be using something like this in code:
foreach ($array as $key => $_) {
}
Which has actually become a pattern for us in some memory sensitive
places, but using array_keys inside foreach is a very intuitive and
common approach and doesn't require the unused variable, so it would
be nice to see the usage enshired.
Another similar problem with creating array copies is the detection of
"indexed" arrays (as opposed to associative arrays). Particularly when
dealing with JSON, it's a common need to detect if an array has keys
from 0 to n-1 and in that order. My understanding is that at least in
some cases this would be trivial and fast to tell internally in PHP,
but the functionality is not exposed to userland.
Current common practices include for example:
array_keys($array) === range(0, count($array) - 1)
Memory optimized way of dealing with this is via foreach, but it's
quite cumbersome and again, you must not use array_keys in the
foreach. The following example demonstrates that the worst case
scenario triples the memory usage using range: https://3v4l.org/FiWdk
Interestingly, using "array_values($array) === $array" is the fastest
and most optimized way in best case scenarios, since php just returns
the array itself in cases it's "packed" and "without holes". However,
this could get hairy in worst case scenarios since it starts comparing
the values as well.
So, it would be nice to have a core PHP function implementing this
test, because the userland way of doing it is unnecessarily
unoptimized. I don't know what the function should be called. In our
code base the function is called is_indexed_array, but PHP doesn't
really have a standard term for this, afaik.
I regret my lack of C skills so I can't really propose
implementations, but I would be truly appreciative if these
suggestions would gain some traction.
[PHP-DEV] Array map with reset function
The following code stopped working in PHP 8: https://3v4l.org/UlIE3 is it a bug or a feature? is posting issues like this to internals@lists.php.net email prefered over opening bug directly? or is there any special email for it? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek
Re: [PHP-DEV] Allow sleep() to accept non-integer values
Again, I personally don't understand why this could bypass the RFC process, as multiple people have already, me included, voiced their disagreement with this change. This was proposed by Nikita Popov in his comment Secondly this change introduces another inconsistency, why can sleep accept a float but not usleep? Nanosleep and microsleep functions are basically 1:1 of the underlaying implementation. The updated sleep() is however now never worse than the best sleep function available, thus we can use it also for time_nanosleep and usleep php function and accept float. I will implement it. If there is indeed a need for being able to specify a sleep in milliseconds I'd prefer the introduction of a msleep function then this change. The issue I solve is sleep function that accepts seconds should accept floating point values as time is continous value. With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 20 Aug 2020 14:25, G. P. B. wrote: Apologies for the double email, my client did something funcky. On Thu, 20 Aug 2020 at 14:22, G. P. B. wrote: On Thu, 20 Aug 2020 at 14:15, Michael Voříšek - ČVUT FEL wrote: Hi everyone, thank you for your comments, based on them, I fixed these: - usleep is now used as a fallback as well, if interrupted, remaining time is measured using microtime, so return value is always available - for BC, if not interrupted, return value remains to be 0 (integer zero) Now, the sleep() function should be really universal, cross platform and I would say also the prefered way to sleep. The implementaion is here https://github.com/php/php-src/pull/5961/files Please comment on Github directly if you have any feedback left. I thinkit's worth considering if this also should be fixed in 8.0 or even earlier ;-)So good to hear the RM view on this. Sara, are you ok to include this in PHP 8.0 and do you require a RFC for it? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek Again, I personally don't understand why this could bypass the RFC process, as multiple people have already, me included, voiced their disagreement with this change. Secondly this change introduces another inconsistency, why can sleep accept a float but not usleep? If there is indeed a need for being able to specify a sleep in milliseconds I'd prefer the introduction of a msleep function then this change. Best regards George P. Banyard
Re: [PHP-DEV] Allow sleep() to accept non-integer values
Hi everyone, thank you for your comments, based on them, I fixed these: - usleep is now used as a fallback as well, if interrupted, remaining time is measured using microtime, so return value is always available - for BC, if not interrupted, return value remains to be 0 (integer zero) Now, the sleep() function should be really universal, cross platform and I would say also the prefered way to sleep. The implementaion is here https://github.com/php/php-src/pull/5961/files Please comment on Github directly if you have any feedback left. I thinkit's worth considering if this also should be fixed in 8.0 or even earlier ;-)So good to hear the RM view on this. Sara, are you ok to include this in PHP 8.0 and do you require a RFC for it? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 11 Aug 2020 12:43, Björn Larsson wrote: Den 2020-08-11 kl. 10:53, skrev Rowan Tommins: On Tue, 11 Aug 2020 at 08:31, Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote: I am the author of https://github.com/php/php-src/pull/5961 , please provide feedback. This idea makes a lot of sense to me as a user (I'll leave comments on the implementation to those with more C experience). I'm pretty sure I've accidentally written things like "sleep(1.5)" in the past, and think there is a strong argument for changing something here: Another reason is that sleep(0.1); is silently accepted now (even with strict types enabled), but the input is casted to 0 and thus producing unexpected behaviour if the user is not aware of the current method prototype. Unless there are problems with the implementation, this seems like a straight-forward win. Regards, Given this unexpected behaviour, one could almost see it as a bug. I think it's worth considering if this also should be fixed in 8.0 or even earlier ;-) So good to hear the RM view on this. r//Björn L
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Please add discussion about merge conflicts. Any inline grouped
attribute syntax needs a manual conflict resolution.
With ungrouped syntax, I expect recommended CS to be one attribute per
line.
If this should be the case also for grouped syntax, then it not +1
character, but +2 new lines per every annotated element.
Also, is 2/3 majority required by RFC rules satisfied by the "Are you
okay with re-voting on the attribute syntax for PHP 8.0, again?"
question?
I think we should require 2/3 votes at least on the question if we
should allow grouping or not and if accepted, use STV results on the
prefered prefix symbols/syntax.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 19 Aug 2020 10:47, Benjamin Eberlei wrote:
On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei
wrote:
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
Hi,
Out of Banjamin's suggestion[1 [1]], I've updated the Shorter Attribute
Syntax Change RFC to reflect that process:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
Patches and comments welcome.
FWIW, this has an excemption from the RM Sara as per [2 [2]]:
* Shorter Attribute Syntax Change
- Joe/Derick - Please make sure this RFC moves along and reaches
conclusion by beta3, as discussed previously.
Heads up: This RFC is now going to vote tomorrow:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
I have updated the RFC one last time with as much of the feedback as
possible:
- a section about comparing to complexity of type definitions
- removal of the machine reading section as too narrow and ultimately
not
that important as downstream libraries just have to deal with any of it
- some more nuances in forward compatibility pro/cons section of #[]
- smaller corrections and improvements.
I don't think something major is missing now.
One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other
languages,
but without the BC Break.
cheers,
Derick
[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286
--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Links:
--
[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
possibility to keep @@ and add @{} as a second syntax for attributes
+1, but I would keep same prefix, ie. @@{} (or @@[]), for both syntaxes,
it is much easier for human eyes to search for one thing, also easier
for grep
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 17 Aug 2020 12:48, Andreas Leathley wrote:
As a possible addition/discussion point, I only noticed today that @{}
is a syntax that has not been mentioned yet, also not in any previous
discussions about attributes as far as I can tell. @{} currently leads
to a syntax error, so there is no BC break, and {} is common syntax for
grouping expressions in PHP, much more so than [], which is an
array-specific syntax.
Would it be a possibility to keep @@ and add @{} as a second syntax for
attributes, that can be used for grouping (for situations where that
makes sense) or other possibly future extensions? Then @@ would be a
good syntax for simple attribute definitions, and @{} could be an
alternative for people who want to group them or if any more complex
attribute features are added to the language later.
Because both sides of the "ending delimiter or no ending delimiter"
discussion do have some points in their favor, and it seems quite
individual what each person prefers. For a language it could be
beneficial to give some choices to the developer instead of foreseeing
each individual use case, and maybe attributes is such a feature.
I previously thought about suggesting both types of syntax (with and
without delimiters), but felt the current options all have too many side
effects to choose "two side effects" or two BC breaks. But the @@ BC
break seems the most harmless BC break of the bunch, and @{} does not
have a BC break, so these two option might be good together.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Concept] Don't cast keys in array to int
This seems almost as a bug, strict types should apply also for array key
which is currently not the case.
https://3v4l.org/epv5s
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 17 Aug 2020 02:56, Josh Bruce wrote:
I'm sure this conversation has happened before. But it's on my mind as I work
on some things on wanted to ask internals real quick before getting back to it.
["2" => "hello", "4" => "internals"] -> [2 => "hello", 4 => "internals"]
Meanwhile:
["hello", "internals"] -> cast to object -> ("0" => "hello", "2" => "internals")
Curious why this it's the case that specifically requesting a string be a key
that happens to be an integer, becomes an int type.
I kind of understand why in the case of object the implicit (PHP-established)
integers become strings.
And, of course, casting back puts us back to an indexed array. I've picked up
that type juggling might be a touchy point - but the focus is on why the key
gets cast at all when it's an array type.
Is it to facilitate the type juggle from an object to an array??
Cheers,
Josh
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Voting access
Hello, I registered on https://wiki.php.net/start?do=register To get authorization you must send a quick introduction to the internals mailing list. Mention your wiki username and say what you're planning to do. This email lets us know you're a human (and not a robot) and what you'll be working on. Please approve the registration, username mvorisek, I plan to submit an RFC for https://github.com/php/php-src/pull/5708 and get further involved in php internals. Thank you, With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 16 Aug 2020 23:13, Michael Voříšek - ČVUT FEL wrote: Hello, I am lead developer in Atk4 project, see https://github.com/mvorisek , but you are right, I need to be chosed by someoen with VCS account first. You do not have a VCS account, so you do not qualify for the firstpart,, the second part is existing people with VCS accounts choose youwhich has not happened here (you requested yourself). How can I register for VCS account to qualify for the first rule? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 16 Aug 2020 18:09, Kalle Sommer Nielsen wrote: Den søn. 16. aug. 2020 kl. 12.08 skrev Michael Voříšek - ČVUT FEL : Hello, based on https://wiki.php.net/rfc/voting voting access is offered to people who: - contributed to PHP source - I have made several smaller contributions to php-src incl. + some core xdebug optimization - lead developers of PHP based projects - I contributed to Symfony, Mink and some data php frameworks, about 500 PRs to PHP based projects totally in past year You missed parts of the text: ``` - People with php.net VCS accounts that have contributed code to PHP - Representatives from the PHP community, that will be chosen by those with php.net VCS accounts - Lead developers of PHP based projects (frameworks, cms, tools, etc.) - regular participant of internals discussions ``` You do not have a VCS account, so you do not qualify for the first part,, the second part is existing people with VCS accounts choose you which has not happened here (you requested yourself). Looking deeper at the second one, I do not see you mentioning you are a lead developer of either (the metric of your PRs is an irrelevant metric here according to the text), nor would I call you a regular internals participant (I found 6 posts total from you). Is this reasonable enought ti gain the voitng access and who should I contact? Based on the above, I do not see it being close to reasonable. If you wish to earn the privilege of voting, you should be more involved with the project as a whole.
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
I have one major issues with the examples.
Syntax Side by Side: The properties are annotated (with attributes)
inline which is the opposited of common usage now (with annotation).
Discussion on Grouping Pro/Cons: But since this depends on the coding
style the user... No, this should be consulted with PSR people and their
recommendations should be discussed there.
Enclosing Delimiters - Complexity of Attribute Declaration: there should
be example on left side without and on right side with - I do not see
how delimiters will actually help
Discussion on grep'ability - the arguments against are theoretical,
imports are not very often aliased, this is clearly a con for grouping
Excl. the <<>> syntax (which I think is not good because of generics
that will come sooner or later), all other examples are about good
prefix for attributes. So I think we should discuss the best prefix and
separately if we want to allow grouping with "[" or even with "{".
The most prefer syntax can be @: for ungrouped attributes and @:[] for
grouped one, but this combination is not discussed there.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 16 Aug 2020 11:36, Benjamin Eberlei wrote:
We have updated the RFC with all (hopefully) of the feedback from this
discussion:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
Most notable changes are:
- A new section with several subsections on the benefits of a closing
delimiter / enclosing syntax.
- A section on grouping pro/cons
- Inclusion of @: as per Theodores request
We are looking for further feedback from the community.
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
Hi,
Out of Banjamin's suggestion[1 [1]], I've updated the Shorter Attribute
Syntax Change RFC to reflect that process:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
Patches and comments welcome.
FWIW, this has an excemption from the RM Sara as per [2 [2]]:
* Shorter Attribute Syntax Change
- Joe/Derick - Please make sure this RFC moves along and reaches
conclusion by beta3, as discussed previously.
cheers,
Derick
[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286
--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Links:
--
[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286
[PHP-DEV] Voting access
Hello, based on https://wiki.php.net/rfc/voting voting access is offered to people who: - contributed to PHP source - I have made several smaller contributions to php-src incl. + some core xdebug optimization - lead developers of PHP based projects - I contributed to Symfony, Mink and some data php frameworks, about 500 PRs to PHP based projects totally in past year Is this reasonable enought ti gain the voitng access and who should I contact? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
I am for stopping the current voting too - because the results are very different vs. the previous voting, they are almost random and the discussion is still very hot which violates rule when voting can be started. My personal opinion on the attributes is: - allow not grouped syntax (with @@ or @:), because I think it is much better as code is 2 lines shorter or it is very badly mergeable with conflicts - comments should stay holy, ie. syntax with "#" is not a good choise, program should stay unchanged when ~/\*.*?\*/|(?://|#)[^\r\n]*~s is removed With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 15 Aug 2020 17:36, Peter Bowyer wrote: On Sat, 15 Aug 2020 at 16:07, tyson andre wrote: I also want a revote. I do too. Partly because of the rules, but mostly because this discussion has gone on so long I am now less clear about what is an "ending delimiter" and why it matters than before. And whether the begin/end delimiters are part of each attribute, or used once for all attributes. For example, https://wiki.php.net/rfc/shorter_attribute_syntax#lack_of_nested_attributes. Derek and Benjamin's RFC shows no nested examples. Are nested attributes even a thing now or did they disappear in an earlier RFC? If they are, they should be featured. On another topic, parentheses and ending delimiters. I have heard Derek's distinction, but if we're after a syntax with an ending delimiter then I would propose compulsory parentheses, which means all syntaxes @@, @:, you name it, would have one. If that's unacceptable for solving the "ending delimiter" issue, then document it in the RFC. It feels there is a lot bound up in the lexing, either by PHP or by how different people read and understand code. I'm stabbing in the dark for reasons because it's not been explicit - and it ought to be. This is not a comprehensive RFC, and while I'm ambivalent about syntax (having swung between <<>>, @@ and #[] over time) I do not appreciate feeling that it's being bounced through. Room 11 is not this list, and discussions that happen there (as earlier messages talk about) provide background and context that is missing when reading this RFC and not having been part of those discussions. P.S. the RFC introduction also states that *"The main concern is that @@ has no ending symbol and it's inconsistent with the language that it would be the only declaration or statement in the whole language that has no ending termination symbol."* I had mentioned this in (https://externals.io/message/111312#111335) that this statement failed to give concrete examples of problems (e.g. parsing ambiguities) that the authors believe could be caused in 8.0 or in future releases. I'd also stated that I think an attribute is neither a declaration nor a statement, but that could be resolved by including the definition of declaration/statement used by the authors. There are various syntaxes in PHP with no ending symbols (`clone`, `public`, `yield`). (I doubt changing this will make a difference since many people prefer `#[]`/`@[]` for other reasons, but still consider that sentence to be misleading.) Agreed. Peter
Re: [PHP-DEV] Allow sleep() to accept non-integer values
Another reason is that sleep(0.1); is silently accepted now (even with strict types enabled), That appears to not be true: https://3v4l.org/7YbqX corrected, should be "without strict types enabled" - https://3v4l.org/A2olN "even with strict type enabled" statement in BC section remains valid Having a function that behaves differently based on different platforms is a bad idea. I will implement fallback to usleep. I have not noticed any issues with usleep availability. Is there any known platform without nanosleep neither usleep support? With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek On 11 Aug 2020 12:39, Dan Ackroyd wrote: Michael Voříšek wrote: Another reason is that sleep(0.1); is silently accepted now (even with strict types enabled), That appears to not be true: https://3v4l.org/7YbqX Rowan wrote: Unless there are problems with the implementation, this seems like a straight-forward win. From the PR. Implemented using nanosleep which is not guaranteed to be available everywhere. Please just use usleep if you need more accuracy than seconds. Having a function that behaves differently based on different platforms is a bad idea. Changing a function to have surprising behaviour just to avoid using a different function, that is already available, is a really bad tradeoff. cheers Dan Ack
[PHP-DEV] Allow sleep() to accept non-integer values
Hi everyone, I am the author of https://github.com/php/php-src/pull/5961 , please provide feedback. All details should be in the description, also, please advise if we can consider it as a small change not requiring RFC as Nikita proposed in his comment. With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, Michael Voříšek
[PHP-DEV] Feature request - allow to append multiple elements to an array
Hi all PHP gurus!
This is a feature request / RFC for the following use-case:
$res = [];
foreach ($arr as $i) {
foreach (make_res($i) as $v) {
$res[] = $v;
}
}
Array_merge in loop is very sloop so it is not a solution.
which I propose to shorten to:
$res = [];
foreach ($arr as $i) {
$res[...] = make_res($i);
}
Appending multiple elements to an array is very common use-case.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
