On 11/13/2016 03:16 AM, Matthieu Napoli wrote:
I filed a PR here with my recommendation:
https://github.com/php-fig/fig-standards/pull/837
Thanks.
--Larry Garfield
Thanks, I feel it's easier to discuss that now:
> An entry identifier is a string of at least one character that
uniquely identifies an item within a container.
Sounds good to me, an empty string would be, IMO, problematic. And it
wouldn't surprise me that many containers would throw an exception
with an empty identifier (I even wonder if PHP-DI does it :p).
Is "uniquely" an issue? With aliases (for example) 2 IDs can identify
the same entry.
I read uniquely to mean the same key string always refers to the same
service, not that a service is represented by only one string. Viz,
"foo" and "bar" can both give me the database object, but "foo" won't
sometimes give me a DB object and other times a 3rd party authentication
key string.
> Implementing libraries MUST support identifiers 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.
That list of characters doesn't include \ which is used by all
autowiring containers (where the ID is the class name). This is IMO an
example of a problem with enumerating all allowed characters: we are
bound to miss some. Same for "-" which is currently not allowed. What
if someone wants to name a service with an emoji? (for whatever reasons).
And I understand you said you wanted to place a "lower bound", but if
some containers don't support "\" then it's a big issue with
interoperability.
Adding more characters to the minimum list is fine by me. I started
with the basic identifier set used by PSR-6 and others but expanding it
is fine.
If we want to expand it as far as "any legal UTF-8 character" as John
Flatness suggests that's an option, although I'm slightly skeptical
there. While we can talk about the hypothetical pizza emoji service, I
would in all honesty immediately reject any patch to a project of mine
that tried to do so. I can't say I've ever seen a service name myself
that was more than the "Standard identifier set" (as above).
The more practical question would be the use of non-latin languages.
I've never worked in a codebase that was written in Hebrew, Arabic,
Cyrillic, or Kanji, and I'm not sure there are any significant projects
that do so even though the language would, technically, support it.
(That may be simply my own ignorance talking; I really have no idea if
such projects are a thing.)
Another problem I see is the max length: why such a maximum? It
doesn't seem very high either, though of course in most cases it would
be fine.
Maximum? It's not a maximum. I have no expectation that any
implementation would realistically support a PHP_MAX_INT number of
characters in an identifier; if for no other reason than memory limits
or constraints in an underlying file system. An implementation backed
by a datastore that requires specifying a length (such as SQL) is going
to have to set a max length of something. (To be fair an SQL-backed
container is an unlikely implementation, but given how generic the spec
currently reads I would argue it's more realistic than a pizza emoji
service.) 64 is suggested as the minimum size an implementation must
support. It could have a cap of 128, 512, or 16 million characters if
it wants, but 12 would not be legal.
I have zero objection to bumping that number higher. 64 is simply what
I borrowed from PSR-6 as a starting point.
I would suggest something like that instead:
> [An entry identifier is a string of at least one character that
uniquely identifies an item within a container.] It can consist of any
characters in UTF-8 encoding.
> Implementing libraries MAY support additional characters and
encodings or longer lengths, but must support at least that minimum.
IMO we can get rid of this sentence because this is exactly the Liskov
Substitution Principle and we removed the sentence about extra
optional parameters for "get()" for the same reason.
I disagree, in the interest of clarity. Especially given how easily
people mistook my intent for setting maximums on possible identifiers,
not minimums, explicitly saying "more than this is completely OK,
really!" makes sense here. In the case of get(), it's arguably a bad
but not forbidden idea to add proprietary parameters. In the case of
the identifier, supporting more variety than the bare minimum is a very
good thing.
> An entry identifier is an opaque string, so callers SHOULD NOT
assume that the structure of the string caries any semantic meaning.
After thinking about it I've switched from "I don't see the point" to
"it's a good idea": some containers use for example "." as a
separator/way to namespace entries, it's good to clear up any
potential confusion here: it's just a string, conventions and
structure can come later but they are out of scope of PSR-11.
That's the reason PSR-6 reserved some characters; on anticipation of, in
the future, using some of them for more advanced functionality like
namespacing. I could see an argument either way for PSR-11's case,
either reserving characters for that or deliberately not reserving
characters but noting that there is no spec-defined meaning. The
question becomes IF a follow-up spec defines a meaning for the {}
characters (for instance), and an existing implementation has already
decided to make it mean something, then what?
Not a clear-cut answer, but a worthwhile question to chew on.
--Larry Garfield
--
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/088c7082-b4df-fcff-2880-ffac82eb6a2a%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
