> 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.
The latter should break when setting the entries, not when fetching them. Restricting what entries can be fetched doesn't make much sense. Restricting what entries can be configured do. What if I add a pizza-emoji service, does it make any sense disallowing fetching that service? I agree with validating this when we are discussing setting entries. For now, I'd consider this out of scope. Em quinta-feira, 3 de novembro de 2016 12:41:26 UTC-2, Larry Garfield escreveu: > > 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 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+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/edc0ee77-872a-4caa-a78a-998f311e7cf4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
