Re: [PHP-DEV] New RFC : empty() function
On 30/10/2023 12:24, Alessandro Rosa wrote:
I have posted a new RFC at this link
https://wiki.php.net/rfc/empty_function where I suggested some
improvements to the standard built-in empty() function and provided a
number of examples.
Hi, and welcome!
First, regarding the clarity of the proposal.
You have a few pieces of sample code in the RFC, but the "expected
value" comments don't actually match what that code would output. Rather
than inline comments on each line, I suggest you give the current output
of the whole code, followed by the expected / desired output. I would
also suggest replacing "" with "\n", to keep the code smaller.
Similarly, your PHP-implemented version of the function is trying to be
far too clever. If you want to illustrate what you think the rules
should be, you need a clear, well-commented function implementing those
rules. The first if statement, for instance, is just a very confusing
way to write "if ( $input === null ) { return true; }"
Neither style of example really explains why you think your proposed
rules make sense. *Why* should boolean true be considered empty? In what
situation would you call the function with no arguments and expect a
meaningful response?
Second, regarding timescales.
As documented at https://wiki.php.net/rfc/releaseprocess the official
policy of the project is that backwards compatibility can only be broken
in a major version - that is, the next chance to break compatibility is
in 9.0, not 8.anything. While there are often grey areas around this
rule, there is absolutely no question that empty() could be removed any
time before that. If anything, proposing removal in 10.0 might be more
reasonable.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
I would be voting against any function that checks for "empty". The `empty()` construct we have now should almost never be used in any reasonable code. It should be avoided at all cost. For this reason, I see no need to introduce a new variant of the same thing. I also don't believe there is any need to fix or change the existing construct. Leave it as it is for use in legacy projects. Maybe in a distant future we will be able to deprecate it or maybe we won't. While I personally consider it a menace, I don't mind it existing in the language. But please do not add any similar functionality. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
Hi there, it's a legacy function, and I don't think we can afford or
we should consider this bc break. Though I don't use this function
myself and also prefer other methods of input validation, still there
are a lot of people that use it. Renaming this to is_empty will bring
a bc break. However, the improvements to this function are worth
considering.
Ahmad
On 10/30/23, Alessandro Rosa wrote:
> Thanks everybody for joining this discussion.
> I appreciated a lot the points you raised, as they are helping me to
> update and improve my rfc,
> whose meaning, as I hope, would look clearer than the earlier version.
>
> Improvements must be achieved, whatever they would cost.
> Ambiguities shall be resolved. I think this is the first principle in
> computer science: 0 or 1 ! :-D
> In any case, they are not assumed to be resort into cut-off transitions:
> they may be achieved within 3, 4 or 5 versions.
> Don't be scared.
> I have implemented my version in my own library and it works like a charm:
> you'll have exactly what you read.
>
> Alessandro Rosa
>
> Il giorno lun 30 ott 2023 alle ore 16:59 tag Knife ha
> scritto:
>
>> >
>> > This is exactly where the problem lies. Is a string with just
>> > whitespace
>> > empty? Why would an ArrayObject with count 0 not be considered to be
>> empty
>> > while an array with count 0 is? "empty" is subjective and therefore not
>> > a
>> > reliable function to use. Especially in legacy code I find that people
>> use
>> > `empty` where they should've been using `count() === 0` and have
>> > resulted
>> > in bugs that weren't discovered until months or years later. The
>> variations
>> > of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null`
>> already
>> > check all the scenarios you need, without risking funky bugs due to how
>> the
>> > internal check for "falsy" values works.
>> >
>>
>> trust me, Ive worked on some terrible code bases that do
>> exactly that and have variables redefined or dynamically assigned
>> and you have to really check if it has been assigned a value or
>> not and what value.
>>
>> It might be forgotten by everyone because of how far PHP has come
>> but there is still extensive use of the @ suppressor and the
>> alternative to empty would be
>>
>> if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
>>
>>
>> empty() is 1 of 3 functions i believe that does not throw an undefined
>> variable warning if you don't @ suppress the variable you are passing in.
>>
>> So if you want to get rid of empty, can we reignite the talks to finally
>> get rid of @
>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
Thanks everybody for joining this discussion.
I appreciated a lot the points you raised, as they are helping me to
update and improve my rfc,
whose meaning, as I hope, would look clearer than the earlier version.
Improvements must be achieved, whatever they would cost.
Ambiguities shall be resolved. I think this is the first principle in
computer science: 0 or 1 ! :-D
In any case, they are not assumed to be resort into cut-off transitions:
they may be achieved within 3, 4 or 5 versions.
Don't be scared.
I have implemented my version in my own library and it works like a charm:
you'll have exactly what you read.
Alessandro Rosa
Il giorno lun 30 ott 2023 alle ore 16:59 tag Knife ha
scritto:
> >
> > This is exactly where the problem lies. Is a string with just whitespace
> > empty? Why would an ArrayObject with count 0 not be considered to be
> empty
> > while an array with count 0 is? "empty" is subjective and therefore not a
> > reliable function to use. Especially in legacy code I find that people
> use
> > `empty` where they should've been using `count() === 0` and have resulted
> > in bugs that weren't discovered until months or years later. The
> variations
> > of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null`
> already
> > check all the scenarios you need, without risking funky bugs due to how
> the
> > internal check for "falsy" values works.
> >
>
> trust me, Ive worked on some terrible code bases that do
> exactly that and have variables redefined or dynamically assigned
> and you have to really check if it has been assigned a value or
> not and what value.
>
> It might be forgotten by everyone because of how far PHP has come
> but there is still extensive use of the @ suppressor and the
> alternative to empty would be
>
> if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
>
>
> empty() is 1 of 3 functions i believe that does not throw an undefined
> variable warning if you don't @ suppress the variable you are passing in.
>
> So if you want to get rid of empty, can we reignite the talks to finally
> get rid of @
>
Re: [PHP-DEV] New RFC : empty() function
>
> This is exactly where the problem lies. Is a string with just whitespace
> empty? Why would an ArrayObject with count 0 not be considered to be empty
> while an array with count 0 is? "empty" is subjective and therefore not a
> reliable function to use. Especially in legacy code I find that people use
> `empty` where they should've been using `count() === 0` and have resulted
> in bugs that weren't discovered until months or years later. The variations
> of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already
> check all the scenarios you need, without risking funky bugs due to how the
> internal check for "falsy" values works.
>
trust me, Ive worked on some terrible code bases that do
exactly that and have variables redefined or dynamically assigned
and you have to really check if it has been assigned a value or
not and what value.
It might be forgotten by everyone because of how far PHP has come
but there is still extensive use of the @ suppressor and the
alternative to empty would be
if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
empty() is 1 of 3 functions i believe that does not throw an undefined
variable warning if you don't @ suppress the variable you are passing in.
So if you want to get rid of empty, can we reignite the talks to finally
get rid of @
Re: [PHP-DEV] Discussion - Anti-null coercion
On Mon, Oct 30, 2023, at 11:17 AM, Ilija Tovilo wrote: > Hi Robert > > On Sun, Oct 29, 2023 at 7:31 PM Robert Landers > wrote: >> >> Hello Internals, >> >> We currently have a null coercion operator: ??, but we lack an >> anti-null coercion operator. >> ... >> fn() => >> ($_SERVER['HTTP_X_MY_HEADER'] ?? null) >> ? md5($_SERVER['HTTP_X_MY_HEADER']) >> : null; >> ... >> This is rather tedious when you have to do it, so, I'd like to discuss >> adding a new "anti-null coercion" operator: ?! >> >> This would collapse the previous verbose code into: >> >> fn() => >> $_SERVER['HTTP_X_MY_HEADER'] >> ?! md5($_SERVER['HTTP_X_MY_HEADER']; > > This does not seem significantly less verbose to me. The main > motivation for ?? was that it avoids repeating the expression over > something like ?:. I would see a stronger argument for this feature if > it offered the same benefit. E.g. > > $_SERVER['HTTP_X_MY_HEADER'] ?! md5($$) > >> It would have a lower precedence than ?? so that the above line would >> read from left to right without requiring parenthesis/brackets. The >> operator would only return the right-hand side if the left-hand side >> exists (aka, not null), otherwise, it would return null. > > I think it should have a higher precedence. > > $_SERVER['HTTP_X_MY_HEADER'] ?! md5($$) ?? 'abc' > ==> > ($_SERVER['HTTP_X_MY_HEADER'] ?! md5($$)) ?? 'abc' > > Otherwise the result is NULL if the header is missing, given that the > coalesce operator is never executed. > > That said, while I've certainly encountered this situation, it's > nothing a temporary variable can't fix. I don't personally believe > there's a strong need for such an operator. > > Ilija Another point to note is that for objects, we already have ?->, which effectively serves this purpose. It is sugar for: is_null($o) ? null : $o->whatever() So any new operator would only be relevant for free-standing variables (which is automatically a code smell) or arrays, and I'm not convinced the latter is a large enough use case in a decently written code base. (You really should know what your data is, and the best way to do that is map it into a proper object, at which point ?-> comes into play.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
Thanks everybody for joining this discussion. I appreciated a lot the points you raised, as they are helping me to update and improve my rfc, whose meaning, as I hope, would look clearer than the earlier version. Alessandro Il giorno lun 30 ott 2023 alle ore 16:36 Lynn ha scritto: > On Mon, Oct 30, 2023 at 4:21 PM tag Knife wrote: > > > > > > > However, according to my example, the variable is defined and has its > > > value as 0 or false, and empty() returns true anyway. I confess that > > > I've had some problems like this, and we chose not to use empty(), as > > > sometimes 0 or false makes sense as a valid value. > > > > > > > That is exactly as the documentation explains it. > > empty is to check if a variable is not holding a usable value. > > 0, false, true are all valid values and show the variable is not > > empty. > > > > The purpose for empty is to check for undefined variables, empty > > arrays or empty strings. > > eg. "", [], null or undefined. > > > > This is exactly where the problem lies. Is a string with just whitespace > empty? Why would an ArrayObject with count 0 not be considered to be empty > while an array with count 0 is? "empty" is subjective and therefore not a > reliable function to use. Especially in legacy code I find that people use > `empty` where they should've been using `count() === 0` and have resulted > in bugs that weren't discovered until months or years later. The variations > of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already > check all the scenarios you need, without risking funky bugs due to how the > internal check for "falsy" values works. >
Re: [PHP-DEV] Basic Type Alias
On Sun, Oct 29, 2023, at 9:52 PM, Jorg Sowa wrote:
> I really like the idea and I would love to see it in PHP. I'm wondering
> however, what would be the scope of the feature and how complex would be
> designed type system. Examples I saw in this thread could be easily
> replaced with union and intersection types (i.e. numeric as int|float). In
> my opinion, there is a little benefit implementing in this shape making the
> PHP core more complex.
>
> The two use cases of user defined types in PHP which would benefit a lot
> IMO, would be:
> 1. Typed arrays similar to Typescript.
> 2. Semantic types which would increase the security of systems. Example:
> type UserId = int;
>
> function setUserId_1(int $userId){}
>
> function setUserId_2(UserId $userId){}
>
> setUserId_1(5); // OK
> setUserId_2(5); // TypeError
>
> setUserId_1(UserId(5)); // OK
> setUserId_2(UserId(5)); // OK
>
> Kind regards,
> Jorg
Simple unions are the easiest to talk about in quick examples, but the real
benefit of type aliases is in other cases, some of which they would enable.
Example:
I have a real parameter defined in my attributes library like this:
\ReflectionProperty|\ReflectionMethod|\ReflectionClassConstant $subject
And it appears several times, I believe. That would definitely be nicer if
simplified to an alias.
Example:
There's general consensus that callable types would be beneficial:
callable(RequestInterface, string): string or similar. But inline, that gets
long and complicated fast. Type aliases would allow simplifying that to
type callable(RequestInterface, string): string as PropertyRetriever
function foo(PropertyRetriever $c) { ... }
Example:
As in the above example, type aliases serve as documentation for callables or
complex types, explaining what that complex ruleset actually means,
semantically.
Example:
If generics or typed arrays ever happen, they'd probably be useful here, too.
Note that using type aliases in a required-fashion is a different matter, and
potentially not feasible. Free standing variables are untyped, which means
setUserId(UserId $id) could not require a UserId, because there's no way to
define a variable as being a UserId, not an int. While I can definitely see a
value in that kind of restriction, in practice I don't think PHP is capable of
it without vastly larger changes.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Issue with php.net
Hi, The issue has opened here. https://github.com/php/web-php/issues/820 Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
On Mon, Oct 30, 2023 at 4:21 PM tag Knife wrote: > > > > However, according to my example, the variable is defined and has its > > value as 0 or false, and empty() returns true anyway. I confess that > > I've had some problems like this, and we chose not to use empty(), as > > sometimes 0 or false makes sense as a valid value. > > > > That is exactly as the documentation explains it. > empty is to check if a variable is not holding a usable value. > 0, false, true are all valid values and show the variable is not > empty. > > The purpose for empty is to check for undefined variables, empty > arrays or empty strings. > eg. "", [], null or undefined. > This is exactly where the problem lies. Is a string with just whitespace empty? Why would an ArrayObject with count 0 not be considered to be empty while an array with count 0 is? "empty" is subjective and therefore not a reliable function to use. Especially in legacy code I find that people use `empty` where they should've been using `count() === 0` and have resulted in bugs that weren't discovered until months or years later. The variations of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already check all the scenarios you need, without risking funky bugs due to how the internal check for "falsy" values works.
[PHP-DEV] Issue with php.net
Hi, sorry, I don't know where to send this. But When visiting https://www.php.net/ I get a certificate error: The provided certificate is for www.caruso.ovh. When visiting http://www.php.net (http only), I get redirected to http://www.caruso.ovh/ Regards Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
> > However, according to my example, the variable is defined and has its > value as 0 or false, and empty() returns true anyway. I confess that > I've had some problems like this, and we chose not to use empty(), as > sometimes 0 or false makes sense as a valid value. > That is exactly as the documentation explains it. empty is to check if a variable is not holding a usable value. 0, false, true are all valid values and show the variable is not empty. The purpose for empty is to check for undefined variables, empty arrays or empty strings. eg. "", [], null or undefined.
Re: [PHP-DEV] New RFC : empty() function
On Mon, Oct 30, 2023 at 1:24 PM Alessandro Rosa wrote: > Hi, > > I have posted a new RFC at this link > https://wiki.php.net/rfc/empty_function > where I suggested some improvements to the standard built-in empty() > function and provided a number of examples. > > Thanks, > > Alessandro Rosa > WEB : http://alessandrorosa.altervista.org > LINKEDIN : https://www.linkedin.com/in/alessandro-rosa-9b7ba67b/ If anything I'd rather see `empty()` disappear, but I'll settle with a warning to be cautious when using it. We don't need a replacement as you should create your own function to validate what you consider "empty" or not based on the given context and variable type. For me `(bool) false or "(int) 0" isn't empty either, it's still a value of sorts.
Re: [PHP-DEV] New RFC : empty() function
Hello, I understand that the idea of the RFC is about some behaviors of empty(), e.g.: ```php $var = ''; var_dump(empty($var)); // true $var= []; var_dump(empty($var)); // true $var= 0; var_dump(empty($var)); // true var_dump(empty($empty)); // true $var= true; var_dump(empty($var)); // false, $varis defined and has value $str = false; var_dump(empty($var)); // true, $varis defined and has value ``` According to the manual: “determine whether a variable is empty”. However, according to my example, the variable is defined and has its value as 0 or false, and empty() returns true anyway. I confess that I've had some problems like this, and we chose not to use empty(), as sometimes 0 or false makes sense as a valid value. Also, having is_empty() would be nice, but keeping it empty, otherwise there would be a huge break. Maybe think of a strict empty() mode? Even so, it would change behavior. Sorry if I didn't understand the discussion correctly.
Re: [PHP-DEV] New RFC : empty() function
On 30.10.2023 13:24, Alessandro Rosa wrote: Hi, I have posted a new RFC at this link https://wiki.php.net/rfc/empty_function where I suggested some improvements to the standard built-in empty() function and provided a number of examples. Forget about deprecating empty(). No chance I'd vote for that. The RFC is not clear either. -- Aleksander Machniak Kolab Groupware Developer[https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
Hi, I don't understand what you are proposing and what problem you are trying to fix. The RFC is not explaining things well.
Re: [PHP-DEV] Re: Basic Type Alias
File-based are the worst. Let the types be attached to namespaces. As we have autoloaders, everyone is free to load them however they want (PSR-4, file, custom autoloader, whatever). Best regards, Erick Em seg., 30 de out. de 2023 às 08:34, G. P. B. escreveu: > On Sun, 29 Oct 2023 at 20:36, Robert Landers > wrote: > > > My personal opinion is that file-based type aliases would be the best. > > It solves an immediate problem while introducing a problem most people > > will never have (needing to reuse the type aliases elsewhere). It > > allows them to be used in functions and classes, while also making > > code more readable but not opaque outside the file. For example, if > > there is a type called BigNumber that was an alias of > > GMP|int|float|string, outside the file, knowing the actual types in my > > IDE is more useful than "BigNumber" and doesn't require me to dig into > > the definition or even agree with the other file's definition of > > "BigNumber." I just need to know that I need to pass it one of those > > types from my own code. However, reading that file's code, I don't > > need to know the intimate details of the aliases to make it more > > readable. > > > > If we find ourselves constantly writing the same type aliases in a > > bunch of files, we only need to wait less than a year to implement > > "global" (as in, available once include'ed) in the very next version > > of PHP. > > > > No, this is actually ridiculous. File based type alias are dumb and I will > vote against this. > My main motivation to work on function autoloading in the first place was > to create a mechanism so that adding a new type autoloader is very easy. > As I already find the semantics of one interface per file dumb, let's not > make it even more ridiculous of having a single line in a file, especially > as a library/project will likely want to declare more than one type. > > An IDE should very much have no struggle to resolve what the type alias > actually resolves too, they already do this with classes and interfaces. > And needing to declare every alias in every single file of a project is a > ludicrous idea. > > Best, > > Gina/George P. Banyard >
[PHP-DEV] New RFC : empty() function
Hi, I have posted a new RFC at this link https://wiki.php.net/rfc/empty_function where I suggested some improvements to the standard built-in empty() function and provided a number of examples. Thanks, Alessandro Rosa WEB : http://alessandrorosa.altervista.org LINKEDIN : https://www.linkedin.com/in/alessandro-rosa-9b7ba67b/
Re: [PHP-DEV] Re: Basic Type Alias
On Sun, 29 Oct 2023 at 20:36, Robert Landers wrote: > My personal opinion is that file-based type aliases would be the best. > It solves an immediate problem while introducing a problem most people > will never have (needing to reuse the type aliases elsewhere). It > allows them to be used in functions and classes, while also making > code more readable but not opaque outside the file. For example, if > there is a type called BigNumber that was an alias of > GMP|int|float|string, outside the file, knowing the actual types in my > IDE is more useful than "BigNumber" and doesn't require me to dig into > the definition or even agree with the other file's definition of > "BigNumber." I just need to know that I need to pass it one of those > types from my own code. However, reading that file's code, I don't > need to know the intimate details of the aliases to make it more > readable. > > If we find ourselves constantly writing the same type aliases in a > bunch of files, we only need to wait less than a year to implement > "global" (as in, available once include'ed) in the very next version > of PHP. > No, this is actually ridiculous. File based type alias are dumb and I will vote against this. My main motivation to work on function autoloading in the first place was to create a mechanism so that adding a new type autoloader is very easy. As I already find the semantics of one interface per file dumb, let's not make it even more ridiculous of having a single line in a file, especially as a library/project will likely want to declare more than one type. An IDE should very much have no struggle to resolve what the type alias actually resolves too, they already do this with classes and interfaces. And needing to declare every alias in every single file of a project is a ludicrous idea. Best, Gina/George P. Banyard
Re: [PHP-DEV] Discussion - Anti-null coercion
Hi Robert On Sun, Oct 29, 2023 at 7:31 PM Robert Landers wrote: > > Hello Internals, > > We currently have a null coercion operator: ??, but we lack an > anti-null coercion operator. > ... > fn() => > ($_SERVER['HTTP_X_MY_HEADER'] ?? null) > ? md5($_SERVER['HTTP_X_MY_HEADER']) > : null; > ... > This is rather tedious when you have to do it, so, I'd like to discuss > adding a new "anti-null coercion" operator: ?! > > This would collapse the previous verbose code into: > > fn() => > $_SERVER['HTTP_X_MY_HEADER'] > ?! md5($_SERVER['HTTP_X_MY_HEADER']; This does not seem significantly less verbose to me. The main motivation for ?? was that it avoids repeating the expression over something like ?:. I would see a stronger argument for this feature if it offered the same benefit. E.g. $_SERVER['HTTP_X_MY_HEADER'] ?! md5($$) > It would have a lower precedence than ?? so that the above line would > read from left to right without requiring parenthesis/brackets. The > operator would only return the right-hand side if the left-hand side > exists (aka, not null), otherwise, it would return null. I think it should have a higher precedence. $_SERVER['HTTP_X_MY_HEADER'] ?! md5($$) ?? 'abc' ==> ($_SERVER['HTTP_X_MY_HEADER'] ?! md5($$)) ?? 'abc' Otherwise the result is NULL if the header is missing, given that the coalesce operator is never executed. That said, while I've certainly encountered this situation, it's nothing a temporary variable can't fix. I don't personally believe there's a strong need for such an operator. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
