On Thu, Nov 3, 2016 at 9:41 AM, Larry Garfield <la...@garfieldtech.com> 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+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/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+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/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 mweierophin...@gmail.com 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/CAJp_myXaa5DJ3d0C2i-rqeL9x3KP22iax%3DW-KQ0-jfi9_qUS0w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
