>Prove me wrong.
I would say that [throw expressions](https://wiki.php.net/rfc/throw_expression) and [constructor promotion](https://wiki.php.net/rfc/constructor_promotion) are *slightly* more important. Don't get me wrong, I use named parameters, but I don't think I could go back to old-school constructors, or having 3 lines to protect the data instead of just one like:
$entity = $repo->find(42) ?? throw new SomeException();
$fp = fopen('myfile.txt) ?: throw new AnotherException();
// we can already start using the above variables
Constructor promption and named arguments go hand-in-hand!
Shot:
class Point {
public function __construct(
public float $x = 0.0,
public float $y = 0.0,
public float $z = 0.0,
) {}
}
Chaser:
new Point(x: 1, y: 2, z: 3)
constructor promotion, while very cool, is the opposite of improved readability.
all the attributes in the constructor arguments, and having properties split up between constructor arguments and class properties, while some constructor argument can also not be class properties... it can be very messy.
Actually it's well known that the train's engineer checks over the train before it leaves, gives it a gentle kiss on the caboose, then sits and relaxes as they watch the train disappear over the horizon on the way to the next town, and a new engineer.
/S
Engineers are individuals who are installed within a functional system. Code standards and readability really matter if you know you (or someone else) will have to go back and make changes.
>all the attributes in the constructor arguments
Do you mean something like Doctrine entities? It is just one line of attributes per property, and I switched to XML anyway. Advanced types like `non-empty-string` goes into phpdoc, and are also now written just once. I find my entities cleaner than ever.
For Symfony autowiring, like iterable of tagged services, that one attribute is inevitable with or without constructor promotion.
Counter point, property promotion cramming most (but not all) properties in the method signature makes it more chaotic and harder to read. The solution should’ve been to `$this->propName` in the signature instead.
It's not just that, but even with one or two parameters with unobvious arguments like booleans, it can provide a big readability benefit, without having to have your IDE expose every single parameter name:
doThing($foo, retry: false)
Is much nicer than
doThing($foo, false)
I want to love named parameters, I'd been basically begging for them for years, but the implementation we got frankly stinks. They're unsafe because the creators didn't bother to enforce the Liskov Substitution Principle (LSP) because doing so would have been a breaking change.
This means that you can't safely substitute extending classes for their parent class or even safely use interfaces because parameter names are not part of the "signature-contract" and have no guarantee to match. They're innately unsafe in any sort of enterprise-level code and should frankly just be avoided in production code until they decide to enforce LSP, hopefully in PHP9 if not sooner.
You can see a clear illustration of the issue here: https://3v4l.org/L1Ki3
It's a particularly frustrating situation because they'd be absolutely amazing for Factories, but the entire purpose of factories is to be polymorphic, and polymorphic uses are where unenforced LSP is the most dangerous.
i dont know, ive written hundreds of classes and thousands of callsites with named arguments and havent encountered a single bug of this sort. yes i have had one or two ocassions to see it, but my IDE warned me immediately. and no such code ever made it through tests to production. using named arguments became such routine for me, i am using them for all calls with more than 1 argument and im totally happy with how clear the code becomes that im willing to accept the risk that it could cause this type of bug one day in production. definitely feels more worth risking it, than not using named arguments in my code until lsp is implemented.
Huh, didn't encounter this. I thought it's not possible to have different parameter names. IDE marks it immediately anyway, but idk if static analysis tools have that. If you use Qodana then you'll have it.
No one using the right tooling does that. But there are people out there that hate IDEs for some reason, and swear on using text editors. They will probably accidentally screw this up.
That being said: Who cares about those guys.
Yes, Psalm makes you use the same name as your parent. I've had to suppress the error once when doing multiple inheritance (extending a class and implementing an interface) and the two parents disagreed on the name, even though I think they were designed to be used together.
I literally never ran into this problem (20 years exp). If interface forces some type or some name (of an attribute), it has a reason for it. Therefore overriding named attribute looks like antipattern to me. It would be cool but also would give a lot space for code confusion.
> This means that you can't safely substitute extending classes for their parent class or even safely use interfaces because parameter names are not part of the "signature-contract" and have no guarantee to match. They're innately unsafe in any sort of enterprise-level code
yeah, you need to add strict static analysis to counter this inherent issue.
This is the logic that led me to a life of FOP / Procedural, as when I learned PHP it didn't really support OOP.
In recent memory, I did a PHP / JS implementation of passkey authentication on a proprietary system. It wasn't easy, but I did it in record time Rambo style.
Few months later, I went to go implement the same thing in NodeJS. The first library I tried to use explicitly warned it wasn't "production ready" (paraphrasing here).
Since then, I can't count the amount of times I have seen that implementation (or similar) utilized on production environments. Are they wrong for that? I don't know. I didn't go through with it - but many others decided the risk was worth it and deployed anyway.
This was properly discussed in the original [RFC](https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance). They also did analysis of the top 2k packages and only found [a few](https://gist.github.com/nikic/6cc9891381a83b8dca5ebdaef1068f4d) instances where it would cause problems, mostly with the Facebook library.
1. That's not a useful metric. The majority of extension happens at the application level and not the library level.
In our monolith alone I have found many examples by many developers of methods parameters not matching the names as defined in the interface.
2. If it was as little of a problem as indicated that seems like a strong argument for enforcing LSP
It has its place for sure. Having many function parameters should be avoided though, there are usually better ways to pass parameterised data around, but not always, where this does become super handy.
Yeah agreed. If you have a method with like 10 optional arguments, that's definitely a code smell and should probably be refactored into a builder pattern or something like that.
When you propose to refactor something the reaction mostly is: ain't nobody got time for that
Unless the refactor needed is the only way forward for writing quality features
guess it depends on what you're doing, and sure you could always replace w/ shit like `array $options = ['default_values' => 'value']`, but really depends on what you're doing. I'd never do it in PHP, but if gamedev was something i'd play w/ there's a few 5 parameter methods I could easily see myself making that would never change.
I’m glad that the authors went with the best syntax instead of a more cumbersome one just for the sake of being “consistent” with php. Because the initial rfc (or maybe the first rfc that proposed this feature, I don’t remember) was using an ugly array like syntax (I don’t remember exactly but it was something like: create(‘firstName’ => ‘John’, ‘lastName’ => ‘doe’).
I mention this because in the clone with RFC people were complaining that the proposed syntax was not php-like which made the author change it to an uglier syntax using arrows like in my example above.
I don't use it that much. It's typically only when I don't want to pass all parameters to a function and want to skip one the ones with default values.
I agree that it is good for readability, but PHPStorm has already provided the name of the argument for years before this was a thing. So if you are using PHPStorm it is not really an upgrade when it comes to readability.
When we're talking business and logistics... I think of variables, functions, etc.; - never in my mind do I think "if I only had NAMED ARGUMENTS..." - it isn't even on the chopping block.
PHP did them well.
Javascript falls down very hard here.
function animals(cat="a", dog="b", bird="c") {
alert(`cat: ${cat} dog: ${dog} bird: ${bird}`)
}
animals(bird="z")
Result
`cat: z dog: b bird: c`
like, the fuck??
It's why Typescript is a thing in JS-- you're forced to use an anonymous object as a work-around...
function animals({ cat = "a", dog = "b", bird = "c" } = {}) {
alert(`cat: ${cat} dog: ${dog} bird: ${bird}`)
}
animals({ bird: "z" })
Great post. I feel like people shit all over PHP for so long they failed to realize that most of the behavior was fairly well documented and understood (in relation to weakly typed variable casting). Dynamically typed languages aren't the devil: people who use them improperly are.
That's an odd statement to make in this thread, where we're discussing how it's great that PHP finally added a syntax feature that's been common in competitors for literally multiple decades.
JavaScript/JSX. Languages that support macros like Rust, C, etc.
Then again, for many languages that don't support inlining HTML that's considered sort of a feature and they generally just have corresponding ways to edit HTML that are more tightly integrated with the language features.
People are down-voting you, probably because of just how robust PHP is in this aspect.
I have production code that uses PHP to template out the HTML, CSS, and even JS of a page. You can just weave in and out of PHP like it isn't even really there, more of an extension on top of HTML and CSS for the server.
A good test for this is that github identifies .php files with no PHP in them as Hack. What other languages can you do stuff like that in? Do you think Python or Rust is going to still compile and run properly if the .py, for instance, doesn't actually contain Python?
AFAIK, this is unique to PHP and very few other languages.
99.99% of things you can do in any language. That other 00.01% is a .php file that contains html, js, css and zero php still rendering properly.
> People are down-voting you, probably because of just how robust PHP is in this aspect.
I wasn't even making a judgement call about how good any of these options were. The comment I was replying to just was claiming that this was a unique feature when it's really not. Arguing whether this is the best implementation is a completely different discussion and one that's inevitably very subjective.
I can't think of a single popular language that has worse syntax than PHP... java maybe? Perl depending on who you ask?
Saying it's good syntax is a stretch let alone best lmao
If you wanted to know you would have read the comment where I pointed out a bunch of things. Or, you know, not be an emotionally attached 1 language dev.
Get over yourself mate. Emotionally attached 1 language dev... lol. You're the one who got defensive over a simple question. PHP is just one tool of many that gets the job done just fine, and the syntax has never been an issue for me. It might not be the best, but it's a damn sight better than Objective C or VB, for instance.
Yeah PHP is great. Completely irrelevant to the conversation though. It's clear though that you didn't read anything and instead emotionally reacted and gave your own little context in your head.
I don't understand your initial comment then. I am not a Java developer myself but when I read books about programming, I like it when the provided examples are written in Java. It's simply one of the cleanest languages out there.
It's about syntax. Some of PHPs bad syntax has reasons for existing too... and I couldn't think of any language that could be considered worse than PHP by someone. It's not that deep.
Dollar signs the only difference lmao. I wasn't aware COBOL was some super popular language (I shouldn't have mentioned perl either but I can't think of anything that is worse that is popular).
* dollar signs are annoynig but whatever, you brought it up
* function keyword spam for everything, even when not needed and for things that aren't functions
* ->
* namespaces are just class prefixes with shitty syntax
* they couldn't even add arrow functions properly
* \_\_construct and magic methods in general
* they managed to add attributes finally and then used the worst syntax possible, almost as bad as javascript private properties
That's enough for now.
I like PHP. But to make out it has the best syntax is mental.
Named arguments truly are awesome.
But IICE's are even more awesome.
```
new class (meaning: 'Immediately Invoked Class Expression') {
public function __construct (string $meaning) {
header ('Content-Type: text/plain; charset=utf-8')&exit (
"This is $meaning"
);
}
};
```
If compared to IIFE, actual parameters are at top level, not at bottom.
From my perspective, easier to handle and modify (or whichever) with IICE.
```
(function (string $meaning) {
header ('Content-Type: text/plain; '
. 'charset=utf-8')&exit ("This is $meaning");
}) (meaning: 'Immediately Invoked Function Expression');
```
I don't like that in JS because it doesn't enforce the structure or types. Is TS different?
I recently started using simple record like readonly classes in PHP, only having validation and some light modifying of fields. I love it, every field is documented in code and has a type.
TS certainly can be used to enforce structure and types yes - that's pretty much the entire point of TS as distinct from JS. You can also use the Typescript compiler to enforce the same thing in Javascript files, by writing the type information in jsdoc comment blocks.
TS crutch was made because named/optional params are broken in JS see: https://old.reddit.com/r/PHP/comments/1d9z5w5/named_arguments_php_8_are_the_greatest_thing_for/l7iey8u/
Why I feel people who loves the named parameters have to work with bad code. If you need 10 parameters instead of passing builder as an argument then something is wrong
Using named parameters is prone to input validation errors
They are pretty nice to use and we are actually lucky to have them with how stubborn php internals are. Same with a bunch of stuff we have now actually, it took years.
I use them only for `new SomeException('a message', previous: $e)`, because the `Exception#__construct()` API stinks.
They're very much useless to me, and they've broken:
* argument splatting / variadic argument guarantees (was: `list`, is now `array`)
* BC on tons of library details: this is mostly an OSS maintainer problem, but it has hurt me plenty
Overall, they're one of the least used features in the language, and they came with big drawbacks for my use-cases.
In fact, they are only useful if your API stinks.
I think they're great. Mostly. Especially when a function has a lot of arguments, and some of them are optional.
Having said that: we had a new developer come in for a few months and in every PR, in every function call, he used named parameters, and it irritated the rest of us. It's like he was using named parameters as a way to avoid internalizing our API which, particularly when it comes to function signatures, is pretty simple and pretty consistent. For example our model / repository components all have credit operations that take two parameters, always in the same order. There's really no good reason to have to use named arguments in the scenario.
It's a great QOL change, and being optional is even better.
>Prove me wrong. I would say that [throw expressions](https://wiki.php.net/rfc/throw_expression) and [constructor promotion](https://wiki.php.net/rfc/constructor_promotion) are *slightly* more important. Don't get me wrong, I use named parameters, but I don't think I could go back to old-school constructors, or having 3 lines to protect the data instead of just one like: $entity = $repo->find(42) ?? throw new SomeException(); $fp = fopen('myfile.txt) ?: throw new AnotherException(); // we can already start using the above variables
Constructor promption and named arguments go hand-in-hand! Shot: class Point { public function __construct( public float $x = 0.0, public float $y = 0.0, public float $z = 0.0, ) {} } Chaser: new Point(x: 1, y: 2, z: 3)
Oh my god. TIL you could do that. That's amazing. Thank you!
Constructor promotion and readonly classes. PHP is a great place to be developing
WHAT THE HELL WE HAVE THROW EXPRESSIONS
Now if we could just get return expressions, esp in match arms.
constructor promotion, while very cool, is the opposite of improved readability. all the attributes in the constructor arguments, and having properties split up between constructor arguments and class properties, while some constructor argument can also not be class properties... it can be very messy.
Anything on code can be very messy, it's up to you as an engineer to keep things tidy and in check.
Actually it's well known that the train's engineer checks over the train before it leaves, gives it a gentle kiss on the caboose, then sits and relaxes as they watch the train disappear over the horizon on the way to the next town, and a new engineer. /S Engineers are individuals who are installed within a functional system. Code standards and readability really matter if you know you (or someone else) will have to go back and make changes.
>all the attributes in the constructor arguments Do you mean something like Doctrine entities? It is just one line of attributes per property, and I switched to XML anyway. Advanced types like `non-empty-string` goes into phpdoc, and are also now written just once. I find my entities cleaner than ever. For Symfony autowiring, like iterable of tagged services, that one attribute is inevitable with or without constructor promotion.
Counter point, property promotion cramming most (but not all) properties in the method signature makes it more chaotic and harder to read. The solution should’ve been to `$this->propName` in the signature instead.
I love native attributes. Looks so much better than using phpdocs. Even better with native attributes + named arguments.
but attributes and phpdoc tags have 2 different purposes
True, but things like doctrine, and symfony routing makes way more sense as attributes.
[удалено]
It's not just that, but even with one or two parameters with unobvious arguments like booleans, it can provide a big readability benefit, without having to have your IDE expose every single parameter name: doThing($foo, retry: false) Is much nicer than doThing($foo, false)
I want to love named parameters, I'd been basically begging for them for years, but the implementation we got frankly stinks. They're unsafe because the creators didn't bother to enforce the Liskov Substitution Principle (LSP) because doing so would have been a breaking change. This means that you can't safely substitute extending classes for their parent class or even safely use interfaces because parameter names are not part of the "signature-contract" and have no guarantee to match. They're innately unsafe in any sort of enterprise-level code and should frankly just be avoided in production code until they decide to enforce LSP, hopefully in PHP9 if not sooner. You can see a clear illustration of the issue here: https://3v4l.org/L1Ki3 It's a particularly frustrating situation because they'd be absolutely amazing for Factories, but the entire purpose of factories is to be polymorphic, and polymorphic uses are where unenforced LSP is the most dangerous.
i dont know, ive written hundreds of classes and thousands of callsites with named arguments and havent encountered a single bug of this sort. yes i have had one or two ocassions to see it, but my IDE warned me immediately. and no such code ever made it through tests to production. using named arguments became such routine for me, i am using them for all calls with more than 1 argument and im totally happy with how clear the code becomes that im willing to accept the risk that it could cause this type of bug one day in production. definitely feels more worth risking it, than not using named arguments in my code until lsp is implemented.
I second this.
I third this.
I foursome this.
Hi five
Wow, I didn't realize you could do that. That's pretty ridiculous.
Huh, didn't encounter this. I thought it's not possible to have different parameter names. IDE marks it immediately anyway, but idk if static analysis tools have that. If you use Qodana then you'll have it.
you have a point, but why would you ever rename a parameter of an overridden method? no one does that
No one using the right tooling does that. But there are people out there that hate IDEs for some reason, and swear on using text editors. They will probably accidentally screw this up. That being said: Who cares about those guys.
and they deserve all the errors that come with it lol
Are there lints for this in static analysis tools?
Probably - phpstan doesn't yet enforce it though. I've been waiting.
Yes, Psalm makes you use the same name as your parent. I've had to suppress the error once when doing multiple inheritance (extending a class and implementing an interface) and the two parents disagreed on the name, even though I think they were designed to be used together.
Well polymorphism should be done via interfaces and not inheritance in most cases, anyways But I agree this is not well implemented
The problem, as in the example, exists even with interfaced code.
I literally never ran into this problem (20 years exp). If interface forces some type or some name (of an attribute), it has a reason for it. Therefore overriding named attribute looks like antipattern to me. It would be cool but also would give a lot space for code confusion.
You’re missing out. Just use them. Everybody is using them just fine, including “enterprise” applications
> This means that you can't safely substitute extending classes for their parent class or even safely use interfaces because parameter names are not part of the "signature-contract" and have no guarantee to match. They're innately unsafe in any sort of enterprise-level code yeah, you need to add strict static analysis to counter this inherent issue.
This is the logic that led me to a life of FOP / Procedural, as when I learned PHP it didn't really support OOP. In recent memory, I did a PHP / JS implementation of passkey authentication on a proprietary system. It wasn't easy, but I did it in record time Rambo style. Few months later, I went to go implement the same thing in NodeJS. The first library I tried to use explicitly warned it wasn't "production ready" (paraphrasing here). Since then, I can't count the amount of times I have seen that implementation (or similar) utilized on production environments. Are they wrong for that? I don't know. I didn't go through with it - but many others decided the risk was worth it and deployed anyway.
This was properly discussed in the original [RFC](https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance). They also did analysis of the top 2k packages and only found [a few](https://gist.github.com/nikic/6cc9891381a83b8dca5ebdaef1068f4d) instances where it would cause problems, mostly with the Facebook library.
1. That's not a useful metric. The majority of extension happens at the application level and not the library level. In our monolith alone I have found many examples by many developers of methods parameters not matching the names as defined in the interface. 2. If it was as little of a problem as indicated that seems like a strong argument for enforcing LSP
It has its place for sure. Having many function parameters should be avoided though, there are usually better ways to pass parameterised data around, but not always, where this does become super handy.
Yeah agreed. If you have a method with like 10 optional arguments, that's definitely a code smell and should probably be refactored into a builder pattern or something like that.
When you propose to refactor something the reaction mostly is: ain't nobody got time for that Unless the refactor needed is the only way forward for writing quality features
"If this becomes so dog-shit slow that the end user finds in unbearable... I know how it should have been coded... I didn't have the time, however."
guess it depends on what you're doing, and sure you could always replace w/ shit like `array $options = ['default_values' => 'value']`, but really depends on what you're doing. I'd never do it in PHP, but if gamedev was something i'd play w/ there's a few 5 parameter methods I could easily see myself making that would never change.
I’m glad that the authors went with the best syntax instead of a more cumbersome one just for the sake of being “consistent” with php. Because the initial rfc (or maybe the first rfc that proposed this feature, I don’t remember) was using an ugly array like syntax (I don’t remember exactly but it was something like: create(‘firstName’ => ‘John’, ‘lastName’ => ‘doe’). I mention this because in the clone with RFC people were complaining that the proposed syntax was not php-like which made the author change it to an uglier syntax using arrows like in my example above.
I don't use it that much. It's typically only when I don't want to pass all parameters to a function and want to skip one the ones with default values. I agree that it is good for readability, but PHPStorm has already provided the name of the argument for years before this was a thing. So if you are using PHPStorm it is not really an upgrade when it comes to readability.
But only show the name when the value is a string. When is a variable dont show the name of the parameter.
No, it shows regardless of the type.
I can not find one only use to them. They **are useless**.
When we're talking business and logistics... I think of variables, functions, etc.; - never in my mind do I think "if I only had NAMED ARGUMENTS..." - it isn't even on the chopping block.
PHP did them well. Javascript falls down very hard here. function animals(cat="a", dog="b", bird="c") { alert(`cat: ${cat} dog: ${dog} bird: ${bird}`) } animals(bird="z") Result `cat: z dog: b bird: c` like, the fuck?? It's why Typescript is a thing in JS-- you're forced to use an anonymous object as a work-around... function animals({ cat = "a", dog = "b", bird = "c" } = {}) { alert(`cat: ${cat} dog: ${dog} bird: ${bird}`) } animals({ bird: "z" })
Great post. I feel like people shit all over PHP for so long they failed to realize that most of the behavior was fairly well documented and understood (in relation to weakly typed variable casting). Dynamically typed languages aren't the devil: people who use them improperly are.
Php is best language, best syntax and I’ll fight about it.
That's an odd statement to make in this thread, where we're discussing how it's great that PHP finally added a syntax feature that's been common in competitors for literally multiple decades.
Yeah but who else can inline html??
JavaScript/JSX. Languages that support macros like Rust, C, etc. Then again, for many languages that don't support inlining HTML that's considered sort of a feature and they generally just have corresponding ways to edit HTML that are more tightly integrated with the language features.
People are down-voting you, probably because of just how robust PHP is in this aspect. I have production code that uses PHP to template out the HTML, CSS, and even JS of a page. You can just weave in and out of PHP like it isn't even really there, more of an extension on top of HTML and CSS for the server. A good test for this is that github identifies .php files with no PHP in them as Hack. What other languages can you do stuff like that in? Do you think Python or Rust is going to still compile and run properly if the .py, for instance, doesn't actually contain Python? AFAIK, this is unique to PHP and very few other languages. 99.99% of things you can do in any language. That other 00.01% is a .php file that contains html, js, css and zero php still rendering properly.
> People are down-voting you, probably because of just how robust PHP is in this aspect. I wasn't even making a judgement call about how good any of these options were. The comment I was replying to just was claiming that this was a unique feature when it's really not. Arguing whether this is the best implementation is a completely different discussion and one that's inevitably very subjective.
You're quite funny.
I can't think of a single popular language that has worse syntax than PHP... java maybe? Perl depending on who you ask? Saying it's good syntax is a stretch let alone best lmao
What’s wrong with the syntax? It’s pretty standard c style. Better than javascript.
You think php syntax is better than javascript? In what world?
JavaScript literally has the worst syntax.
I also want to know, what’s wrong with the syntax?
If you wanted to know you would have read the comment where I pointed out a bunch of things. Or, you know, not be an emotionally attached 1 language dev.
Get over yourself mate. Emotionally attached 1 language dev... lol. You're the one who got defensive over a simple question. PHP is just one tool of many that gets the job done just fine, and the syntax has never been an issue for me. It might not be the best, but it's a damn sight better than Objective C or VB, for instance.
Yeah PHP is great. Completely irrelevant to the conversation though. It's clear though that you didn't read anything and instead emotionally reacted and gave your own little context in your head.
We were talking about PHP and syntax, right..? I say were, as I'm not going to continue conversing with an emotional vampire.
Nah you could have just gone back and read but that's okay can't expect much.
Now, I absolutely love TypeScript. But in what world is JavaScript syntax "better" than PHP? Especially if we're talking vanilla JS.
..... what? typescript is javascript with typing... it's the same syntax. you have to be trolling to say js is worse syntax wise than php.
Vanilla JS has no types and you're saying that JS syntax is "better" than PHP. When did you last use PHP? 5.6? I bet you love JQuery.
Oh I see. you're stupid and think syntax is another word for types. Sure, PHP type hinting is better than javascripts not type hinting...
I would agree but I really don't see what's wrong with Java. You may find it to verbose but the syntax is clean and lean.
It's verbose, that's about it. Only thing I could really think of that you could maybe make an argument for.
It's verbose for a good reason. Having to declare the types of args and return should be a standard in all programming languages.
yes I know why it is verbose...
I don't understand your initial comment then. I am not a Java developer myself but when I read books about programming, I like it when the provided examples are written in Java. It's simply one of the cleanest languages out there.
It's about syntax. Some of PHPs bad syntax has reasons for existing too... and I couldn't think of any language that could be considered worse than PHP by someone. It's not that deep.
Why? Because it uses dollar signs? Because that's the only big difference in syntax between other languages. Also have you seen COBOL?
Dollar signs the only difference lmao. I wasn't aware COBOL was some super popular language (I shouldn't have mentioned perl either but I can't think of anything that is worse that is popular). * dollar signs are annoynig but whatever, you brought it up * function keyword spam for everything, even when not needed and for things that aren't functions * -> * namespaces are just class prefixes with shitty syntax * they couldn't even add arrow functions properly * \_\_construct and magic methods in general * they managed to add attributes finally and then used the worst syntax possible, almost as bad as javascript private properties That's enough for now. I like PHP. But to make out it has the best syntax is mental.
Named arguments truly are awesome. But IICE's are even more awesome. ``` new class (meaning: 'Immediately Invoked Class Expression') { public function __construct (string $meaning) { header ('Content-Type: text/plain; charset=utf-8')&exit ( "This is $meaning" ); } }; ``` If compared to IIFE, actual parameters are at top level, not at bottom. From my perspective, easier to handle and modify (or whichever) with IICE. ``` (function (string $meaning) { header ('Content-Type: text/plain; ' . 'charset=utf-8')&exit ("This is $meaning"); }) (meaning: 'Immediately Invoked Function Expression'); ```
Downside being: if you rename an argument, you also have to remember doing it wherever you've called the function while using named args.
Not much downside. Use the refactor function in your IDE. Should be doing that anyway when changing function signatures.
Yes. Object literals and object destructuring parameters in JS/TS come a close second.
I don't like that in JS because it doesn't enforce the structure or types. Is TS different? I recently started using simple record like readonly classes in PHP, only having validation and some light modifying of fields. I love it, every field is documented in code and has a type.
TS certainly can be used to enforce structure and types yes - that's pretty much the entire point of TS as distinct from JS. You can also use the Typescript compiler to enforce the same thing in Javascript files, by writing the type information in jsdoc comment blocks.
Destructuring is great and so smooth to use, until people abuse it.
TS crutch was made because named/optional params are broken in JS see: https://old.reddit.com/r/PHP/comments/1d9z5w5/named_arguments_php_8_are_the_greatest_thing_for/l7iey8u/
Shits garbage bro
First time I saw something similar was Objective-C. Liked it then and like it now.
Especially in [`implode()`](https://www.php.net/manual/en/function.implode.php) and [`explode()`](https://www.php.net/manual/en/function.explode.php).
Why I feel people who loves the named parameters have to work with bad code. If you need 10 parameters instead of passing builder as an argument then something is wrong Using named parameters is prone to input validation errors
They are pretty nice to use and we are actually lucky to have them with how stubborn php internals are. Same with a bunch of stuff we have now actually, it took years.
I use them only for `new SomeException('a message', previous: $e)`, because the `Exception#__construct()` API stinks. They're very much useless to me, and they've broken: * argument splatting / variadic argument guarantees (was: `list`, is now `array`)
* BC on tons of library details: this is mostly an OSS maintainer problem, but it has hurt me plenty
Overall, they're one of the least used features in the language, and they came with big drawbacks for my use-cases.
In fact, they are only useful if your API stinks.
I think they're great. Mostly. Especially when a function has a lot of arguments, and some of them are optional. Having said that: we had a new developer come in for a few months and in every PR, in every function call, he used named parameters, and it irritated the rest of us. It's like he was using named parameters as a way to avoid internalizing our API which, particularly when it comes to function signatures, is pretty simple and pretty consistent. For example our model / repository components all have credit operations that take two parameters, always in the same order. There's really no good reason to have to use named arguments in the scenario.
Wtf! Just don't use them and find a way to not use default values.