Today we're taking a look at a seemingly small RFC for PHP 8.4, but one that'll have a pretty big impact. rfc.stitcher.io/rfc/new-mycla... #PHP #whatsnew
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
@@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.
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->... .
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!"
I will be slapping that Rector rule in my primary project when it gets added. A nice little QoL improvement. :)
Thank you very much for reviewing my RFC!
Thank you for making it!
this was contributed by Valentin Udaltsov from PHPoint channel
: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
FINALLY!
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?
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!! 🔥
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->... .
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.