You need to make the change against the Framework package here https://github.com/joomla-framework/uri/blob/master/src/AbstractUri.php. Then we can load it trough composer and add it to the CMS. The vendor directory shouldn't being changed in a PR.

Honestly, I'm ? here. In the end all it's doing is introducing a hack that lets you pass an array of parts without wrapping it in an array declaration.

@laoneo Thanks, I'll do that.

@mbabker I'm not sure in what way this is a hack. And, yes, in the end all this is doing is exactly what it's intended to do. Look at it this way, if this were a new function with no questions of BC or anything else what would you say are the merits of each of these approaches?

a) Take any number of strings directly
b) Take an array of strings
c) Take an associative array where each url part is a key and will be used if the value is truthy
d) Like c but with an object instead
e) c + d (array/object agnostic)
f) All of the above

Honestly, if this were really a new function, I'd say use class constants instead of strings anyway but that's a bit of a tangent.

It turns something with a defined signature (granted it's not the most well defined thing, but it still has a purpose) and turns it into a variadic function with what results in a signature that cannot be documented accurately. Even if this were a new method I'd look at it the same way. Honestly I'm not the biggest fan of variadic functions or unkeyed arrays being used for function signatures, I prefer specificity in my code and documentation as to me it results in clearer expectations for the developer maintaining the code and the consumer using it.

In fact, I agree with you in principle but I also prefer to look at things on a case by case basis rather than stick to some absolute ideals. I don't believe this change introduces any significant ambiguity to the way this function can be used but it does make it simpler to use. I suppose how those things balance out is mainly a matter of opinion.

It might not be terribly relevant but Joomla already has many functions that work in a similarly flexible way. For example JDatabaseQuery::select, which I would say is more ambiguous than this proposal.

Yes, Joomla has many such functions. Mostly old functioms where it couldn't be changed for B/C reasons.
Let's not introduce more from them if not absolutel needed.

Closing this as it is the wrong repo anyway (it should be in the framework as @laoneo poiinted out) and chances are high it doesn't get accepted anyway.

The difference with this proposal and JDatabaseQuery::select() is the latter method either accepts a single string or a single array whereas this proposal changes the method to accept an unlimited number of strings, and that's what I'm not a fan of here. If there's really going to be a change, I'd rather it be similar to the database query and it allow a single string (just wrap it in an array if need be).