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
<https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#32-non-goals>
