Re: [PSR-11] Characters allowed in service IDs

Per the open meeting at php[world] I have updated the PR again to remove mention of the character encoding. --Larry Garfield On 11/18/2016 04:56 PM, Daniel Plainview wrote: > In the eyes of interoperability and standard, unless there's a strong and compelling reason to add "UTF-8" to the

Re: [PSR-11] Characters allowed in service IDs

After discussion with Larry last night I suggested an edit that states that all containers should support a valid PHP string in UTF-8 format. I made that suggestion on the pull request. G On Tuesday, 15 November 2016 05:42:42 UTC-5, Alessandro Pellizzari wrote: > > On 14/11/2016 17:50, David

Re: [PSR-11] Characters allowed in service IDs

Hi, I kind of agree with @GeeH here. > 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. If I read this sentence correctly, this means that one should be able to *set* in a

Re: [PSR-11] Characters allowed in service IDs

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

Re: [PSR-11] Characters allowed in service IDs

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

Re: [PSR-11] Characters allowed in service IDs

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

Re: [PSR-11] Characters allowed in service IDs

Let me preface this comment by saying that I understand fully that this proposal is setting a floor on allowable characters, not a ceiling. That being said, I still don't understand the purpose behind specifying it as proposed: "MUST support identifiers consisting of the characters A-Z, a-z,

Re: [PSR-11] Characters allowed in service IDs

I filed a PR here with my recommendation: https://github.com/php-fig/fig-standards/pull/837 Thanks. --Larry Garfield On 11/11/2016 12:43 PM, Matthieu Napoli wrote: Hi Larry, you are right, let's move forward: what sentence do you suggest we should add to the spec? Matthieu Le 11 novembre

Re: [PSR-11] Characters allowed in service IDs

I hear you Larry, but I still disagree and say this is an implementation detail. G On Friday, November 11, 2016 at 4:48:58 PM UTC, Larry Garfield wrote: > > To reiterate what I said before: I am mostly suggesting a *lower bound*, > not *upper bound*. As PSR-6 states: > > " A string of at

Re: [PSR-11] Characters allowed in service IDs

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

Re: [PSR-11] Characters allowed in service IDs

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

Re: [PSR-11] Characters allowed in service IDs

On Thu, Nov 3, 2016 at 9:41 AM, Larry Garfield 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

Re: [PSR-11] Characters allowed in service IDs

> 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. The latter should break when setting the entries, not when fetching them. Restricting what entries can be fetched

Re: [PSR-11] Characters allowed in service IDs

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,

Re: [PSR-11] Characters allowed in service IDs

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 to define precisely the