Re: [PSR-16] Question about `set` and `setMultiple` methods on PSR-16

Hi, Paul! Thanks for replying. I'll reply inline. > The PSR-16 standard says that in the event of an invalid passed TTL then this is the specific class typehint that will be thrown. It doesn't, actually. It only says an InvalidArgumentException MUST be thrown if the provided $key is not a

[PSR-16] Question about `set` and `setMultiple` methods on PSR-16

Hi, very quick question. Couldn't find anything on either the spec or the meta doc. The `set` and `setMultiple` methods define that an `InvalidArgumentException` MUST be thrown if $key is not a legal string value. However, shouldn't these methods specify that an InvalidArgumentException MUST

Re: [PSR-11] Review: should the container ALWAYS return the same instance?

not a big issue, then let's move on. I do feel like it's a big issue, though. Em terça-feira, 8 de novembro de 2016 17:54:08 UTC-2, Matthew Weier O'Phinney escreveu: > > > > On Tue, Nov 8, 2016 at 6:55 AM, Pedro Cordeiro <pedro.c...@sympla.com.br > > wrote: > >> H

Re: [PSR-11] Review: should the container ALWAYS return the same instance?

you see, you can build some tools to wrap a PSR-11 interface. You will >> not use it directly for all cases but probably there won't be so many cases >> where you have non-stateless services if you try to do it. >> This is how I use the container-interop interface and it's

Re: [PSR-11] Review: should the container ALWAYS return the same instance?

And now that I think about it, solution 3 works best for me. It'd forbid having something like I described on the previous email (ContainerFactory), because there'd need to be an option to fetch shared instances. Em sexta-feira, 4 de novembro de 2016 14:19:03 UTC-2, Pedro Cordeiro escreveu

Re: [PSR-11] Review: should the container ALWAYS return the same instance?

the event dispatcher being a > non-shared service. This would definitely be an issue. I just disagree that > it is a concern with PSR-11. It is a concern with either the user > configuring the container, or the next PSR to come that defines how we put > things into a container. > &

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] Review: should the container ALWAYS return the same instance?

> The typical use case for ContainerInterface is to allow a consumer (like a router) to be "container agnostic". I completely agree. I can't think of a use case where a router would depend on having either shared instances or exclusive instances of a controller, so I'll change this example a

Re: [REVIEW] PSR-11 Container Interface

> > Yes, a container *can* in some cases return new services for some > entries. But I'm still capable of writing a service-provider PSR that > dictates that consuming containers MUST return shared services for services > contained in my service provider. Both statements are

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 <pedro.corde...@sympla.com.br>: > > > Just like @mwop, I've never had an issue with this beh

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

[PSR-11] Question about PSR-11

I tried searching but couldn't find the reason PSR-11 doesn't have a `register`, `add` or similar method to register a new service in the container. I'm not sure if I misunderstood something, but it looks like I'll still have to create a new contract wrapper around PSR-11 to define how to

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

> I will say that it's too bad this discussion period was wasted It wasn't wasted as much as it was hijacked by Paul. > Is that what everyone who voted +1 on the secretary role understood the case to be? It doesn't matter, because FIG 3.0 doesn't change the bylaws regarding a secretary's

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

Paul, the role of a secretary is well described here, as I'm sure you are aware: http://www.php-fig.org/bylaws/membership/#fig-secretary. Em segunda-feira, 12 de setembro de 2016 13:22:28 UTC-3, pmjones escreveu: > > > > On Sep 12, 2016, at 10:56, Michael Cullum >

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

This is a huge breaking change. Just imagine how many CI servers are going to explode due to sudden PSR2 violations when running phpcs. If I had a vote here, I'd vote -1, because: 1) Most projects can't refactor their APIs entirely due to SemVer (and wouldn't even if they could, just to adhere