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. > 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. 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. 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. > 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. Matthieu -- 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/etPan.58282f5c.4f16cf07.2fe%40mnapoli.fr. For more options, visit https://groups.google.com/d/optout.
