Re: [PHP-DEV] Nullsafe

[Eugene Sidelnyk]

Thus, can you provide any other dangerous example?

On Wed, Nov 4, 2020, 6:59 AM Eugene Sidelnyk  wrote:

> But wait!
>
> In your example, funds won't get detracted. If `$accounts->get($receiver)`
> will return `null`, then everything inside `addFunds(...)` will not be
> executed.
> Your example (simplified): https://3v4l.org/38Dk3
>
> Another one:
> ```php
> function expensive_function() {
> var_dump(__FUNCTION__);
> }
>
> $foo = null;
>
> $foo?->baz(expensive_function());
> ```
>
> On Tue, Nov 3, 2020 at 10:11 PM Marco Pivetta  wrote:
>
>> Heya,
>>
>> On Tue, Nov 3, 2020, 17:38 Eugene Sidelnyk  wrote:
>>
>>> Hello, internals!
>>> I am wondering why don't we use ordinary `->` operator with safe null
>>> handling? Programmers will be more prone to return null values. And thus,
>>> in most of cases `?->` will replace `->`.
>>> Why do we need another operator, if we can implement null safe in current
>>> operator without BC breaks?
>>>
>>
>> Overall, "null safe" can be very dangerous if made the default.
>>
>> Here's a scenario where I'd never want "null safe" behaviour (which does
>> anything but introducing safety):
>>
>> ```php
>> $accounts->get($receiver)
>> ->addFunds(
>> $accounts->get($sender)
>> ->detractFunds($amount)
>> );
>> ```
>>
>> In the above scenario, if the first `$accounts->get()` call returns
>> `null` for any reason, you may actually destroy money (funds detracted, but
>> never added to another account).
>>
>> The example is simplistic, but it shows that "null safe" is everything
>> but "safe", and it must instead be used only where it absolutely makes
>> sense to suppress null reference errors.
>>
>> Similar behaviour can be observed around cast operators, which are too
>> lax for most businesses logic:
>> https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
>>
>> Safe = crashes when it should crash.
>>
>>>

Re: [PHP-DEV] Nullsafe

[Josh Bruce]

> Implicit nullable is terrible, moreover I don't see why users should return
> null values more often.
> They serve their purpose but most of the time you can use another sane/safe
> default of the given
> property type.
> 

Agreed. 

I’m not overly opinionated about much, but null as a default habit is one of 
them. I want the use of null and workarounds to feel ugly and dirty, because 
they are - imho. (The billion dollar mistake.)

Absolute last resort.

Also agreed on explicit communication of intent. If the operator flipped is 
want another operator to disallow null...at which point the world has not 
changed, just perceived default and desirable methods. 

Cheers,
Josh

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Nullsafe

[Christian Schneider]

Am 04.11.2020 um 19:39 schrieb Eugene Sidelnyk :
> Thus, can you provide any other dangerous example?

I think at this point you could have realised that it is
a) a BC break (code which has thrown an exception before now wouldn't)
b) not finding any love among the community here. Possibly for a reason?

If you really want you could put an RFC together but I'm pretty sure that it 
wouldn't be accepted.

And now for your dangerous example:
try {
$foo = null;
$foo->bar();
deletel_all_files_on_machine();
} catch (Error $dummy) {}


Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Nullsafe

[Eugene Sidelnyk]

Yeah... Creating null was a huge mistake.
Now it is probably too late to fix that (maybe some new language can
introduce that).

But what do you think about introducing special class `NullObject`?

On Wed, Nov 4, 2020, 9:32 PM Christian Schneider 
wrote:

> Am 04.11.2020 um 19:39 schrieb Eugene Sidelnyk :
> > Thus, can you provide any other dangerous example?
>
> I think at this point you could have realised that it is
> a) a BC break (code which has thrown an exception before now wouldn't)
> b) not finding any love among the community here. Possibly for a reason?
>
> If you really want you could put an RFC together but I'm pretty sure that
> it wouldn't be accepted.
>
> And now for your dangerous example:
> try {
> $foo = null;
> $foo->bar();
> deletel_all_files_on_machine();
> } catch (Error $dummy) {}
>
>
> Regards,
> - Chris
>
>

Re: [PHP-DEV] Nullsafe

[Marco Pivetta]

Hey,

On Wed, Nov 4, 2020, 20:39 Eugene Sidelnyk  wrote:

> Yeah... Creating null was a huge mistake.
> Now it is probably too late to fix that (maybe some new language can
> introduce that).
>
>
Y'all confusing Java's `null` (billion dollar mistake) with PHP's `null`.

 * In Java, `null|object` passes the `object` property and parameter type
declaration, but crashes on `.` (`->` operator in PHP). That means that the
type system is fundamentally flawed.
 * In PHP, `null|object` does not pass the `object` property and parameter
type declaration, and crashes on `->`

The PHP `T|null` type is almost equivalent to `data Maybe T = Just T |
Nothing` from typed functional languages, and does not present the same
"billion dollar mistake" flaws of Java.
It is also an accurate and sufficient representation of "absence of value".

That's why I linked the `toString()` vs `(string)` example in
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229

Also, this was previously discussed in a similar way in
https://externals.io/message/108369#108386

But what do you think about introducing special class `NullObject`?
>

You can really only apply the null object pattern (you can use the one from
https://github.com/Ocramius/ProxyManager/blob/2.9.1/docs/null-object.md,
which is relatively type-safe) when interactions with such an object
leading to no effect are valid.

In the example I wrote above:

Let's assume following repository signature:

```php
interface Accounts
{
/** @throws AccountNotFoundException */
public function get(AccountHolder $id): Account;
}
```

In following usage:

```php
$accounts->get($receiver)
->addFunds(
$accounts->get($sender)
->detractFunds($amount)
);
```

Assuming `->` were capable of operating with `object|null` (OP proposal),
if (by accident) somebody decided to change this signature:

```diff
interface Accounts
{
-/** @throws AccountNotFoundException */
-public function get(AccountHolder $id): Account;
+public function get(AccountHolder $id): ?Account;
}
```

In this scenario, what can happen is that money disappears, as I've written
above:

 > In the above scenario, if the first `$accounts->get()` call returns
`null` for any reason, you may actually destroy money (funds detracted, but
never added to another account).

The same would happen if a `NullObject` were used:

```diff
interface Accounts
{
-/** @throws AccountNotFoundException */
-public function get(AccountHolder $id): Account;
+public function get(AccountHolder $id): NullObject|Account;
}
```

Same scenario (slight variation):

 > In the above scenario, if the first `$accounts->get()` call returns `
NullObject ` for any reason, you may actually destroy money (funds
detracted, but never added to another account).

I would say that embracing nullability **in a type-safe manner** (please
use https://psalm.dev/ or https://phpstan.org/) leads to proper usage of
`null`, where it correctly indicates cases where no value has been
produced/found/calculated/etc.

Null pointer exceptions are trivially avoided by using any of these
relatively stable and well adopted static analysis tools, and we don't
really need to fight windmills at all.

Re: [PHP-DEV] Nullsafe

[Josh Bruce]

> On Nov 4, 2020, at 1:38 PM, Eugene Sidelnyk  wrote:
> 
> Yeah... Creating null was a huge mistake.
> Now it is probably too late to fix that (maybe some new language can
> introduce that).
> 
> But what do you think about introducing special class `NullObject`?

I would rather let an instance be “empty” than to have a unique, separate thing 
that always represents nothing. To be fair, I don’t know the specific 
NullObject implementation here - based on presumption - I would intentionally 
be creating something that represents nothing.

See also this RFC: https://wiki.php.net/rfc/objects-can-be-falsifiable 
 - sounds like this thread 
might bring more supporters to that table/discussion.

Cheers,
Josh

Re: [PHP-DEV] [RFC] Short-function syntax

[Nuno Maduro]

Hey Larry,

In my vision, this proposal is a good addition to PHP exactly as stated in
this pull request (https://github.com/php/php-src/pull/6221): where only
the "=> expr;" is introduced, and not the "fn".

For visual consistency in the future of PHP functions/methods, I think it's
important to differ "=> expr;" from "fn":

- "=> expr;" means "arrow": syntax that defines functions/methods with
one-line return expressions.
- "fn" means "short": syntax that makes functions inherit scope. It's
already in use by arrow short closures (
https://wiki.php.net/rfc/arrow_functions_v2 ).

Therefore, from my understanding, your proposal would allow all the
following things to be possible:
```php
// arrow function
function foo() => /** */;

// arrow closure
$foo = function () => /** */;

// fn/short arrow closure ( already introduced in PHP 7.4 )
$foo = fn() => /** */;

class Foo {
// arrow method
poublic function bar() => /** */;
}
```

If this proposal keeps using the "function", and not the "fn", I don't see
any conflict with my Proposal (multi-line short closures -
https://github.com/php/php-src/pull/6246).

Good luck with the RFC.

- Nuno