This, as in the shared containers thread, is surely an implementation detail rather than part of the standard? It would be a shame to limit use of the standard by restricting which character sets are acceptable based on nominal research by people in the western world (I mean this in terms of character sets rather than social or political).
G On Thursday, November 3, 2016 at 7:36:58 PM UTC, Matthew Weier O'Phinney wrote: > > > > On Thu, Nov 3, 2016 at 9:41 AM, Larry Garfield <la...@garfieldtech.com > <javascript:>> wrote: > >> I disagree for exactly that reason. :-) >> >> If the goal is interoperability, then containers need to have at least a >> common baseline of what they should allow. It's essentially an additional >> layer of type checking beyond just "string". That doesn't mean it has to >> specify a dot-delimited format, or require/disallow /, or whatever. Just >> the legal world of opaque strings. >> > > I disagree. We didn't specify beyond the string type in PSR-7 for any of > the various properties that represented lookup tables (attributes, server > params, cookies, query params, etc); doing so is essentially unnecessarily > verbose, when "non-empty string" essentially implies it's up to the user to > determine what keys are valid and what are not, with the baseline > assumption that *any* can be used. > > I've played with a fair number of containers at this point, and, honestly, > I cannot think of *any* that had restrictions on characters. In a worst > case scenario, the lookup will fail. For containers with sets of reserved > characters, they can normalize before lookup and/or injection. > > Swapping containers is usually not something done lightly, and I would > expect that if an implementation has a more restrictive set of characters > allowed, that would be a consideration in the choice when switching. > > > I believe PSR-6's definition allows any UTF-8 character, so that would >> include pizza emoji. :-) However, if I'm trying to connect two containers >> (for delegation), and one uses a pizza emoji and the other only allows >> ASCII characters, then they're not actually compatible. (Or, god forbid, >> one tries to use Windows-1252 for some ungodly reason.) Or perhaps one is >> limited to only 5 character strings for some reason (stored in a database >> column)? Then passing in a longer string wouldn't work. >> >> PSR-6's requirement was simply "at leas a 64 character UTF-8 string, and >> these chars are reserved". If you don't want to reserve the same/any >> characters that's fine, but at least a character encoding and minimum legal >> length should be specified. >> >> --Larry Garfield >> >> >> On 11/03/2016 03:47 AM, David Négrier wrote: >> >> I agree with Matthieu. >> >> Specifying what legal characters are supported definitely belongs to >> another PSR (the one where we put things into the container). I'll propose >> a PR in container-interop/service-provider >> <https://github.com/container-interop/service-provider/> to define >> precisely the allowed identifiers. >> >> Unlike PSR-6, there is no "set" in this PSR, therefore no need to >> standardize the acceptable identifiers. For PSR-11, if the identifier >> passed is "🍕" (the pizza slice emoji) and the container does not support >> emoji identifiers (what a shame! :) ), the container should return a >> NotFoundException. >> >> David. >> >> >> >> Le mercredi 2 novembre 2016 22:49:33 UTC+1, Matthieu Napoli a écrit : >>> >>> Splitting of the main thread, quoting Larry: >>> >>> > The spec should specify what legal characters are for an entry >>> identifier, and what if any reserved characters there are. It should >>> also specify minimum supported key length and character sets, for >>> completeness. I recommend borrowing PSR-6's language here, which I >>> believe addresses this area well. Whether it uses the same reserved >>> character list or another one I don't feel strongly about. I would not >>> consider this a Review-breaking change. >>> >>> Why should we specify that? This is explicitly a "non-goal" of PSR-11: >>> https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#32-non-goals >>> >>> -- >> 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 php-fig+u...@googlegroups.com <javascript:>. >> To post to this group, send email to php...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/5fa24b40-1b48-4c0e-907b-3fc88cc965dc%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/5fa24b40-1b48-4c0e-907b-3fc88cc965dc%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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 php-fig+u...@googlegroups.com <javascript:>. >> To post to this group, send email to php...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/074d736b-f5b4-db27-765a-814de60387c7%40garfieldtech.com >> >> <https://groups.google.com/d/msgid/php-fig/074d736b-f5b4-db27-765a-814de60387c7%40garfieldtech.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Matthew Weier O'Phinney > mweiero...@gmail.com <javascript:> > https://mwop.net/ > -- 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/471a6868-f78a-40f7-a16b-212d64f6eaef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
