To reiterate what I said before: I am mostly suggesting a *lower bound*,
not *upper bound*. As PSR-6 states:
" A string of at least one character that uniquely identifies a cached
item. Implementing libraries MUST support keys consisting of the
characters A-Z, a-z, 0-9, _, and . in any order in UTF-8 encoding and a
length of up to 64 characters. Implementing libraries MAY support
additional characters and encodings or longer lengths, but must support
at least that minimum."
And then it also has 8 reserved characters. With the exception of the
reserved punctuation marks (which as I said are highly debatable for
PSR-11), it does not limit at all the keys that can be used; it's
exactly the opposite.
Vis, I am in no way suggesting the spec should say "UTF-32 characters
are illegal." I am saying the spec should say "if all you support is
basic ASCII, that's not enough."
I admit to being quite confused as to how this is a controversial
suggestion, and why people keep misinterpreting it as suggesting to
heavily restrict legal key values.
--Larry Garfield
On 11/11/2016 05:02 AM, Gary Hockin wrote:
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>
--
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
<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
<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
<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/471a6868-f78a-40f7-a16b-212d64f6eaef%40googlegroups.com
<https://groups.google.com/d/msgid/php-fig/471a6868-f78a-40f7-a16b-212d64f6eaef%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/747f1318-fcad-54c5-15db-c056f500bbfa%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
