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

[Pedro Cordeiro]

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 legal string. There is no reference to 
what it SHOULD/MUST do in case of an invalid TTL.

> in the context of if it only wants INT or DateInterval only, that's not 
for us to decide

In the context of interoperability, I believe it should be. By allowing 
each implementation to decide if they will work with ONLY int, ONLY 
\DateInterval or ONLY something else whatsoever, we end up with 
incompatible implementations. I find it odd that the spec implies that 
**normally** TTLs are ints or dateintervals, yet enforces neither and 
allows for each implementation to decide what kind of data it will get.

Since PSR-16 has been accepted, I'm not sure how much it can change, 
anyway. At this point, I don't think enforcing a minimum would break any of 
the very few implementations out there. But if I had the choice (and I 
deeply regret not seeing this before the vote), I'd have the spec force 
implementations to allow at least ints and dateintervals, while giving room 
for them to implement any other types they wish so.

Just out of curiosity, is it possible to ammend a PSR once it's live?


> Invalid is primarily decided by the backend that is being used at the 
> time. 
>
> PSR-16 doesn't define what is or it not a valid TTL (yes we have said INT 
> or DateInterval), however in the context of if it only wants INT or 
> DateInterval only, that's not for us to decide. 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. Does this make more sense now?
>
> Many thanks,
> Paul
>  
>
>>
>> -- 
>> 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+u...@googlegroups.com .
>> To post to this group, send email to php...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/dd2e5055-a45e-4cd9-afb7-196769e588fc%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/7fc0579e-42f4-4ad6-9ce1-1c69bfcc66e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Pedro Cordeiro]

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 also be thrown if the provided $ttl is 
neither an integer or a \DateInterval? The spec says a TTL is **normally** 
defined by either an amount of seconds or a \DateInterval object. However, 
if we let implementations dictate what TTLs can be, we can end up with 
incompatible implementations.

Implementation A only allows integers, where B only allows DateIntervals. C 
only allows some custom wrapper for a TTL value. A, B and C are now 
incompatible amongst themselves, and we have less INTEROPERABILITY (which 
is kind of the point of this standard).

Was this discussed?

-- 
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/dd2e5055-a45e-4cd9-afb7-196769e588fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Pedro Cordeiro]

Hi, Matthew! Thanks for replying :)

Larry and I presented a few cases where the framework relies on its 
components having a shared instance, instead of exclusive ones. Every 
framework component that fetches services that handles connections, IO 
sockets, in-memory caches, and others HAVE to be given shared instances. 
Being fed new (empty) in-memory caches every time is crazy, right? :) If 
you could address how we can deal with these cases with factory-only 
containers, maybe it could be clearer to me.

I don't really agree that most services are only fetched once by the 
framework -- an event dispatcher (that traditionally has an in-memory 
registry of listeners that must be shared) could be fetched various times 
by various different components - to register new listeners or to simply 
dispatch events. It would depend on the framework here. Maybe a 
microframework tends to fetch less, but a fullstack framework could really 
differ in that aspect.

Like I said before, I would agree that it's an application/configuration 
issue if all containers were interoperable on a behavior level. If the user 
had misconfigured a container to act as factory for a specific service, 
where it should be retrieving shared instances, ok, that's a bug, not this 
PSR's fault. However, once we decide to allow factory-only containers, we 
define that there is no way to configure these containers properly for 
components that need shared instances (such as the ones I mentioned 
previously). Hence, we have a compatibility issue.

Again, choosing the right containers for my use is not a 
configuration/application issue. PSR-11's goal SHOULD be container 
interoperability. Which means containers should agree on a minimum behavior 
to be interoperable. If we need to code to specific implementations, than a 
standard is not needed at all.

I won't dwell any more into this issue, because I feel like I'm bashing the 
same key over and over again. I feel like I've said all I had to say in 
that aspect, and I only have the best intentions in mind for this PSR. If 
you all feel like it's 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:
>
>> Hi, Matthew!
>>
>> I understand everything you said. About the configuration responsibility, 
>> this PSR's scope and the fact that it's coherent to have non-shared 
>> services in some contexts. I never disagreed with any of that.
>>
>> I'll try to be more objective here.
>>
>> Given two containers: 
>>
>> a) "ContainerShared", that implements PSR-11 and ONLY returns shared 
>> instances, no option to configure non-shared services;
>> b) "ContainerFactory", that implements PSR-11 and ONLY returns non-shared 
>> instances, acts as a factory always.
>>
>> Do you agree that:
>>
>> 1) These implementations are perfectly fine PSR-11 implementations, as 
>> it's phrased right now?
>> 2) These implementations are incompatible between themselves for pretty 
>> much every use case, including zend-expressive, that is currently the most 
>> successful case of container interoperability?
>> 3) The incompatibility between these two containers is not an 
>> application/configuration issue, but plain lack of interoperability between 
>> them?
>>
>> If you agree with (1), (2) and (3), the final question that stands is: is 
>> it still OK to have container implementations that are NOT interoperable 
>> implementing an interoperability standard?
>>
>
> I don't agree with your assessment at all.
>
> I agree with point 1. I don't agree with either point 2 or point 3.
>
> In the majority of use cases I've encountered, the workflow goes something 
> like this:
>
> - Application composes a container.
> - Application does some sort of request routing to determine what service 
> to dispatch
> - Application pulls that service from the container and dispatches it
>
> This means that, regarding point 2, whether or not instances are shared is 
> typically moot. They are pulled from the container generally once, and once 
> only, in any given request. (Yes, there are times when multiple retrieval 
> may happen, particularly in large, event-based applications where multiple 
> listeners may use the same services.)
>
> However, this leads to point 3: it's absolutely an 
> application/configuration issue. You need to choose the container that 
> suits your application needs and configure it accordingly. The PSR-11 
> specification is only around *retrieving* services. It is specifically not 
> detailing how those services a

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

[Pedro Cordeiro]

 services (like Mouf or Aura.DI).
>
> Those containers are valid. Yes, they are "exotic", but we need to allow 
> exotic containers. IMO, they can be useful, especially when composed with 
> other containers.
>
> David.
>
>
> Le mardi 8 novembre 2016 16:02:50 UTC+1, Alexandru Pătrănescu a écrit :
>>
>> Hi Pedro,
>>
>> You articulated your problem well. Thanks.
>>
>> If you have a need to use a container so that it must return a shared or 
>> new instance than using the PSR-11 interface directly is not a solution.
>> Just as everyone said, PSR-11 is not addressing this problem.
>>
>> I said this another time in another thread:
>>
>> Having in mind the fact that you can't rely on obtaining a shared/new 
>> instance from the container, can you still use the PSR-11 interface?
>> My answer is yes, considering some practiced that people might say are 
>> good practices anyway:
>>
>> Use the container to inject stateless services only.
>> Use as much as possible only stateless services so that you will need 
>> only one instance of it in a php process.
>> You should separate state: value objects should be different class than 
>> service objects. Value object keep state, service objects execute logic 
>> using state as state as input/output.
>>
>> If you really need to have a service with state, don't inject it directly 
>> but inject the stateless service object that can give you the instance you 
>> need. That is a factory in case you always need to create a new instance or 
>> is a registry in case you need a multiton pattern or a singletons wrapper 
>> in case you really need to be sure you are using the same instance like for 
>> an event manager.
>>
>> So 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 working.
>> Anyway, you should build your classes agnostics of PSR-11. Only the 
>> "application" classes will use it to wire things up.
>>
>> Hope I was helpful with my point of view.
>>
>> Regards,
>> Alex
>>
>>
>> On Tue, Nov 8, 2016 at 2:55 PM, Pedro Cordeiro <pedro.c...@sympla.com.br> 
>> wrote:
>>
>>> Hi, Matthew!
>>>
>>> I understand everything you said. About the configuration 
>>> responsibility, this PSR's scope and the fact that it's coherent to have 
>>> non-shared services in some contexts. I never disagreed with any of that.
>>>
>>> I'll try to be more objective here.
>>>
>>> Given two containers: 
>>>
>>> a) "ContainerShared", that implements PSR-11 and ONLY returns shared 
>>> instances, no option to configure non-shared services;
>>> b) "ContainerFactory", that implements PSR-11 and ONLY returns 
>>> non-shared instances, acts as a factory always.
>>>
>>> Do you agree that:
>>>
>>> 1) These implementations are perfectly fine PSR-11 implementations, as 
>>> it's phrased right now?
>>> 2) These implementations are incompatible between themselves for pretty 
>>> much every use case, including zend-expressive, that is currently the most 
>>> successful case of container interoperability?
>>> 3) The incompatibility between these two containers is not an 
>>> application/configuration issue, but plain lack of interoperability between 
>>> them?
>>>
>>> If you agree with (1), (2) and (3), the final question that stands is: 
>>> is it still OK to have container implementations that are NOT interoperable 
>>> implementing an interoperability standard?
>>>
>>> I understand zend-servicemanager is a coherent implementation, that 
>>> allows for both shared and non-shared services, and that configuring which 
>>> services are shared is up to the application. I don't disagree.
>>> I understand that most current container implementations allow for both 
>>> kinds of services, shared and non-shared, and that it'd be up to the 
>>> application to configure which is which. I don't disagree.
>>>
>>> But certain implementations (as presented above) could still be 100% 
>>> incompatible for its consumers - not because *I*, the application 
>>> developer, configured something wrong (a bug), but because the *CONSUMING* 
>>> standard (PSR-11) simply allows for non-interoperable container 
&g

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

[Pedro Cordeiro]

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:
>
> Hi, David. 
>
> Thank you again for your response.
>
> I understand your point of view. You don't think there is anything the ORM 
> should do to prevent fetching a non-shared instance, because that would be 
> the responsibility of the application. I kind of agree, to a limited scope.
>
> But if you allow me to press on this issue just a little longer... it 
> still doesn't change the fact that I can still have two different 
> containers: ContainerShared, that only configures/fetches shared services, 
> and ContainerFactory, that only fetches new instances. They would both be 
> PSR-11 compliant, and still, incompatible for most cases. And then, it 
> wouldn't be a configuration issue (a bug) on the application end, it would 
> be a component incompatibility - which kind of defeats the point of having 
> a interoperability standard. It'd still be a little odd saying something 
> like "this ORM can be used with PSR-11 compatible containers, except for 
> containers that don't have the option to configure shared services (like 
> ContainerFactory)".
>
> Choosing a standardized component is not a configuration bug, right? 
> Should we let two PSR-11 implementations be incompatible for many (if not 
> most) cases, in the name of backwards compatibility (with containers that 
> still don't extend PSR-11)?
>
> You tell me this concern is out of scope. I don't disagree. I'm just 
> saying that, IMO, the current scope is not enough to assure two different 
> implementations are actually compatible - and thus, interoperable, which is 
> kind of the point here. And there is something we could do to fix this, 
> without broadening the scope -- limit what kind of services (shared or 
> exclusive) "get" can return. This leads us to a different issue, which is 
> compatibility with current implementations.
>
> To be completely honest here, with best practices in mind, I can't even 
> think of why a framework component (the ORM, in this case) should even be 
> container-aware. It should have its dependencies declared directly in the 
> constructor (or in separate setters) and just trust someone else (the 
> application) will inject them. A container should be just one of the 
> framework's components, not part of its core/kernel.
>
> Em sexta-feira, 4 de novembro de 2016 13:45:29 UTC-2, David Négrier 
> escreveu:
>>
>> Hi Pedro,
>>
>> I understand your example (about the event dispatcher that MUST be 
>> shared), but still, I disagree this is an issue with PSR-11.
>>
>> You say:
>>
>> *Now, my consumer, the ORM, is completely container agnostic. It only 
>> works, however, with SOME specific implementations (that ALWAYS return 
>> shared instances), and fails on SOME others (that ALLOWS for factories). I 
>> don't know (and can't control) how the entries were set, because I deferred 
>> this wiring to the application realm, by design. I don't know (and can't 
>> control) which container this is. If I can't guarantee it will work with 
>> ANY PSR-11 implementation, I cannot depend on the contract (PSR-11) - I'll 
>> have to depend of an implementation, which is bad.*
>>
>> When you say: *It only works, however, with SOME specific 
>> implementations (that ALWAYS return shared instances), and fails on SOME 
>> others (that ALLOWS for factories), *I disagree. If we use "solution 3" 
>> I'm proposing above, you should really write: *It only works, however, 
>> with SOME specific configurations (that ALWAYS return shared instances), 
>> and fails on SOME others (for containers that CAN provide non-shared 
>> services and that have been configured accordingly)*
>>
>> Now, you say: *I don't know (and can't control) how the entries were 
>> set, because I deferred this wiring to the application realm, by design.*
>>
>> When you say "I", I suppose you mean "the ORM author", am I right? Of 
>> course, you are right to say the ORM author can't control if the event 
>> dispatcher is shared or not. And it is not its job. And I'm sure you agree 
>> with me if I say that the ORM is not using ContainerInterface directly (it 
>> is the container how creates the ORM's EntityManager and injects the event 
>> dispatcher in it.
>>
>> So in the end, the wiring of the app is deferred to the application realm 
>> (i.e. the end user). If the en

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

[Pedro Cordeiro]

ven't done so yet, you should definitely take a look at 
> container-interop/service-provider 
> <https://github.com/container-interop/service-provider>. This project 
> proposes a way to put things into a container (and I hope will be the basis 
> of a future PSR). I just submitted a PR (here: 
> https://github.com/container-interop/service-provider/pull/33/files) that 
> makes sure that containers consuming a service provider MUST provide shared 
> services. So even if PSR-11 allows for non-shared service, 
> container-interop/service-provider explicitly forbids it for services 
> provided in service providers.
>
> TL;DR; I understand your sample about 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.
>
> Does it make more sense?
>
> ++
> David.
>
>
> Le jeudi 3 novembre 2016 10:58:51 UTC+1, Pedro Cordeiro a écrit :
>>
>> > 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 little. Hopefully this answers 
>> @Matthieu's question too.
>>
>> Let's say I have a framework component (and ORM, maybe) that triggers 
>> events (to log queries, maybe). This part of my framework fetches an event 
>> dispatcher (let's say, symfony's) from the registry, and it HAS to be a 
>> shared entry (otherwise, I'll just dispatch an event on a new instance that 
>> has no listeners).
>>
>> Now, my consumer, the ORM, is completely container agnostic. It only 
>> works, however, with SOME specific implementations (that ALWAYS return 
>> shared instances), and fails on SOME others (that ALLOWS for factories). I 
>> don't know (and can't control) how the entries were set, because I deferred 
>> this wiring to the application realm, by design. I don't know (and can't 
>> control) which container this is. If I can't guarantee it will work with 
>> ANY PSR-11 implementation, I cannot depend on the contract (PSR-11) - I'll 
>> have to depend of an implementation, which is bad.
>>
>> The only instances where I could depend on a 100% generic PSR-11 
>> container is when I don't care at all if the service being retrieved is 
>> exclusive or shared. And there only needs to be ONE place where I need a 
>> specific kind of instance, and my entire framework will depend on a 
>> specific implementation. The event dispatcher service is one example where 
>> I need a shared instance -- the ORM could be another. I don't want new 
>> connections being opened, I don't want two separate units of work with two 
>> different in-memory caches. If I fetch my ORM twice from the container, I 
>> expect to be given the same instance, not two different separate instances. 
>> If I fetch it twice from separate consumers, I still expect to be given the 
>> same instance.
>>
>> Now, I'll reiterate that I understand strengthening the SHOULD to a MUST 
>> would greatly hinder this PSR's adoption. I just want to know if you guys 
>> understand my point and if you guys still disagree that this is an issue, 
>> and why. I don't know if I'm failing to see it, but as far as I can think 
>> about it, not knowing what kind of instance the container will yield would 
>> also greatly restrict the possible uses and hinder its adoption -- and I'm 
>> not even talking about things out of scope here, because I'm failing to see 
>> its usefulness even for consumer-only frameworks, like shown on the 
>> previous examples.
>>
>> Em quarta-feira, 2 de novembro de 2016 15:45:49 UTC-2, David Négrier 
>> escreveu:
>>>
>>> This is a continuation from the discussion about whether PSR-11 
>>> containers should always return the same instance.
>>> See https://groups.google.com/forum/#!topic/php-fig/L8rDUwRFsOU for the 
>>> beginning of the discussion.
>>>
>>> <TL;DR;> I believe that we should keep the SHOULD word in place because 
>>> it does not hurt in practice and because we can require a container to 
>>> always return the same instance in the yet to come PSR that will define how 
>>> we put things into a container (see container-interop/service-provider 
>>> <https://github.com/container-interop/service-provider/> for

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

[Pedro Cordeiro]

>  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 doesn't make much sense. 
Restricting what entries can be configured do. What if I add a pizza-emoji 
service, does it make any sense disallowing fetching that service?

I agree with validating this when we are discussing setting entries. For 
now, I'd consider this out of scope.

Em quinta-feira, 3 de novembro de 2016 12:41:26 UTC-2, Larry Garfield 
escreveu:
>
> 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, or require/disallow /, or whatever.  Just 
> the legal world of opaque strings.
>
> I believe PSR-6's definition allows any UTF-8 character, so that would 
> include pizza emoji. :-)  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.  (Or, god forbid, 
> one tries to use Windows-1252 for some ungodly reason.)  Or perhaps one is 
> limited to only 5 character strings for some reason (stored in a database 
> column)?  Then passing in a longer string wouldn't work.
>
> PSR-6's requirement was simply "at leas a 64 character UTF-8 string, and 
> these chars are reserved".  If you don't want to reserve the same/any 
> characters that's fine, but at least a character encoding and minimum legal 
> length should be specified.
>
> --Larry Garfield
>
> On 11/03/2016 03:47 AM, David Négrier wrote:
>
> 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 allowed identifiers.
>
> Unlike PSR-6, there is no "set" in this PSR, therefore no need to 
> standardize the acceptable identifiers. For PSR-11, if the identifier 
> passed is "" (the pizza slice emoji) and the container does not support 
> emoji identifiers (what a shame! :) ), the container should return a 
> NotFoundException.
>
> David.
>
>
>
> Le mercredi 2 novembre 2016 22:49:33 UTC+1, Matthieu Napoli a écrit : 
>>
>> Splitting of the main thread, quoting Larry: 
>>
>> > The spec should specify what legal characters are for an entry 
>> identifier, and what if any reserved characters there are.  It should 
>> also specify minimum supported key length and character sets, for 
>> completeness.  I recommend borrowing PSR-6's language here, which I 
>> believe addresses this area well.  Whether it uses the same reserved 
>> character list or another one I don't feel strongly about. I would not 
>> consider this a Review-breaking change.  
>>
>> Why should we specify that? This is explicitly a "non-goal" of PSR-11: 
>> https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#32-non-goals
>>
>> -- 
> 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+u...@googlegroups.com .
> To post to this group, send email to php...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/5fa24b40-1b48-4c0e-907b-3fc88cc965dc%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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/edc0ee77-872a-4caa-a78a-998f311e7cf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Pedro Cordeiro]

> 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 little. Hopefully this answers @Matthieu's 
question too.

Let's say I have a framework component (and ORM, maybe) that triggers 
events (to log queries, maybe). This part of my framework fetches an event 
dispatcher (let's say, symfony's) from the registry, and it HAS to be a 
shared entry (otherwise, I'll just dispatch an event on a new instance that 
has no listeners).

Now, my consumer, the ORM, is completely container agnostic. It only works, 
however, with SOME specific implementations (that ALWAYS return shared 
instances), and fails on SOME others (that ALLOWS for factories). I don't 
know (and can't control) how the entries were set, because I deferred this 
wiring to the application realm, by design. I don't know (and can't 
control) which container this is. If I can't guarantee it will work with 
ANY PSR-11 implementation, I cannot depend on the contract (PSR-11) - I'll 
have to depend of an implementation, which is bad.

The only instances where I could depend on a 100% generic PSR-11 container 
is when I don't care at all if the service being retrieved is exclusive or 
shared. And there only needs to be ONE place where I need a specific kind 
of instance, and my entire framework will depend on a specific 
implementation. The event dispatcher service is one example where I need a 
shared instance -- the ORM could be another. I don't want new connections 
being opened, I don't want two separate units of work with two different 
in-memory caches. If I fetch my ORM twice from the container, I expect to 
be given the same instance, not two different separate instances. If I 
fetch it twice from separate consumers, I still expect to be given the same 
instance.

Now, I'll reiterate that I understand strengthening the SHOULD to a MUST 
would greatly hinder this PSR's adoption. I just want to know if you guys 
understand my point and if you guys still disagree that this is an issue, 
and why. I don't know if I'm failing to see it, but as far as I can think 
about it, not knowing what kind of instance the container will yield would 
also greatly restrict the possible uses and hinder its adoption -- and I'm 
not even talking about things out of scope here, because I'm failing to see 
its usefulness even for consumer-only frameworks, like shown on the 
previous examples.

Em quarta-feira, 2 de novembro de 2016 15:45:49 UTC-2, David Négrier 
escreveu:
>
> This is a continuation from the discussion about whether PSR-11 containers 
> should always return the same instance.
> See https://groups.google.com/forum/#!topic/php-fig/L8rDUwRFsOU for the 
> beginning of the discussion.
>
>  I believe that we should keep the SHOULD word in place because it 
> does not hurt in practice and because we can require a container to always 
> return the same instance in the yet to come PSR that will define how we put 
> things into a container (see container-interop/service-provider 
>  for a proposal). 
> On the other hand, requiring the container to return always the same value 
> would make PSR-11 de-facto incompatible with most containers out there (so 
> should be avoided). However, I think we definitely need to make 
> improvements on the wording that is clumsy (see end of the message). 
> 
>
> Currently, the spec says:
>
>
> *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 value on 2 successive calls.  *
>
> Hari, Larry, Pedro are asking if we could strengthen the SHOULD to a MUST 
> (as in: *Two successive calls to get with the same identifier MUST return 
> the same value*).
>
> For instance, Larry says:
>
> > I would prefer to have get() defined to always return the same object 
> (lazy loaded or otherwise, not relevant here), as that is the typical case, 
> and another method added (either on the same interface or a separate one, I 
> am flexible) to handle the factory use case.  That way I know the behavior 
> of each object I get back, specifically in relation to whether I have a 
> private copy or not.
>
> First of all, let me say if I was starting from a blank slate, I would 
> definitely agree with you and put a MUST here. But we are not starting from 
> a blank slate and many containers out there offer the possibility to create 
> new services each time you call "get". For instance Pimple (with the 
> factory method), or Symfony (with the "shared" option: 
> http://symfony.com/doc/current/service_container/shared.html)
> I definitely want Pimple and Symfony 

Re: [REVIEW] PSR-11 Container Interface

[Pedro Cordeiro]

return shared services for services 
> contained in my service provider. Both statements are not incompatible.
>
> ++
> David
> Twitter: @david_negrier
> Github: @moufmouf
>
> Le jeudi 27 octobre 2016 19:04:06 UTC+2, Pedro Cordeiro a écrit :
>>
>> To phrase it better: specifying that setting a service is out of scope 
>> for this abstraction and yet having this abstraction's behavior depend on 
>> how the service was set sounds really inconsistent and greatly limits the 
>> possible use cases for this standard.
>>
>> 2016-10-27 14:56 GMT-02:00 Pedro Cordeiro <pedro.c...@sympla.com.br>:
>>
>>> > As you noted in your post, if the user configured its container so 
>>> that a new dispatcher is injected in each service, this is configuration 
>>> issue, not an issue with the standard. The user is simply misusing its 
>>> container.
>>>
>>> I understand where you are coming from, and it makes sense from a 
>>> framework's developer point of view. This is the same conversation we had a 
>>> while ago, about the scope of this PSR. 
>>>
>>> However, as an application developer, this PSR doesn't help me much as 
>>> is, because:
>>>
>>> a) I still need adapters for each specific implementation to add 
>>> services to the container;
>>> b) even though adding services to the container is out of scope for this 
>>> PSR, I still need to know how to add a service in order to figure out what 
>>> a specific implementation of `get` will yield (a new instance or a shared 
>>> instance).
>>>
>>> So, as an application developer, the fact that this PSR doesn't enforce 
>>> either way makes even retrieving services (which is the scope of this PSR) 
>>> unusable without having to adapt my application to specific implementations.
>>>
>>> Now, to reiterate, I understand this was proposed under FIG 2.0 and that 
>>> its goal is to help interoperability between the frameworks themselves, not 
>>> to allow for agnostic implementations on enduser's applications. I'm just 
>>> pointing out that if setting a service is unknown AND getting a service 
>>> doesn't enforce shared objects/new instances, I can't truly know in my 
>>> application how it's going to behave. 
>>>
>>> My main complaint is: *I can end up with a class that depends on a 
>>> PSR-11 container (a contract/abstraction) but is incompatible with 
>>> some implementations of PSR11*, and it struck me as something weird to 
>>> have. This basically excludes the possibility of depending on PSR-11 in my 
>>> applications.
>>>
>>> A possible new PSR that defines how to set/add services shouldn't extend 
>>> PSR-11 because of this. It'd need to redefine if `get` should return a 
>>> shared/new instance DEPENDING on how the service was set.
>>>
>>> Currently, I can have a 100% PSR-11 compliant container that either:
>>> a) returns new instances each time `get` is hit;
>>> b) instantiates on the first hit, returns a shared instance always;
>>> c) returns either a new instance each time or a shared instance each 
>>> time, depending on the "set"/"add" implementation (which is out of scope 
>>> here).
>>>
>>
>>
>>
>> -- 
>>
>> *Pedro Cordeiro*
>> Produto
>>  
>> Phone: +55 31 3024 1115
>>
>> [image: Logo assinatura] 
>> <http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiXwUuwMLrMuwyQMihLilvGuFQlwqGcwaqcxv14TZBo-2Fkx216CWkoFS-2BFrkKrfuwK-2BVQHJQ1z2pKo2dYIxq5cmilGdRu7bAh5za9wh3RLzO4nA-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00DrbMV7fXYAiuL24XcUrHvHs1-2BIk0UWwDs-2F72MMLfB2NOFl6lJHtovPskkuiwYJajeWEJycLVSCkLape6k6LHU-2BSZcF2Uvp2Asye0iUJTldf0eVlnrql-2BA6I-2F6d00ZAiOxLHEVlUTd1ixtgJipaRe0L1jjobMF41uBNJLCRzafhz8q5oziitdm7z7VLEgrZz2klJhql8ltu8q97TK>
>>
>>
>> <http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiXwUuwMLrMuwyQMihLilvGuFQlwqGcwaqcxv14TZBo-2Fkx216CWkoFS-2BFrkKrfuwK-2BVQHJQ1z2pKo2dYIxq5cmilGdRu7bAh5za9wh3RLzO4nA-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIE

Re: [REVIEW] PSR-11 Container Interface

[Pedro Cordeiro]

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 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 dispatcher. If I register a listener on one
> instance of the dispatcher and trigger an event on another instance of the
> dispatcher, my registered listeners will not be called. Again, this is an
> application concern, not a framework concern and it could be argued that
> this kind of issue is out-of-scope for this PSR.
>
> But overall, I agree with Hari that the main use case for a container is
> to instance the service once and always return the same instance on further
> calls. If you retrieve new instances from your container on each call, your
> container is acting like a simple factory, not as a service
> container/dependency injection container.
>
> --
> 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/2c879363-54ca-4723-8a6e-01c1c9917718%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/2c879363-54ca-4723-8a6e-01c1c9917718%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 

*Pedro Cordeiro*
Produto

Phone: +55 31 3024 1115
<%2B55%2031%203024%200283>

[image: Logo assinatura]
<http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiXwUuwMLrMuwyQMihLilvGuFQlwqGcwaqcxv14TZBo-2Fkx216CWkoFS-2BFrkKrfuwK-2BVQHJQ1z2pKo2dYIxq5cmilGdRu7bAh5za9wh3RLzO4nA-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00DrbMV7fXYAiuL24XcUrHvHs1-2BIk0UWwDs-2F72MMLfB2NOFl6lJHtovPskkuiwYJajeWEJycLVSCkLape6k6LHU-2BSZcF2Uvp2Asye0iUJTldf0eVlnrql-2BA6I-2F6d00ZAiOxLHEVlUTd1ixtgJipaRe0L1jjobMF41uBNJLCRzafhz8q5oziitdm7z7VLEgrZz2klJhql8ltu8q97TK>

<http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiXwUuwMLrMuwyQMihLilvGuFQlwqGcwaqcxv14TZBo-2Fkx216CWkoFS-2BFrkKrfuwK-2BVQHJQ1z2pKo2dYIxq5cmilGdRu7bAh5za9wh3RLzO4nA-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00DrbMV7fXYAiuL24XcUrHvHs1-2BIk0UWwDs-2F72MMLfB2NOFl6lJHtovPskkug8HnNMYMLjg6qWS45zCOIrm0vptTNigLUcaaUyHWLPOZGe0FSmf9PqyBfjwjFw-2F88h7bt2F1L5K-2FcCWvoYbYXvfmpn1s4vRjzgBFGFfMaV4wNfAKPCaPqR75Md-2Flsd-2F7ry86VRGQ2Sc0YQoNvf1REv>*O
site com o maior número de eventos à venda do Brasil!*
<http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiXwUuwMLrMuwyQMihLilvGuFQlwqGcwaqcxv14TZBo-2Fkx216CWkoFS-2BFrkKrfuwK-2BVQHJQ1z2pKo2dYIxq5cmilGdRu7bAh5za9wh3RLzO4nA-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00DrbMV7fXYAiuL24XcUrHvHs1-2BIk0UWwDs-2F72MMLfB2NOFl6lJHtovPskkuh-2FcAWngEps85gZcv1JSt88f2MW6opGq90KNlySvzdU-2Fye89UtpBfv3fUye6Q18GdWjcQkrSLGREh4GUTjQXGm2TY6JDX6BMrWAmqiU-2BRatDqBDMb7o4f0IPHrMBwqWCmc1qGopJBiN5-2FLRBjhg40Gq>
www.sympla.com.br
<http://t.rdsv6.net/wf/click?upn=9ID9MxPkUk-2FXCePkr1qGk3jeNsyS6MabLki1WEC2jiVLI3wuhL5Ti6hw89C0ESCSVJNdh8FfaGqV-2BFmL5HRlzZKExa4qrB0ctNsViB6l8TFdI11l371V56-2Ffz1iwPM-2FaLxM6A0XQGU-2B6JVEDbnNA0Q-3D-3D_wKmGSCWlO-2F6J-2FSpm-2BxtvG5JaaAosDe4Q3OV4TyR4tzwOAocQ0H-2BKup9nj5ZrffTGmoFTZ-2FwY-2BiZ62zA9YUETNc69y4PsViv5cHctzYQM9bh8n4o9ivPlzVyx-2BJyllIEnG1Q-2F2tN-2BOSPuz0Nn8uv2ZSfKxBLUbTLKbmGhzSIZRi0PYxNI8DwJc7HKhR0hHwKI8kmuyZfBkzNrxoCmV0NXGSkn3a3WzIqMEkuwdILSgR-2Fm4Yi08v1XJ0ACOgxAjO-2BND8H30UmwWPAPr6joAP3kKuQ6WcA7R-2FTErDPH0l26ly5T8d00Dr

Re: [REVIEW] PSR-11 Container Interface

[Pedro Cordeiro]

> 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 dispatcher. If I register a listener on one 
instance of the dispatcher and trigger an event on another instance of the 
dispatcher, my registered listeners will not be called. Again, this is an 
application concern, not a framework concern and it could be argued that 
this kind of issue is out-of-scope for this PSR.

But overall, I agree with Hari that the main use case for a container is to 
instance the service once and always return the same instance on further 
calls. If you retrieve new instances from your container on each call, your 
container is acting like a simple factory, not as a service 
container/dependency injection container.

-- 
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/2c879363-54ca-4723-8a6e-01c1c9917718%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PSR-11] Question about PSR-11

[Pedro Cordeiro]

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 
register new services to the container, and then I'll have to make a bridge 
for each provider, since they won't agree on how to add new services. 
Wouldn't it defeat the purpose of this PSR, which is interoperability?

-- 
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/1877a319-8b9e-4150-8048-97e6b43750ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Pedro Cordeiro]

> 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 role. This is a FIG 3.0 proposal thread. You are deliberately 
hindering the discussion. Like everyone else already said, if you're 
unhappy with the current state of affairs, propose bylaw changes regarding 
the secretaries' role in FIG and put that to a vote.

Now, we can spend the rest of our lives here in this back-and-forth. You 
keep saying there is a problem, I keep responding that IF there is one, 
it's not FIG 3.0 related.

Em sábado, 17 de setembro de 2016 12:14:12 UTC-3, Korvin Szanto escreveu:
>
> Great job guys, I'm excited to see where this takes us and the php 
> community at large.
>
> I will say that it's too bad this discussion period was wasted, it 
> would've been nice to have an opportunity to talk about fig 3.0 at all.
>
> Thanks,
> Korvin
> On Sat, Sep 17, 2016 at 8:06 AM Paul Jones  > wrote:
>
>>
>> > On Sep 15, 2016, at 13:37, Matthew Weier O'Phinney <
>> mweiero...@gmail.com > wrote:
>> >
>> > On Thu, Sep 15, 2016 at 9:11 AM, Paul Jones > > wrote:
>> >> So I still have no idea if the secretary role is intended as an 
>> "assistant" type of secretary, or some other type of secretary. Again, this 
>> should be a straightforward thing to answer.
>> >
>> > You're creating a false dichotomy, Paul.
>>
>> Not at all. It might be part assistant, part something else (or perhaps 
>> multiple something elses).
>>
>> Regardless, I seem to have gotten an answer from Larry's SitePoint 
>> article on the FIG at <
>> https://www.sitepoint.com/the-past-present-and-future-of-the-php-fig/> :
>>
>> > In late 2015, FIG added a 3-person Secretary position, elected by 
>> project reps, to handle managerial tasks but stay out of technical tasks. I 
>> personally feel that change has been a resounding success, as managerial 
>> tasks are actually getting done now ...
>>
>> Based on that, it seems the Voting Members are the workers in FIG, and 
>> the secretaries are the managers in FIG.
>>
>> Is that what everyone who voted +1 on the secretary role understood the 
>> case to be?
>>
>>
>> --
>>
>> Paul M. Jones
>> http://paul-m-jones.com
>>
>>
>>
>> --
>> 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+u...@googlegroups.com .
>> To post to this group, send email to php...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/7DBA8B40-A3C8-4683-8670-9B651A55A719%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/61cff5c5-7224-4d0a-bdff-fc9e18ba7a1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Pedro Cordeiro]

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  > wrote: 
> > 
> > The Secretary role is not changing in FIG 3.0 as previously stated. 
>
> And what role is that, exactly?  Assistive, or more along the lines of 
> "Secretary-General" or  "Secretary of (Parliament|State|etc)" ? 
>
>
> -- 
>
> Paul M. Jones 
> http://paul-m-jones.com 
>
>
>
>

-- 
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/8c081150-5ce9-4747-b2e8-b30b00ad7ba6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Pedro Cordeiro]

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 to a styling standard). This 
will make every major project non-psr2-compliant, and will break its status 
as the de-facto standard.
2) If that rule must change, just get rid of it. Do NOT force projects to 
remove the suffix, just don't enforce the suffix anymore. That would be a 
minor change, as it's more permissive and therefore backwards compatible.
3) Let's be consistent and use the same rule to interfaces, abstract and 
traits (at least).

- Pedro.

-- 
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/eaae419c-b94e-49f9-a976-be05be3ece49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.