I'm worried by this suggested change. We tried doing something similar in Zend ServiceManager 2.0 and had to wait until 3.0 to be able to fix the mistake. I don't understand why any legal string in PHP can't be a container key. Limiting the range of characters in a legal key is an implementation detail. I realise I'm repeating myself (again), but it's important to make the point that this is a mistake we had to live with for the entire duration of ZF2 until we could introduce a breaking change in ZF3.
G On Monday, 14 November 2016 01:28:52 UTC+1, Larry Garfield wrote: > > 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/53f00ca9-0aef-4045-8e4b-bfe25b0fdc69%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
