Sorry, reading that back (which I should have done before posting) I realise I worded that incredibly badly. Let me rephrase.
> 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. This is surely an implementation detail. If my container wants to disallow "." in valid service names, it should absolutely be able to do so. This would limit the interoperability in that I wouldn't be able to drop this container into my project without any changes if I used "." in my key names, but this is entirely fair. Interoperability should be about minimum effort, not no effort. I've been able to change containers very easily using the existing container-interop which places no such boundaries on key names, as with any change I had to choose my new container wisely in order to ensure compatibility. I'm worried because PSR-11 will be attempting to replace an already widely adopted standard, and any changes from that standard should be thought about very carefully. At the moment it would be trivial to replace container-interop with PSR-11, indeed, it may be possible to use both interfaces, but these kind of changes that (admittedly in my opinion) don't bring much to the table scare the hell out of me with regards to adoption. G On Monday, 14 November 2016 10:22:03 UTC+1, GeeH wrote: > > 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/8f1f9936-a771-4a13-b560-42cefaf295f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
