Re: [REVIEW] PSR-11 Container Interface (Take 3)

On Mon, Jan 30, 2017 at 3:23 PM, Chuck Reeves wrote: > Hope it is not too late but I would like to have a quick talk about merging > containers. > > How would a user merge in containers? From what I hear it was going to be > by merging the configs. What if there is a

Re: [REVIEW] PSR-11 Container Interface (Take 3)

Hope it is not too late but I would like to have a quick talk about merging containers. How would a user merge in containers? From what I hear it was going to be by merging the configs. What if there is a container from a library that needs a specialized factory that is added when the

Re: [REVIEW] PSR-11 Container Interface (Take 3)

LGTM... On Jan 17, 2017 09:13, "Matthew Weier O'Phinney" wrote: > We are rebooting the PSR-11 review period again as of now; this marks > the third review period, and it will end at 11:59 UTC 29 Jan 2017, > with the prospect of holding a vote starting the following

Re: [REVIEW] PSR-11 Container Interface (Take 3)

> Are you suggesting that 2 different exceptions should be present? It seems that MissingDependencyException would mean that the $id service exists but cannot be created since that service depends on another service that is not present. Exactly. However, as it was discussed in the past, I

Re: [REVIEW] PSR-11 Container Interface (Take 3)

Are you suggesting that 2 different exceptions should be present? It seems that MissingDependencyException would mean that the $id service exists but cannot be created since that service depends on another service that is not present. My thoughts go to Zend\Db\Table\Gateway which needs a

[REVIEW] PSR-11 Container Interface (Take 3)

We are rebooting the PSR-11 review period again as of now; this marks the third review period, and it will end at 11:59 UTC 29 Jan 2017, with the prospect of holding a vote starting the following day. The only change since the previous review period is a clarification of the role of

Re: [REVIEW] PSR-11 Container Interface

> > > > 31st December: Latest date for any PSRs to start approval votes under > the old system > > 31st December: Final deadline for PSRs to have full working groups > formed with a CC sponsor > > 1st January: All votes and actions take place under new system; full > transition > > 31st

Re: [REVIEW] PSR-11 Container Interface

> > Yet, I'm really happy to discuss this issue if you think it is worthwhile, > but we have a strong deadline. If we change the way exceptions are handled, > we must do so before Tuesday, 17th because it is the last possible date for > a PSR to enter (again) a review phase, so please, give me

Re: [REVIEW] PSR-11 Container Interface

> Essentially, the try/catch block MUST be present. This is specifying > _internal implementation_, and, of more concern, specifying an > implementation based on try/catch which has significant performance > issues. Do I miss something or it can be implemented easier w/o try .. catch?

Re: [REVIEW] PSR-11 Container Interface

Note: If you're using a single + to indicate a second choice, then I'd have a single + on PR 1. --Larry Garfield On 01/16/2017 12:01 PM, David Négrier wrote: First of all, thanks a lot for being so quick to comment this issue. Let's summarize the expressed opinions. (I'll try to put a note

Re: [REVIEW] PSR-11 Container Interface

On 01/16/2017 10:15 AM, Matthieu Napoli wrote: Larry, Unsurprisingly I'd favor PR 3: Explicit exception. I'll be honest that I'm still very confused why there's so much resistance from the Editors on using exception types for what they're supposed to be used for. Different error condition,

Re: [REVIEW] PSR-11 Container Interface

First of all, thanks a lot for being so quick to comment this issue. Let's summarize the expressed opinions. (I'll try to put a note from -- to ++ based on your textual feedback, excuse me if I'm not 100% accurate). --|--|--|--- Name

Re: [REVIEW] PSR-11 Container Interface

On Mon, Jan 16, 2017 at 10:01 AM, Daniel Plainview wrote: >> If PR >> 1 is used, we end up with a call to get() raising a >> NotFoundExceptionInterface instance if either of the following >> conditions is true: >> - One of the dependencies of $id does not exist. > > PR 1

Re: [REVIEW] PSR-11 Container Interface

Larry, > Unsurprisingly I'd favor PR 3: Explicit exception. > > I'll be honest that I'm still very confused why there's so much > resistance from the Editors on using exception types for what they're > supposed to be used for. Different error condition, different > exception. In 20

Re: [REVIEW] PSR-11 Container Interface

> If PR > 1 is used, we end up with a call to get() raising a > NotFoundExceptionInterface instance if either of the following > conditions is true: > - One of the dependencies of $id does not exist. PR 1 doesn't bubble out NotFoundException in this case. PR 2 acts like you described,

Re: [REVIEW] PSR-11 Container Interface

On Mon, Jan 16, 2017 at 8:41 AM, Larry Garfield wrote: > On 01/16/2017 04:58 AM, David Négrier wrote: > > Ok, we have 3 options, and one day to decide which to choose. > > In order to ease the choice, I opened 3 PRs on Github. > > I'll ask everyone involved to give

Re: [REVIEW] PSR-11 Container Interface

> Different error condition, different exception. In 20 years of writing code I cannot recall ever saying "damn, this error message is too precise and specific". @Larry nobody says the opposite, we all agree on this one. Of course, it must be different exception with nice and precise class

Re: [REVIEW] PSR-11 Container Interface

I'm good with #3, as it looks like a useful addition that should alleviate some concerns. On Jan 16, 2017 04:58, "David Négrier" wrote: > Ok, we have 3 options, and one day to decide which to choose. > > In order to ease the choice, I opened 3 PRs on Github. > > I'll

Re: [REVIEW] PSR-11 Container Interface

On 01/16/2017 04:58 AM, David Négrier wrote: Ok, we have 3 options, and one day to decide which to choose. In order to ease the choice, I opened 3 PRs on Github. I'll ask everyone involved to give feedback on the 3 PRs. Let me present them briefly. *PR 1: Status Quo:

Re: [REVIEW] PSR-11 Container Interface

On 13/01/2017 16:48, Fabien Potencier wrote: I do understand that the group spent a lot of time trying to figure out something that works for most projects, and I really appreciate their work, but **can we admit that the result is deceptive and not useful enough to standardize?** I disagree.

Re: [REVIEW] PSR-11 Container Interface

Ok, we have 3 options, and one day to decide which to choose. In order to ease the choice, I opened 3 PRs on Github. I'll ask everyone involved to give feedback on the 3 PRs. Let me present them briefly. *PR 1: Status Quo: NotFoundExceptionInterface CANNOT bubble up, but we do not standardize

Re: [REVIEW] PSR-11 Container Interface

I really like this proposal y Nikolas, especially the part about the SHOULD NOT use the exception for control flow... Il giorno domenica 15 gennaio 2017 08:48:15 UTC+1, Nicolas Grekas ha scritto: > > Hi David, > > let's drop any distinction between "entry not found" and "dependency >>

Re: [REVIEW] PSR-11 Container Interface

> Btw, don't we miss an "InvalidArgumentException", to be thrown when the arg passed to has/get is not a string? It has as much value as documenting `@throws \Error` (compare it with scalar type hints). On Sunday, January 15, 2017 at 5:40:10 PM UTC+3, Nicolas Grekas wrote: > > > > Regarding

Re: [REVIEW] PSR-11 Container Interface

Regarding you last suggestion I'm having trouble seeing the difference with > the current version of the spec, could you pinpoint it more explicitly? > There are two differences: The most important one is that the *wording* of the PSR need to be as clear as possible. Finding a clear way to

Re: [REVIEW] PSR-11 Container Interface

Hi David, let's drop any distinction between "entry not found" and "dependency > missing". We don't need this because users of containers can anyway figure > that out. > I'd like to propose the opposite alternative. That's no a rebuttal of yours and I sincerely thank you for being so open to

Re: [REVIEW] PSR-11 Container Interface

Hey people, This might sound as a surprise, but thanks to Nicolas' and Matthew's comments, I came up with yet another solution that was never really discussed. PR (WIP) is here: https://github.com/php-fig/fig-standards/pull/869 Nicolas and Matthew pointed a few things that were never said

Re: [REVIEW] PSR-11 Container Interface

> My main issue is that the current text says "In situation A, do X. In situation B, do any capital letter that is not A." That is a construction I simply cannot get behind in any specification of any sort, as it is simply too vague and begs for inconsistent error handling There is no such

Re: [REVIEW] PSR-11 Container Interface

On 01/14/2017 11:37 AM, David Négrier wrote: *snip* So my code was looking like this: try { $service = $container->get($id); } catch (NotFoundExceptionInterface $e) { if ($id === $e->getMissingIdentifier()) { // Display an error message to the user saying the service does not

Re: [REVIEW] PSR-11 Container Interface

> > > the NotFoundExceptionInterface triggered by the inner get call SHOULD > NOT bubble out. > > > > Fortunately enough, this is only a "SHOULD NOT", so we can do as we want > and still be compliant. Because I agree with Larry here, the wording is so > abstract that in practice it hardly

Re: [REVIEW] PSR-11 Container Interface

The parser does not look far enough ahead. It sees the text of the heading that follows it, and thinks that text is a part of the list (list items with blank lines in are a valid syntax for lists with multi-paragraph contents). It does not spot the "--" that follows the heading text

Re: [REVIEW] PSR-11 Container Interface

PR 866 https://github.com/php-fig/fig-standards/pull/866 fixes this formatting issue. It doesn't fix the obvious bug in github causing it, but it uses the alternate markdown syntax that avoids it. -- Jason On Thursday, 12 January 2017 23:08:10 UTC, Larry Garfield wrote: > > ... > There's a

Re: [REVIEW] PSR-11 Container Interface

> Larry just gave one: better error handling. You can use this argument for any exception. Furthermore, I don't think it is correct to handle such "error" at this stage. You don't need to catch *exactly* this exception (MissingDependency/Misconfigured), because you can't auto-fix it at runtime.

Re: [REVIEW] PSR-11 Container Interface

> > That basically means a simple closure would do the job equally well, isn't? > Yes, for such a basic use-case like mine, a Clousure would be also sufficient but type-hinting would be sacrified when doing so (I mean it is more difficult to document the Closure's signature). Furthermore, if

Re: [REVIEW] PSR-11 Container Interface

Hi, all! I'm going to respond to a couple different posts in this thread at once, quoting the bits I want to respond to. On 2017-01-13 Nicolas Grekas wrote: > > the exception part is really where things start to look like a zoo. Because > we have many animals there in the "Exception" namespace,

Re: [REVIEW] PSR-11 Container Interface

I don't think that the fact that PSR-11 is limited to a get is a reason to worry. In my opinion we should see this standard as a stepping stone for everything about containers. Basically, I foresee in the feature various other container-related PSR, and PSR-11 will just be a prerequisite,

Re: [REVIEW] PSR-11 Container Interface

Thanks for your answer Máté Without ContainerInterface, I should have used an Adapter (e.g. the > Acclimate package) or I could have hardwired a specific container into my > framework to achieve so (I would have hated both solutions). > It looks like the only feature of PSR11 that this is using

Re: [REVIEW] PSR-11 Container Interface

Hi all, for the shake of trying (meaning I come here with no announcement at all that this is going to be merged), here is what this currently looks like on the Symfony container: https://github.com/symfony/symfony/pull/21265 the exception part is really where things start to look like a zoo.

Re: [REVIEW] PSR-11 Container Interface

On the exceptions, that language just says to me that in my get() method, I have a try/catch around any deeper get() calls, and thus my outer get is going to catch *anything* and wrap it with the package-level exception before throwing it. It's not really about the source exception being

Re: [REVIEW] PSR-11 Container Interface

Late in the week, I know, but this is when I had time. :-( One: " A call to get can trigger additional calls to get (to fetch the dependencies). If one of those dependencies is missing, the NotFoundExceptionInterface triggered by the inner get call SHOULD NOT bubble out. Instead, it should

Re: [REVIEW] PSR-11 Container Interface

Hey folks, Before the review ends, I'd like to update the list of contributors in the META document. I'm proposing a PR to add Larry Garfield to the list of contributors as he made major feedback and contributed a PR to PSR-11: - https://github.com/php-fig/fig-standards/pull/864 If any of

Re: [REVIEW] PSR-11 Container Interface

Hey folks, To avoid the usual insurgence of concerns and critiques that only happen when an acceptance vote starts, and which to be really addressed would require to first cancel the vote, then push back the spec to draft, then start reviewing again, I would urge anybody who thinks that the this

Re: [REVIEW] PSR-11 Container Interface

LGTM from PEAR... On Dec 31, 2016 14:57, "Matthew Weier O'Phinney" wrote: > Greetings, on this last day of 2016! (For some of you, it's already 2017!) > > I'm rebooting the REVIEW period for PSR-11 as of now; review will end > at 11:59 on 13 January 2017, with the

[REVIEW] PSR-11 Container Interface

Greetings, on this last day of 2016! (For some of you, it's already 2017!) I'm rebooting the REVIEW period for PSR-11 as of now; review will end at 11:59 on 13 January 2017, with the possibility of starting a vote under the existing FIG 2.0 by-laws possible immediately thereafter. The changes

Re: [REVIEW] PSR-11 Container Interface

Hi Chuck, good point I've opened a PR to fix that: https://github.com/php-fig/fig-standards/pull/832 For those not aware I just wanted to point out that topics in this thread are being discussed in separate threads on the mailing list. That helps to keep up with each discussion. If a topic was

Re: [REVIEW] PSR-11 Container Interface

Small point: should the has() section in 1.1 say that the entry identifier MUST be a string, similar to how it does so for get()? On Oct 26, 2016 8:28 AM, "Matthew Weier O'Phinney" wrote: > Hello, everyone! > > PSR-11, Container Interface (née container-interop) has

Re: [REVIEW] PSR-11 Container Interface

Hi Larry, Hi Pedro, Wooh! That's a lot of comments. Thanks to both of you. There are really many different issues that need to be addressed in those review (especially in Larry's posts). I'll not respond directly in this thread (otherwise it will be hard to follow each issue individually.

Re: [REVIEW] PSR-11 Container Interface

Hi, David. Thank you for your response. Let me address some points. > Out of the box, even if you can't put things into the container, PSR-11 is still useful. I still have a lot of issues trying to think of use cases where I don't need to know if the objects I'm retrieving are shared

Re: [REVIEW] PSR-11 Container Interface

Hi Pedro, Interestingly enough, I think we completly agree. If you look at your sentence, you say: "*A container should "contain" services, not create services on each call, return them and then discard them.*" Notice that you used the word "should", not "must". This is exactly what the PSR

Re: [REVIEW] PSR-11 Container Interface

A container, like the name says, should "contain" services, not create services on each call, return them and then discard them. 2016-10-27 11:04 GMT-02:00 Pedro Cordeiro : > > > Just like @mwop, I've never had an issue with this behaviour. > > Actually, I'd be

Re: [REVIEW] PSR-11 Container Interface

> Just like @mwop, I've never had an issue with this behaviour. > Actually, I'd be interested in knowing what is your concern with this? Do you have an actual use case in mind that absolutely requires the container to always return the same value for all entries? A simple example is an event

Re: [REVIEW] PSR-11 Container Interface

Hey Hari! You say: > Basically this is the text : > > Two successive calls to get with the same identifier SHOULD return the same > value. However, depending on the implementor design and/or user > configuration, different values might be returned, so user SHOULD NOT rely > on getting the same

Re: [REVIEW] PSR-11 Container Interface

Hi @mwop, Thank you for your comments. I am writing inline for I don't miss anything. > The only concern to me is > > https://github.com/container-interop/container-interop/issues/69 > regarding > > return value of get . > > > > Basically this is the text : > > > > Two successive calls to get

Re: [REVIEW] PSR-11 Container Interface

On Wed, Oct 26, 2016 at 8:58 AM, Stephan Hochdörfer wrote: > Just wondering which PHP version are we targeting with the PSR? Or to be > more precise: Shouldn't we add parameter type hints and return type > declarations where possible? As Andreas already pointed out, it

Re: [REVIEW] PSR-11 Container Interface

Hi all. Am 26.10.16 um 15:58 schrieb Stephan Hochdörfer: > Just wondering which PHP version are we targeting with the PSR? Or to be > more precise: Shouldn't we add parameter type hints and return type > declarations where possible? As PHP5.6 is supposed to be supported until Dec. 2018

Re: [REVIEW] PSR-11 Container Interface

Hi, The only concern to me is https://github.com/container-interop/container-interop/issues/69 regarding return value of get . Basically this is the text : Two successive calls to get with the same identifier SHOULD return the same value. However, depending on the implementor design and/or user