[DOCS][Paradigms] Elaborate on Null, Set and Void

This commit is contained in:
Diogo Peralta Cordeiro 2021-07-29 13:38:12 +01:00 committed by Hugo Sales
parent c020958690
commit 2be4aeaab2
Signed by: someonewithpc
GPG Key ID: 7D0C7EAFC9D835A0
2 changed files with 33 additions and 3 deletions

View File

@ -1,4 +1,4 @@
# Architecture: Modules # Architecture
## Core ## Core

View File

@ -35,6 +35,7 @@ Things to note in the example above:
It's also common to have [functional code](https://en.wikipedia.org/wiki/Functional_programming) snippets It's also common to have [functional code](https://en.wikipedia.org/wiki/Functional_programming) snippets
in the middle of otherwise entirely imperative blocks (e.g., for handling list manipulation). in the middle of otherwise entirely imperative blocks (e.g., for handling list manipulation).
For this we often use the library [Functional PHP](https://github.com/lstrojny/functional-php/).
Use of [reflective programming](https://en.wikipedia.org/wiki/Reflective_programming#PHP), Use of [reflective programming](https://en.wikipedia.org/wiki/Reflective_programming#PHP),
[variable functions](https://www.php.net/manual/en/functions.variable-functions.php), and [variable functions](https://www.php.net/manual/en/functions.variable-functions.php), and
@ -46,8 +47,7 @@ Unless contributing to the core, you most likely _shouldn't_ use these.
PHP allows for a high level of code expression. In GNU social we have conventions for when each programming style PHP allows for a high level of code expression. In GNU social we have conventions for when each programming style
should be adopted as well as methods for handling some common operations. Such an example is string parsing: We never should be adopted as well as methods for handling some common operations. Such an example is string parsing: We never
chain various `substring` calls. We write a [regex](https://en.wikipedia.org/wiki/Regular_expression) pattern and then chain various `substring` calls. We write a [regex](https://en.wikipedia.org/wiki/Regular_expression) pattern and then
call `preg_match` instead. All of this consistency highly contributes for a more readable code and of easier call `preg_match` instead. All of this consistency highly contributes for a more readable and easier of maintaining code.
maintenance code.
Strings Strings
------------------------------------------------------------------------------- -------------------------------------------------------------------------------
@ -331,3 +331,33 @@ value.
A vast majority of programming errors come down to not checking your inputs A vast majority of programming errors come down to not checking your inputs
and outputs properly, so please try to do so as best and thoroughly as you can. and outputs properly, so please try to do so as best and thoroughly as you can.
NULL, VOID and SET
-------------------------------------------------------------------------------
On the discussion of whether to **use `=== null` vs [`is_null()`](https://www.php.net/manual/en/function.is-null.php)**,
the literature online is diverse and divided.
Some facts to consider:
* [null is both a data type, and a value](https://www.php.net/manual/en/language.types.null.php);
* As noted in PHP's documentation, the constant null forces a variable to be of type null;
* A variable with null value returns false in an [isset()](https://www.php.net/manual/en/function.isset.php) test,
despite that, assigning a variable to NULL is _not_ the same as [unsetting](https://www.php.net/manual/en/function.unset.php) it.
To actually test whether a variable is set or not [requires adopting different strategies per context](https://stackoverflow.com/a/18646568).
* The [void return type](https://wiki.php.net/rfc/void_return_type) doesn't return NULL, but if used as
an expression, it evaluates to null.
Therefore, in GNU social we would expect you to use one, or the other in function of context.
This is better illustrated with two example situations:
* If you're testing if a function returned null, then you're not testing a variable's data type, you're testing
whether it evaluated to null or not. So, as you normally would with a `=== true` or `=== false`, we prefer
that you test as `=== null` in this situation.
* If you're testing whether a variable is of type null, then you should use `is_null($var)`. Just as you normally
would with a `is_int($var)` or `is_countable($var)`.
About [nullable types](https://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.union.nullable),
we prefer that you _use_ the shorthand `?T` instead of the full form `T|null` as it suggests that you're considering the
possibility of not having the value of a certain variable. This is reinforced by the fact that NULL can not be a
standalone type in PHP.