Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
Hi! 3. I am already aware of several people within internals that believe any version of this feature will result in uncontrolled chaos in PHP codebases. I think this is false, as I do not see that kind of uncontrolled chaos in the languages which do have this feature. However I would think that allowing arbitrary overloads would increase that proportion. Depends on how you define "uncontrolled chaos". I have encountered toolkits where the authors think it's cute to define "+" to mean something that has nothing to do with mathematical addition (go read the manual for an hour to figure what it actually does) or for += to mean something different than + and assignment. Some people even learn to love it, so far I haven't. However, once a feature is added it is very difficult to change it. Not only for backward compatibility reasons, but for the sheer inertia of the massive impact that PHP has. I do not plan on ever proposing that arbitrary symbol combinations be allowed for overloads myself. But I cannot possibly know what internals might think of that possibility 10 years from now when this feature has been in widespread usage for a long time. Using magic methods makes it extremely difficult at *any* point in the future to allow PHP developers the option of an overload for say +=+. What would such a That's awesome. The only thing worse than a toolkit author that thinks it's cute to play with "+" is the one that thinks it's cute to invent some random combination of special characters and assign it some meaning that of course is obvious to the author, but unfortunately that's the only person in existence to whom is it obvious. Some people enjoy the code being a puzzle that you need to untangle and make a sherlockian detective work to even begin to understand what is going on in this code. Other people have work to do. And again, what's the intuitive difference between operators +=+@-+ and ++--=!* ? Of course, of course I know, every feature can be abused. The difference here is that if it's hard to think about any use that wouldn't be an abuse. That sounds far *less* maintainable to me. It seems more likely that even if it were a desired feature 10 years from now, it would be something that would be extremely difficult to implement, maintain, and pass. I must notice "if" carries a lot of load here. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] !instanceof operator - reaction measuremen
I would like to create my first RFC proposing adding a new operator
`!instanceof` named `T_NOT_INSTANCEOF`.
The purpose of this RFC is to add syntactic sugar for checking if an object
is not an instance of something else.
The current syntax for checking not instance of looks the following way
```php
!$object instanceof MyClass
```
When I read this I read it as:
Negate the `$object` variable and check if that is an instance of `MyClass`.
My proposed operator would allow for the following syntax
```php
$object !instanceof MyClass
```
This is for me and people I have spoken to a much clearer syntax.
Some arguments on other ways the not instance of can currently be written
```php
!($object instanceof MyClass) // Wrapping in parenthesis
! $object instanceof MyClass // Simply adding spacing
```
My main problem with these alternative syntaxes is the readability when
added inside an `if` condition
```php
if(!($object instanceof MyClass)) { ...
if(! $object instanceof MyClass) { ...
```
compared to
```php
if($object !instanceof MyClass) { ...
```
In regards to implementing the feature, I wouldn't mind trying to do that
myself. I believe this change is relatively simple in the parser and AST
and something I should be able to figure out.
What do people think about this? Would love to clarify if needed.
Best regards
Oliver Nybroe (he/him)
Re: [PHP-DEV] [RFC] !instanceof operator - reaction measuremen
Heya,
While I definitely agree with this, and after more than 10 years of PHP I
still have the tendency to write `if ($object !instanceof MyClass)` anyway.
Would it be possible, or would it collide with constants to do the
following?
```
$object === MyClass;
$object !== MyClass;
```
The reason I'm hoping this would be possible, is that I often have brainlag
trying to write "instanceof" and I either make several typos, or I end up
with "instance" and it takes me an error message to realize I forgot the
"of". The "instanceof" is counterintuitive for me compared to operators.
If this isn't possible and `!instanceof` would be adopted, what about the
following in addition to the proposed example?
```
$object implements MyInterface;
$object !implements MyInterface;
$object extends MyClass;
$object !extends MyClass;
```
On Mon, Dec 13, 2021 at 11:53 AM Oliver Nybroe
wrote:
> I would like to create my first RFC proposing adding a new operator
> `!instanceof` named `T_NOT_INSTANCEOF`.
>
> The purpose of this RFC is to add syntactic sugar for checking if an object
> is not an instance of something else.
> The current syntax for checking not instance of looks the following way
> ```php
> !$object instanceof MyClass
> ```
> When I read this I read it as:
> Negate the `$object` variable and check if that is an instance of
> `MyClass`.
>
> My proposed operator would allow for the following syntax
> ```php
> $object !instanceof MyClass
> ```
> This is for me and people I have spoken to a much clearer syntax.
>
>
> Some arguments on other ways the not instance of can currently be written
> ```php
> !($object instanceof MyClass) // Wrapping in parenthesis
> ! $object instanceof MyClass // Simply adding spacing
> ```
> My main problem with these alternative syntaxes is the readability when
> added inside an `if` condition
> ```php
> if(!($object instanceof MyClass)) { ...
> if(! $object instanceof MyClass) { ...
> ```
> compared to
> ```php
> if($object !instanceof MyClass) { ...
> ```
>
>
> In regards to implementing the feature, I wouldn't mind trying to do that
> myself. I believe this change is relatively simple in the parser and AST
> and something I should be able to figure out.
>
>
> What do people think about this? Would love to clarify if needed.
>
> Best regards
> Oliver Nybroe (he/him)
>
Re: [PHP-DEV] [RFC] !instanceof operator - reaction measuremen
pon., 13 gru 2021 o 12:10 Lynn napisał(a): > Heya, > > While I definitely agree with this, and after more than 10 years of PHP I > still have the tendency to write `if ($object !instanceof MyClass)` anyway. > Would it be possible, or would it collide with constants to do the > following? > ``` > $object === MyClass; > $object !== MyClass; > ``` > The reason I'm hoping this would be possible, is that I often have brainlag > trying to write "instanceof" and I either make several typos, or I end up > with "instance" and it takes me an error message to realize I forgot the > "of". The "instanceof" is counterintuitive for me compared to operators. > > If this isn't possible and `!instanceof` would be adopted, what about the > following in addition to the proposed example? > ``` > $object implements MyInterface; > $object !implements MyInterface; > $object extends MyClass; > $object !extends MyClass; > ``` > Why not "not" instead? The "!" in front of "i" in "!implements" is almost not visible which IMO could get easily ignored unintentionally. Instead constructs like "$foo not implements stdClass" have higher visibility and are currently a syntax error. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [RFC] !instanceof operator - reaction measuremen
On Mon, Dec 13, 2021 at 12:19 PM Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > > Why not "not" instead? The "!" in front of "i" in "!implements" is almost > not visible which IMO could get easily ignored unintentionally. > Instead constructs like "$foo not implements stdClass" have higher > visibility and are currently a syntax error. > > Cheers, > Michał Marcin Brzuchalski > Definitely a good idea! I was considering suggesting that as well when writing the implements/extends down, but wasn't sure if that would be doable as it would introduce a new keyword as well if I understand the setup of php correctly.
Re: [PHP-DEV] [RFC] !instanceof operator - reaction measuremen
> The "instanceof" is counterintuitive for me compared to operators. Hmm interesting, might be possible to go that direction by making `T_IS_EQUAL` accept `class_name_reference`. I like that, biggest concern with this is what is the difference (if any) between ```php $object !== MyClass $object != MyClass ``` > If this isn't possible and `!instanceof` would be adopted, what about the following in addition to the proposed example? I definitely agree that those make sense, but I would say that they should prob. have their own discussion, but would be much easier to get through if this one would be accepted. > Why not "not" instead? The "!" in front of "i" in "!implements" Might be my limited knowledge on the subject, but by using `not`, we are making `not` a reserved keyword, which I think should be done really carefully. Best regards Oliver Nybroe (he/him) On Mon, 13 Dec 2021 at 12:19, Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > > > pon., 13 gru 2021 o 12:10 Lynn napisał(a): > >> Heya, >> >> While I definitely agree with this, and after more than 10 years of PHP I >> still have the tendency to write `if ($object !instanceof MyClass)` >> anyway. >> Would it be possible, or would it collide with constants to do the >> following? >> ``` >> $object === MyClass; >> $object !== MyClass; >> ``` >> The reason I'm hoping this would be possible, is that I often have >> brainlag >> trying to write "instanceof" and I either make several typos, or I end up >> with "instance" and it takes me an error message to realize I forgot the >> "of". The "instanceof" is counterintuitive for me compared to operators. >> >> If this isn't possible and `!instanceof` would be adopted, what about the >> following in addition to the proposed example? >> ``` >> $object implements MyInterface; >> $object !implements MyInterface; >> $object extends MyClass; >> $object !extends MyClass; >> ``` >> > > Why not "not" instead? The "!" in front of "i" in "!implements" is almost > not visible which IMO could get easily ignored unintentionally. > Instead constructs like "$foo not implements stdClass" have higher > visibility and are currently a syntax error. > > Cheers, > Michał Marcin Brzuchalski >
Re: [PHP-DEV] [RFC] !instanceof operator - reaction measuremen
Den man. 13. dec. 2021 kl. 12.53 skrev Oliver Nybroe : > What do people think about this? Would love to clarify if needed. > > Best regards > Oliver Nybroe (he/him) I find this to be more a problem to be solved by individual coding standards and cs tools. The !instanceof syntax is awkward at best, at least I find it to be so because it is mixing a symbol with a word to form an operator. The documentation already states the following[1]: > Use of parentheses, even when not strictly necessary, can often increase > readability of the code by making grouping explicit rather than relying on > the implicit operator precedence and associativity. [1] https://www.php.net/manual/en/language.operators.precedence.php -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] LOCK_SH for file_get_contents ?
This has been requested for years (since at least 2009?) but it seems no actual plan has been proposed How about this? since we already have the constant FILE_USE_INCLUDE_PATH , seems it was introduced in PHP5.0.0, 1: FILE_USE_INCLUDE_PATH currently collides with LOCK_SH (they're both 1), lets change FILE_USE_INCLUDE_PATH to something that doesn't collide with any of LOCK_SH | LOCK_EX | LOCK_NB for example (1 << 3) / int(8) 2: change argument #2 from "bool $use_include_path = false" to "int|bool $flags = 0" , treating bool(false) the same as int(0) and bool(true) the same as FILE_USE_INCLUDE_PATH , and support LOCK_SH | LOCK_NB | FILE_USE_INCLUDE_PATH here (i think LOCK_EX could also be supported, but that might be controversial, and the use case is certainly limited, if there is one at all) because it's kind of silly, and at times annoying, that file_put_contents support LOCK_EX but file_get_contents does not support LOCK_SH
Re: [PHP-DEV] Allow default parameters before non-default ones?
>Четверг, 9 декабря 2021, 8:22 +03:00 от André Hänsel :
>
>PHP 8 has named parameters in function calls, Kotlin has named parameters in
>function calls.
>
>Kotlin has this handy feature that you can put parameters with defaults
>before normal ones. Those parameters can then only be used by naming them.
>See also: https://kotlinlang.org/docs/functions.html#default-arguments
>
>This is very useful because I can add an optional parameter to a function
>and prevent users of my function from using the parameter in a positional
>way. This way I don't have to make a compatibility promise to never change
>the position of this parameter.
>
>If I try the same thing in PHP 8.0 I get a Deprecated warning and if I try
>it in PHP 8.1 I get something that I don't understand:
>https://3v4l.org/cg4DA
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: https://www.php.net/unsub.php
I'll add that leading optional parameters are needed to implement currying and
partial application.
```
function foo(int $opt = 42, int $req) {}
$foo = curry(foo(...), 23);
// $foo = fn($opt = 42, $req = 23);
```
While this is not a popular practice in PHP, this deprecation notification
«breaks» all code that uses functional pradigm/concepts.
--
Kirill Nesmeyanov
