The static constructor would especially be useful for dynamic instantiation, e.g. $className::new() vs new $className() due to IDE and static analysis support. At least right now in PHPStorm $className::make() has IDE support for me, new $className() does not
@@phpannotated I don't remember, but maybe it's mainly just being able to click on the ::make() part to go to definition, while you can't click on the braces in new $className()
new MyClass()() opens up for typo or replacement errors. Im not a fan of (new MyClass())->... , but also dont really like the new new MyClass()->... . I stick to $object = new MyClass(); $object->... .
@@barneylaurance1865 No, I mean function overloading. So I wont have to write ugly ifs with func_*() functions. I'm not quite sure what you mean about compile time, because php is an interpreted language (did you mean parsing?). Nevertheless in php we have precious type-hints that really work
@@theargentum PHP does have a compiler, its just very fast so you don't notice it running. I think what you're talking about is indeed double dispatch - meaning the function to call is looked up not just bye the type of the parameter on the left of the arrow as it is now but also by the type of the param(s) on the right.
I dont like it. It makes the scope of the class ambigious. That was the purpose of the brackets. To tell the developer "Hey this expression wont exist when the brackets are closed!"
Thank you very much for reviewing my RFC!
Thank you for making it!
this was contributed by Valentin Udaltsov from PHPoint channel
FINALLY!
:D Had a good chuckle at the "it didn't get any upvotes" :D
I'll go give you an upvote Brent! You deserve it!
How much of your code will you be able to refactor? 🤓
it can be automated with rectorPHP
The static constructor would especially be useful for dynamic instantiation, e.g. $className::new() vs new $className() due to IDE and static analysis support. At least right now in PHPStorm $className::make() has IDE support for me, new $className() does not
I'll check with the team if we can improve this 👍
I checked, apparently it works in simple cases, what was your specific use case where it didn't?
@@phpannotated I don't remember, but maybe it's mainly just being able to click on the ::make() part to go to definition, while you can't click on the braces in new $className()
new MyClass()() opens up for typo or replacement errors.
Im not a fan of (new MyClass())->... , but also dont really like the new new MyClass()->... .
I stick to $object = new MyClass(); $object->... .
Cool. Still waiting for some real improvements like damned function overloading...
Personally not a fan of the idea of function overloading, but that might change if they ever get added :)
Do you mean double dispatch? I don't see how you can have compile time function overloading when variables are dynamically typed.
@@barneylaurance1865 No, I mean function overloading. So I wont have to write ugly ifs with func_*() functions. I'm not quite sure what you mean about compile time, because php is an interpreted language (did you mean parsing?). Nevertheless in php we have precious type-hints that really work
@@theargentum PHP does have a compiler, its just very fast so you don't notice it running.
I think what you're talking about is indeed double dispatch - meaning the function to call is looked up not just bye the type of the parameter on the left of the arrow as it is now but also by the type of the param(s) on the right.
It's just reducing the readability, I hope they don't turn this into typescript...
Yeah, because JavaScript and readability go hand in hand 😅.
(foo[bar?'baz1':'baz2']())().buzz()
Oh I hope they do!! 🔥
I dont like it.
It makes the scope of the class ambigious. That was the purpose of the brackets. To tell the developer "Hey this expression wont exist when the brackets are closed!"
Well the RFC explains how that ambiguity already exists in PHP without the RFC, so it doesn't really make a difference.