Thanks Matthew! That is exactly what I couldn't find. I appreciate the link and agree with all of your points!
Can I suggest that, as per definition of the second parameter - "optionally, scheme-specific information about how to gain authorization to access the resource.", the parameter name ( along with the description ) gets changed from `$password` to `$authorizationParameter` or something more generic than password? On Monday, March 18, 2019 at 5:10:37 PM UTC+2, Matthew Weier O'Phinney wrote: > > > > On Mon, Mar 18, 2019 at 8:37 AM Robert Crous <[email protected] > <javascript:>> wrote: > >> I understand that `Uri(some_url)->userInfo` returns the result of >> `parse_url(some_url)[user]` (and then optionally append ':' . [pass]). >> >> My question is: why are there no setters and getters available for `user` >> and `pass`? >> >> I can't see any reason why having getters/setters available for user + >> pass would disrupt anything and it seems fairly odd that the decision was >> made to replace this with `getUserInfo` and `withUserInfo`. >> >> But is there a specific reason why this was done? >> > > There is a reason: because the user-info segment of a URI is not limited > to user/pass combinations, and user/pass combinations are, in fact, > deprecated, per RFC 3986 Section 3.2.1: > https://tools.ietf.org/html/rfc3986#section-3.2.1 > > This is also why we do not provide separate "getter" methods for the > user/pass. When using that functionality, the onus is on the user to know > that both fields are present, and to split them manually. (Having > additional methods did not make sense, since the functionality can be > accomplished in userland code using the available methods.) > > As such, we provide the following methods only: > > - getUserInfo(), which will return the full user-info segment > - withUserInfo(string $user, ?string $password = null) : UriInterface, > which allows creating and returning a new instance with the provided > user-info data. > > As noted elsewhere in this thread, the majority of interfaces in the > specification are marked immutable, and the way to create variants of any > given instance is via the various `with*()` methods. This decision is > documented in the meta document. > > > And if not- is there any way this can be added to the spec for the URI >> interface? >> >> Kind Regards, >> >> Rob >> >> -- >> You received this message because you are subscribed to the Google Groups >> "PHP Framework Interoperability Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/b45e38a2-222c-4b3a-afb6-bd2f130547f7%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/b45e38a2-222c-4b3a-afb6-bd2f130547f7%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Matthew Weier O'Phinney > [email protected] <javascript:> > https://mwop.net/ > he/him > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/e7f4d1c9-8fce-4812-bfc6-83b5d2273906%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
