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
<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
<mailto:php-fig+unsubscr...@googlegroups.com>.
To post to this group, send email to php-fig@googlegroups.com
<mailto: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.
For more options, visit https://groups.google.com/d/optout.
