Re: PSR-11 and the next steps - Service Provider Interop

[David Négrier]

Hey Benjamin,

I'm the PSR-11 co-editor and service-provider author here (with Matthieu 
Napoli).
I tried to start a service-provider PSR about 2 years ago (based on the 
work started with container-interop/service-provider) but I failed to setup 
a team of people motivated enough to work on this (believe me, it requires 
some time).

I'm still very interested in working on this topic but I have limited time 
right now. Many of us have experimented quite a bit and I'm sure we have 
the collective knowledge for a great PSR. I don't have time to lead the 
subject but if anyone manages to start a working group, I'm interested in 
helping!

++
David.


Le jeudi 9 janvier 2020 14:27:35 UTC+1, Paul Dragoonis a écrit :
>
> As per last year, I'm still keen to continue to contribute to this. 
>
> I have already implemented and solved this situation for the laravel 
> project. 
>
> I gave my client container interop and interoperable service providers and 
> respective config, and brought this to laravel projects  
>
> This was to share code between symfony, laravel and a bespoke product, and 
> it increased performance massively too since laravel was quite slow in its 
> lookups until my impl.
>
> I also solved this issue with the PPI Framework project in the past, and 
> the objective of that project was to solve these things in advance, and 
> give them to real world clients,  prior to it popping up in FIG and the 
> wider community.
>
> As such I have the experience and drive to work on this and see it through 
> to release.
>
> If you'd like me involved then let me know. In turn I will show up at the 
> next get together we have (online) to talk about technical details, 
> implementation and next steps. 
>
> Just send me the invite.
>
> Many thanks,
> Paul
>
>
>
>
>
>
> On Wed, 8 Jan 2020, 19:37 Benjamin Mack,  > wrote:
>
>> Hi list,
>>
>> since we (TYPO3 CMS) are continuing our path in modernizing our PHP 
>> stack, we've been looking for ways to standardize our container 
>> implementation. While it's good to have PSR-11 for Service Containers - and 
>> we utilize this with our latest version - we had some discussions around 
>> the actual service providers (factories, extensions), and my _guess_ is 
>> that it was a too much to put into PSR-11 and to tackle container PSR 
>> first, and then "at some point" see if service provider PSR would be 
>> feasible.
>>
>> We found the service-provider package (air quotes EXPERIMENTAL, 
>> https://github.com/container-interop/service-provider/) to be extremely 
>> cool, but were reluctant to depend on the package, but would really love to 
>> see such a (IMHO common) need to be provided as a PHP Standards 
>> Recommendation.
>>
>> So, my question is: Is there an interest (either by the original PSR-11 
>> gang, CC or by somebody else in this list) to invest this topic further? Or 
>> did I just miss some communication that this isn't something that is 
>> feasible in moving forward?
>>
>> Thanks in advance for any hints and clarification!
>>
>> Benni Mack,
>> TYPO3 Project Lead
>> https://typo3.org - inspire people to share.
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/F9B5D08F-3134-420F-9128-12245F919C2D%40gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/adcb6d9e-2e20-4758-8e68-c6036d1cee3c%40googlegroups.com.

Re: [BYLAW] Proposal: let PSRs evolve with the language

[David Négrier]

Hey FIG,

It's been a while since I last posted here. Just wanted to give a huge +1 
to Stefano Torresi proposal.
Having a different package with a different namespace for major version 
would solve compatibility issues instantly. I think this is something we 
ought to consider.

Also, this is something that has already be done in other languages.
For instance, when Microsoft releases a new version of DirectX, it prefixes 
all classes with the 
version: https://docs.microsoft.com/en-us/windows/win32/api/d3d11/

Without going as far as Stefano proposes, it could possible to propose a v2 
without completely changing the naming scheme. For instance v2 of PSR-11 
could be:

- Namespace: Psr\Container\v2
- package: psr/container2 

Stefano's idea is far from crazy, it totally makes sense.

Additionally, you can mark "psr/container" as deprecated in composer, 
asking to migrate to "psr/container2" in order to speed up adoption.

++
David.

Le samedi 5 octobre 2019 15:21:47 UTC+2, G. P. B. a écrit :
>
> Greetings PHP-FIG,
>
>
> From my understanding this project is to add parameter and return types to 
> some of the interfaces defined in PSRs before those exists in PHP.
>
>
> First, adding parameter types is the easiest and also, in my mind, the 
> most important type information to add, as it is impossible to add a more 
> specific type from a mixed type as it goes against LSP.
> This is easy to add as it doesn't break compatibility with current 
> implementations, as parameter types can be widened. 
> Adding parameter types can be tagged as a version 1.1.0 because semver 
> allows to upgrade dependencies in minor version. i.e. updating the PHP 
> version is a dependency update.
>
> Determining whether the change is a patch level or minor level 
>> modification depends on whether you updated your dependencies in order to 
>> fix a bug or introduce new functionality. I would usually expect additional 
>> code for the latter instance, in which case it’s obviously a minor level 
>> increment.
>
>
> See FAQ on https://semver.org/
>
> Secondly adding return types, this cannot be done in a BC compatible way 
> as having a wider (i.e contravarient) return type breaks LSP.
> However, I would argue that with the imminent release of PHP 7.4 this is a 
> non-issue.
> Indeed PHP 7.4 comes with the feature of contravarient parameter types 
> (i.e type widening) and covarient return types (i.e limiting the return 
> type).
> This means that a library will be able to add return types even though the 
> PSR interface doesn't specify a return type if it decides to only support 
> PHP 7.4 as a minimum version, which IMHO is bound to happen as there are a 
> ton of features bundled with this release of PHP.
>
> I hope that everyone can agree that adding parameter types in a minor 
> version of the PSR spec and leaving return types alone is a better plan 
> than, IMHO, the various other proposals which seem unnecessary complicated.
>
> Best regards
>
> George Peter Banyard
>
>  
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/e7154f93-10cb-44c7-a885-7c31fb1a4e7c%40googlegroups.com.

Service provider PSR: proposed goal and scope

[David Négrier]

Hi list,

Following my last message here, it has been clear we need to clearly define 
the scope of this PSR (before going to Draft stage)
I've been working on my "ideal" scope. I'm sharing it with you here in the 
hope to gather the maximum amount of comments.

As usual, I cross-posted this proposed scope on my blog if you want a 
better formated 
version: 
https://thecodingmachine.io/psr-11-scope-of-universal-service-providers-part2

Stated goal

Each framework has it's own custom package format. What these package 
formats are doing is essentially always the same. They are used to put 
things in a container.

If the PHP-FIG could come up with a unique package format that could be 
supported by all frameworks, package developers could truly write classes 
that can be used in any framework more easily.

Hence, the stated goal of this PSR (let's call it PSR-X since it does not 
have a number yet) is to *find a common package format that could be 
supported by all frameworks*.


In the rest of this post, I'll highlight a list of "abilities" that this 
package format should have.


1: Ability to put entries in a container

The very first thing our package format should be able to do is to *put 
things in a container*.


*Use case*: 

If I wrote a new "logger" package, with a MyLogger class in it, I want to 
register an entry in the container containing a MyLogger instance.


In other words, the PSR should be able to feed the container with a 
*factory* that can create the requested service.


2: Ability to claim a default implementation for an interface

The package should be able to declare that the service it provides is the 
*default 
implementation for a given interface* (this is important for auto-wiring 
containers). 


*Use case*: 

My MyLogger class implements PSR-3. I want a way to tell the container 
explicitly that if a service has a dependency on the Psr\Log\LoggerInterface, 
the entry I provide is a good candidate and can be used.


Note: in almost all containers I've seen, this is done by relying on 
convention and "aliases". It seems there is an agreement that to "claim" 
ownership of an interface, your identifier for the entry should be the 
fully qualified name of the interface.

"Psr\Log\LoggerInterface" => your logger instance

Since a service can implement many interfaces, the best practice here seems 
to be using aliases.

"MyLogger" => your logger instance"Psr\Log\LoggerInterface" => alias to 
"MyLogger"



3: Ability to "tag", with or without priorities

The package can register a provided service as part of a "group" of 
services that share the same purpose.

Those services might need to be ordered inside the tag.


*Use case*: 

My package is providing a PSR-15 middleware in charge of transforming 
exceptions into HTTP 500 pages. I don't know who will consume it (it might 
be Zend Stratigility or any other PSR-15 consumer). I want my package to 
instruct the container that:

   - my middleware should be part of the middleware pipe (i.e. it should be 
   "tagged" as belonging to a middleware) 
   - my middleware should be the first in the "middleware pipe". 

Note: PSR-11  does not introduce the 
notion of tags. Indeed, all containers do not have the notion of tag 
built-in. But PSR-11 specifies that a container entry can be anything 
 (it is 
not limited to objects only). Therefore, a "tag" can be seen as a container 
entry that contains an array of services.


4: Ability to alter a service

A package should be able to alter/modify a service stored in the container, 
either by calling methods on it or by "decorating" it.


*Use case*: 

My package is providing a Twig extension. I want my package to:

   - Create a new container entry called `MyExtension` 
   - Alter the `Twig_Engine` instance in the container to call: 
   $twig->register($myExtension);. 

5: Auto-discovery

When you install a Symfony Bundle in Symfony 4 (via composer require), Symfony 
Flex  takes care of registering the bundle 
for you. Same thing with Laravel Service Providers since Laravel 5.5 

 
or with Zend Framework 
. Those 
frameworks are actually coming with a Composer plugin that triggers after a 
package is installed and that is looking for some configuration in the 
package (either a manifest.json file or a special "extra" section in the 
composer.json file).

If we want our package format to be as easy to use as the framework 
specific package formats, we need to have a way for underlying frameworks 
to perform auto-discovery of service providers.

*Use case*: 

I'm performing a composer require to install a new package. Some composer 
plugin specific to my framework is triggered. The framework registers the 
service 

Re: Service provider PSR: discussing the scope

[David Négrier]

> I think it was a mistake that PSR-11 allowed the container to contain 
> scalar values. 
>

I strongly disagree here. I think the decision we took to allow returning 
anything was the good one.
Otherwise, containers like Pimple based on factories could never properly 
implement PSR-11. PSR-11 adapted fairly well to the wide range of 
containers out there, without dictating a philosophy. If I had to start it 
again (god help me :), I would do the same!
 

>
> The value in a config PSR is that it would greatly improve type safety 
> (container contains objects, config contains scalars) and therefore 
> make it much easier to approach how a service provider is configured, 
> as not all containers have a way to fetch scalar values. 
>

Isn't this "type safety" an illusion? I mean... a config PSR could still 
return strings, ints, arrays of scalars, ...
And even restricted to only returning objects, a container can return ANY 
type of object on a given key.

So spliting one container into 2 containers (one for config and one for 
objects) is very far from bringing us any real type safety.

If we want to address type safety issues, we'd better look at Symfony's 
proposal (using an array to map identifiers to types). That brings way more 
value.

++
David
Twitter: @david_negrier
Github: @moufmouf


 

> -- 
> Woody Gilk 
> http://about.me/shadowhand 
>
>
> On Mon, Mar 5, 2018 at 8:54 AM, David Négrier <david@gmail.com 
> > wrote: 
> > Hey Woody, 
> > 
> > I'm really not sure we need that config PSR. 
> > 
> > My reasoning goes like this: 
> > 
> > What do we need for a config PSR? We cannot standardize a configuration 
> > format. Each framework has its own format (YAML, PHP array files, NEON, 
> > etc...) 
> > 
> > However, we can standardize how we "get" a config value from the 
> > application. 
> > 
> > So we would certainly have an interface like a `ConfigFetcherInterface` 
> with 
> > a "get" (and maybe a "has" method): 
> > 
> > interface ConfigFetcherInterface 
> > { 
> > public function get(string $name) : mixed; 
> > public function has(string $name) : mixed; 
> > } 
> > 
> > Whoops... It is identical to PSR-11! 
> > You can argue it serves a different purpose, but PSR-11 already states 
> that 
> > a container can contain anything (including scalars like strings, ints, 
> > etc...) 
> > So we could use PSR-11 for configuration fetching. 
> > 
> > We could however discuss if we want to split configuration from services 
> in 
> > the function signature of factories. 
> > 
> > Current signature for a factory is: 
> > 
> > function(ContainerInterface $container) 
> > 
> > where $container contains both configuration and services. 
> > 
> > We could change the signature to something like: 
> > 
> > function(ContainerInterface $configContainer, ContainerInterface 
> > $serviceContainer) 
> > 
> > I'm not really a big fan of this, but I can understand it rings a bell 
> for 
> > people we are making a clear distinction between config and services 
> (like 
> > in Symfony). 
> > 
> > What do you think? 
> > 
> > David. 
> > 
> > 
> > 
> > Le dim. 4 mars 2018 à 01:44, Woody Gilk <woody...@gmail.com 
> > a écrit : 
> >> 
> >> I think that Oscar's PR proves the point that we need a config PSR 
> before 
> >> service providers will make sense. Using the container for 
> configuration is 
> >> not (imho) the purpose of containers and makes it harder to standardize 
> on 
> >> using FQCN for container identifiers. 
> >> 
> >> 
> >> On Sat, Mar 3, 2018, 15:18 Oscar Otero <oscar...@gmail.com 
> > wrote: 
> >>> 
> >>> To me, the problem with these proposals is they have different 
> >>> responsabilities in the same class. A ServiceProvider implementation 
> >>> includes the callables to create instances of different services, 
> defines 
> >>> the key used to store each of these services and even include two 
> methods: 
> >>> one to get factories and other for extensions, so in many times you 
> have to 
> >>> create a method returning an empty array (see 
> >>> https://github.com/container-interop/service-provider/issues/43), 
> (Interface 
> >>> segregation principle). 
> >>> 
> >>> I proposed a different approach 
> >>> (https://github.com/container-interop/service-provider/issues/45) 
> consisting 
> >>

Re: Service provider PSR: discussing the scope

[David Négrier]

Hey Woody,

I'm really not sure we need that config PSR.

My reasoning goes like this:

What do we need for a config PSR? We cannot standardize a configuration
format. Each framework has its own format (YAML, PHP array files, NEON,
etc...)

However, we can standardize how we "get" a config value from the
application.

So we would certainly have an interface like a `ConfigFetcherInterface`
with a "get" (and maybe a "has" method):

interface ConfigFetcherInterface
{
public function get(string $name) : mixed;
public function has(string $name) : mixed;
}

Whoops... It is identical to PSR-11!
You can argue it serves a different purpose, but PSR-11 already states that
a container can contain anything (including scalars like strings, ints,
etc...)
So we could use PSR-11 for configuration fetching.

We could however discuss if we want to split configuration from services in
the function signature of factories.

Current signature for a factory is:

function(ContainerInterface $container)

where $container contains both configuration and services.

We could change the signature to something like:

function(ContainerInterface $configContainer, ContainerInterface
$serviceContainer)

I'm not really a big fan of this, but I can understand it rings a bell for
people we are making a clear distinction between config and services (like
in Symfony).

What do you think?

David.



Le dim. 4 mars 2018 à 01:44, Woody Gilk <woody.g...@gmail.com> a écrit :

> I think that Oscar's PR proves the point that we need a config PSR before
> service providers will make sense. Using the container for configuration is
> not (imho) the purpose of containers and makes it harder to standardize on
> using FQCN for container identifiers.
>
>
> On Sat, Mar 3, 2018, 15:18 Oscar Otero <oscarot...@gmail.com> wrote:
>
>> To me, the problem with these proposals is they have different
>> responsabilities in the same class. A ServiceProvider implementation
>> includes the callables to create instances of different services, defines
>> the key used to store each of these services and even include two methods:
>> one to get factories and other for extensions, so in many times you have to
>> create a method returning an empty array (see
>> https://github.com/container-interop/service-provider/issues/43),
>> (Interface segregation principle).
>>
>> I proposed a different approach (
>> https://github.com/container-interop/service-provider/issues/45)
>> consisting in creating a factory for each service. The proposal is just a
>> sketch to illustrate the main concept (each object has just one
>> responsabiity: create a service) and surely can be improved.
>>
>>
>>
>> El 3 mar 2018, a las 14:07, David Négrier <david.negr...@gmail.com>
>> escribió:
>>
>> To build upon Larry's answer, the container does not only contains
>> services. It knows how to build them.
>>
>> If we ended up "setting" in a container every service, well first... we
>> could use arrays instead of containers :) and then, the performance of the
>> container would degrade proportionally to the number of entries in the
>> container. You would have to instantiate and store every service on every
>> request, even if the service does not end up being called. So basically,
>> the bigest your application, the slowest.
>>
>> This is why both proposals carefully avoid the use of a "set" method.
>>
>> ++
>> David.
>>
>>
>> Le vendredi 2 mars 2018 23:02:49 UTC+1, Larry Garfield a écrit :
>>>
>>> The reason a simple set() won't work is that the "thing" put into the
>>> container is generally not a value but instructions for how to produce a
>>> value
>>> on-demand, and the value is typically a service object.  How to encode
>>> "here's
>>> how to build the thing" is the main question to answer.
>>>
>>> --Larry Garfield
>>>
>>> On Friday, March 2, 2018 1:18:32 PM CST David Lundgren wrote:
>>> > If the problem to solve is "what's a common way to put things in a
>>> > container?" wouldn't the simplest solution be a `set($id, $value)`
>>> method
>>> > on the container?
>>> >
>>> > Most container implementations already have a method of this sort.
>>> While a
>>> > few have shared/concrete/protected concepts baked in, they could make
>>> > separate methods for changing it  based on the $id.
>>> >
>>> > Dave
>>> >
>>> > On Thursday, March 1, 2018 at 11:16:29 AM UTC-6, David Négrier wrote:
>>> > &g

Re: Service provider PSR: discussing the scope

[David Négrier]

To build upon Larry's answer, the container does not only contains 
services. It knows how to build them.

If we ended up "setting" in a container every service, well first... we 
could use arrays instead of containers :) and then, the performance of the 
container would degrade proportionally to the number of entries in the 
container. You would have to instantiate and store every service on every 
request, even if the service does not end up being called. So basically, 
the bigest your application, the slowest.

This is why both proposals carefully avoid the use of a "set" method.

++
David.


Le vendredi 2 mars 2018 23:02:49 UTC+1, Larry Garfield a écrit :
>
> The reason a simple set() won't work is that the "thing" put into the 
> container is generally not a value but instructions for how to produce a 
> value 
> on-demand, and the value is typically a service object.  How to encode 
> "here's 
> how to build the thing" is the main question to answer. 
>
> --Larry Garfield 
>
> On Friday, March 2, 2018 1:18:32 PM CST David Lundgren wrote: 
> > If the problem to solve is "what's a common way to put things in a 
> > container?" wouldn't the simplest solution be a `set($id, $value)` 
> method 
> > on the container? 
> > 
> > Most container implementations already have a method of this sort. While 
> a 
> > few have shared/concrete/protected concepts baked in, they could make 
> > separate methods for changing it  based on the $id. 
> > 
> > Dave 
> > 
> > On Thursday, March 1, 2018 at 11:16:29 AM UTC-6, David Négrier wrote: 
> > > Hey list, 
> > > 
> > > We are still in the process of forming a working group regarding a 
> Service 
> > > provider PSR. 
> > > 
> > > I've had the chance to speak about this with several Symfony 
> contributors, 
> > > and while discussing about this idea, Nicolas Grekas 
> > > <https://github.com/nicolas-grekas/> (from Symfony) came up with an 
> > > alternative proposal. It's about having many containers working 
> together, 
> > > with a slightly different scope. First of all, I'd like to thank 
> Nicolas 
> > > for the time he is investing in researching this issue, and for all 
> the 
> > > feedback. We talked about his idea with Matthieu Napoli 
> > > <https://github.com/mnapoli/> and Larry Garfield 
> > > <https://github.com/crell> at the Paris ForumPHP in November. I'm now 
> > > sharing this conversation with you. 
> > > 
> > > I put this in a blog article that you can find here: 
> > >
> https://thecodingmachine.io/psr-11-scope-of-universal-service-providers 
> > > 
> > > I'm reposting the content of the article here, since it's directly 
> related 
> > > to PHP-FIG concerns. It's a bit long, but the topic is worth it :) 
> > > 
> > > Stated goal 
> > > 
> > > Each framework has it's own custom package format (bundles, packages, 
> > > modules, etc...). What these package formats are doing is essentially 
> > > always the same. They are used to put things in a container. 
> > > 
> > > If the PHP-FIG could come up with a unique package format that could 
> be 
> > > supported by all frameworks, package developers could truly write 
> classes 
> > > that can be used in any framework more easily. 
> > > 
> > > Hence, the stated goal of this PSR (let's call it PSR-X since it does 
> not 
> > > have a number yet) is to find a common way to *put things in a 
> container*. 
> > > 
> > > We (the container-interop group) have been working on this for quite 
> some 
> > > time and have come up with a solution that needs to be turned into a 
> PSR 
> > > <https://github.com/container-interop/service-provider/>. The idea is 
> to 
> > > build generic service providers. 
> > > 
> > > 
> > > Current proposal 
> > > 
> > > The current proposal is named container-interop/service-provider 
> > > <https://github.com/container-interop/service-provider/>. In this 
> > > proposal, we create a ServiceProviderInterface interface that exposes 
> a 
> > > set of *factories*. 
> > > 
> > > 
> > > class MyServiceProvider implements ServiceProviderInterface{ 
> > > 
> > > public function getFactories() 
> > > { 
> > > 
> > > return [ 
> > > 
> > > 'my_service' => function(ContainerInterface $container) : 
> 

Re: Service provider PSR: discussing the scope

[David Négrier]

Hey Rasmus,

Thanks for the feedback!

Version 0.4 of the ongoing original proposal looks pretty solid to me by 
> now.
>
> The alternative proposal involves strings with PHP-like type-hints that 
> need to be parsed and checked at run-time. Seems a bit brittle, more 
> complex than I'd like, and doesn't really seem necessary.
>

Both proposals do not have the same maturity level. Maybe you should not 
focus too much on the implementation details of the Symfony proposal but on 
the general idea.
For instance, we could propose to replace the "PHP-like type-hints"  
strings by proper classes. Like:

return [
"my_service" => new Type(MyService::class, $isOptional)
];

Or for the "ServiceSubscriberInterface" (the interface that publishes the 
list of required dependencies of a given service provider), it could be 
interesting to replace the type by a "ValidatorInterface".

Something like:

interface ValidatorInterface {
public function validateDependency($entry);
}

class MyServiceProvider implements ..., ServiceSubscriberInterface
{
public function getSubscribedServices()

{
return [
'debug' => new CanBeNull(new(MustBeBool()),
'twig_extensions' => new CanBeNull(new 
MustBeArrayOf(TwigExtentionInterface::class)),

];
}

}

This could allow very interesting possibilities (we could do more than only 
checking the type of the dependencies).

Also, as Nicoas noted, both proposals are not mutually exclusive.

@Nicolas, what do you think?

The only thing missing for me, from the first proposal, is the ability for 
> providers to depend on providers, somehow. These past few years, I've been 
> part of building a big system at work - and we have so many providers now, 
> with so many dependencies, one of the most common problems is "hey, this 
> provider gave me some component that needs a dependency X, which other 
> provider is supposed to provide me with X?"
>
> The second proposal seems to address the need to check for missing 
> dependencies up front - but what we'd really like, is a declarative means 
> of saying "this provider depends on that provider", since, almost 100% of 
> the time, in an environment where literally everything is bootstrapped by 
> providers, the answer to "X is missing" is going to be "Add the provider of 
> X", rather than "bootstrap X yourself".
>
> Another common problem is the order in which providers get bootstrapped - 
> if one provider needs to override a registration of another, the order 
> matters.
>
> One idea to solve both of these issues, is to introduce a provider ID of 
> some sort. The provider's own class name would be an obvious candidate, 
> though the Composer package name might be a safer choice, since ::class 
> might not provide static analysis when a provider isn't installed.
>
> So basically two methods:
>
> function getProviderID(): string;
> function listRequiredProviders(): string[]
>
> The container can now get the full list of providers, use a topological 
> sort to figure out the correct order in which to bootstrap these providers, 
> check for missing providers, etc.
>
> This enables "abstract" providers as well - for example, a provider might 
> depend on "psr/cache", which might be the Provider ID of numerous packages 
> with an agreed-upon ID and bootstrapping scope. This would build on the 
> idea of abstract Composer packages and make that concept more useful - 
> since merely installing a package (with correct version and dependcies etc) 
> is all that Composer can guarantee, this lets us guarantee that it's 
> provider has also been bootstrapped.
>
> I think, at this point, that's the only missing feature for me.
>

I completely agree that we need to discuss the way we handle the 
dependencies between service providers. We never really had a discussion on 
this topic, and I'm facing the same issue as you are.

I'm not completely sold to the idea of adding a notion of "providerID" as 
you present it. It's not a notion that exists in any existing framework. 
Also, making it "explicit" adds another layer of complexity to the 
solution. I'd rather have a service-provider declares that it requires a 
"Psr\Log\LoggerInterface" entry rather than having a service-provider 
declares that it requires a "psr3-service-provider" service provider (at 
the class level)

That being said, I agree that we could use the notion of "virtual packages" 
already available in Composer to carry that meaning (at the package level)

Let's take an example with 2 service providers.

Service provider "myService" provides a "MyService" entry that requires a 
"Psr\Log\LoggerInterface" entry to be available in the container.
Service provider "monolog" provides a "Psr\Log\LoggerInterface" entry.

In the composer.json of the package containing the MonologServiceProvider, 
we could add:

{
"provide": { "psr-3-service-provider": "1.0.0" }
}

In the composer.json of the package containing the "myService" service 

Service provider PSR: discussing the scope

[David Négrier]

Hey list,

We are still in the process of forming a working group regarding a Service 
provider PSR.

I've had the chance to speak about this with several Symfony contributors, 
and while discussing about this idea, Nicolas Grekas 
 (from Symfony) came up with an 
alternative proposal. It's about having many containers working together, 
with a slightly different scope. First of all, I'd like to thank Nicolas 
for the time he is investing in researching this issue, and for all the 
feedback. We talked about his idea with Matthieu Napoli 
 and Larry Garfield  
at the Paris ForumPHP in November. I'm now sharing this conversation with 
you.

I put this in a blog article that you can find here:

   https://thecodingmachine.io/psr-11-scope-of-universal-service-providers

I'm reposting the content of the article here, since it's directly related 
to PHP-FIG concerns. It's a bit long, but the topic is worth it :)

Stated goal

Each framework has it's own custom package format (bundles, packages, 
modules, etc...). What these package formats are doing is essentially 
always the same. They are used to put things in a container.

If the PHP-FIG could come up with a unique package format that could be 
supported by all frameworks, package developers could truly write classes 
that can be used in any framework more easily.

Hence, the stated goal of this PSR (let's call it PSR-X since it does not 
have a number yet) is to find a common way to *put things in a container*.

We (the container-interop group) have been working on this for quite some 
time and have come up with a solution that needs to be turned into a PSR 
. The idea is to 
build generic service providers.


Current proposal

The current proposal is named container-interop/service-provider 
. In this proposal, 
we create a ServiceProviderInterface interface that exposes a set of 
*factories*.


class MyServiceProvider implements ServiceProviderInterface{
public function getFactories()
{
return [
'my_service' => function(ContainerInterface $container) : MyService 
{
$dependency = $container->get('my_other_service');
return new MyService($dependency);
}
];
}

// ...
}


In the example above, the 'my_service' service can be created by the 
container by executing the factory (the anonymous function).

Additionally, the ServiceProviderInterface let's you *modify* existing 
services stored in the container.


class MyServiceProvider implements ServiceProviderInterface{
// ...

public function getExtensions()
{
return [
Twig_Environment::class => function(ContainerInterface $container, 
Twig_Environment $twig) : Twig_Environment {
$twig->addExtension($container->get('my_extension'));
return $twig;
}
];
}
}


In the example above, the service named "Twig_Environment" is modified. We 
register a new twig extension in it. This is very powerful. This can be 
used to create arrays and add elements to them, or this can be used to 
decorate an existing service (using the decorator pattern). Overall, this 
gives a lot of power to the service provider.

Right now, this interface has been tested. It has adapters in Symfony, 
Laravel, and there is a Pimple fork named Simplex that is also implementing 
it. You can view the complete list of implementations here 
.


The alternative proposal

Nicolas Grekas and the Symfony team came up with another proposal 
.

Rather than standardizing service providers, he proposes that each package 
could provide it's own container. The container would have an interface to 
expose a list of services to your application's container.

The proposal goes like this:


interface ServiceProviderInterface extends ContainerInterface{
/**
 * Returns an associative array of service types keyed by names provided by 
this object.
 *
 * Examples:
 *
 *  * array('logger' => 'Psr\Log\LoggerInterface') means the object 
provides service implementing Psr\Log\LoggerInterface
 *under "logger" name
 *  * array('foo' => '?') means that object provides service of unknown 
type under 'foo' name
 *  * array('bar' => '?Bar\Baz') means that object provides service 
implementing Bar\Baz or null under 'bar' name
 *
 * @return string[] The provided service types, keyed by service names
 */
public function getProvidedServices(): array;
}


Notice how the ServiceProviderInterface extends the PSR-11 
ContainerInterface .

Here, there is a single function getProvidedServices that provides 

Re: Minimal HTTP middleware

[David Négrier]

Hey Beau,

Thanks a lot for your detailed posts.

You understood my idea completely and you are expressing (in better words) 
exactly what I wanted to suggest. I take my hat of to you.

Also, you are 100% right in the critics you make. Indeed, middleware 
authors would have to write 2 classes (one middleware and one factory). You 
are also right to state that the factory class is mostly a boilerplate 
class with a constructor that takes the same arguments as the middleware, 
except the "next" middleware that is provided at runtime to the factory.

I've been looking for ways to write a "generic" factory, but to do this, we 
have to go back to a convention (like in Stack) so I've not yet found 
something sexy enough to speak about it.

Anyway, I'm glad I could help move the discussion forward. I completely 
forgot to state it but I have really no strong feeling about which way 
PSR-15 go. I'm really ok with the way PSR-15 is right now. I understand 
what Rasmus says regarding the fact that not all middlewares need a "next" 
delegate (or that some need more than one). I would be glad if we can find 
a way to improve this, but I also understand Beau whan he says he does not 
want this to be at the expense of simplicity (my proposal requires writing 
2 classes and only one class to write is a plus as it will help widen 
adoption). It looks to me like so far, unless we can come up with a better 
idea, there is a tradeoff to be done. Whatever way this is going, I'll be 
happy ;)

++
David.


Le lundi 15 mai 2017 02:43:27 UTC+2, Beau Simensen a écrit :
>
> On Sunday, May 14, 2017 at 11:13:46 AM UTC-5, Rasmus Schultz wrote:
>>
>> > the middleware themselves cannot be autowired and *must* be created 
>> manually by the factory.
>>
>> Are you highlighting this as a problem?
>>
>> Of course the factory would need to create the middleware - that's what a 
>> factory is for. (?)
>>
>
> I think there is confusion between your solution and the middle-ground 
> David was proposing. I had hoped I kept that post more clear but it appears 
> I failed. :( My bad.
>
> First, yes, it is a problem because a middleware that could previously be 
> autowired can now only be created manually by a factory, even though the 
> middleware has not changed much at all.
>
> Second, with the existing proposal we don't need a factory. Yes, David's 
> proposal has a factory so yes, obviously, it should be used to create the 
> middleware. If we ended up going with something like David proposed, I do 
> not disagree that this is where the middleware should be created. :)
>
> My entire set of example code was intended to show what would happen to 
> one of my real world middleware if we implemented Davdi's proposal.
>
>  
>
>> > At the end of the day it comes down to whether the delegate/next of a 
>> middleware should be a runtime dependency or an instance dependency. I 
>> think that is the core of what Rasmus is exploring here. It seems like he 
>> has decided it should not be a runtime dependency
>>
>> I don't feel it's a decision so much as a conclusion.
>>
>> I'd like it not to be the case, because it would surely be simpler, but 
>> the fact is that there isn't always precisely one delegate - which leads me 
>> to conclude it can't be a runtime dependency, or at least not if you want 
>> the model to reflect reality, which is something I always strive for.
>>
>
> This is the same reasoning I would use to argue for why the delegate 
> should be a runtime dependency. There is never precisely one delegate. The 
> state that is important at the point in time that the middleware is 
> executed is the request and the delegate. The middleware instance itself 
> does not depend on the delegate any more than it does on the request.
>
>  
>
>> > I'm not happy about the idea that every middleware is going to 
>> effectively require two classes be written
>>
>> Let's explore that problem.
>>
>> I think, first of all, you need to not think of this as "middleware 
>> consisting of two classes" - it's really two different classes, one is a 
>> handler, the other is middleware: they have different purposes in different 
>> contexts.
>>
>
> Again, this line of thought was directly related to David's proposal.
>
> I'm confused by what you said here, though, so maybe you can elaborate. 
> Not sure if this is talking about something else or about David's proposal 
> or?
>
> What I had said was not that "middleware would consist of two classes", 
> but that "writing middleware would require writing two classes." Since this 
> was about David's proposal, this was a factory and a middleware. Where I 
> previously had one middleware class, it turned into a middleware class and 
> a factory class. The example I shared showed the BEFORE code with one 
> MiddlewareInterface implementation and AFTER showed two classes, a 
> MiddlewareFactoryInterface and a MiddlewareInterface.
>
> What you said is something different. What do you mean by "one is a 
> handler, 

Re: Minimal HTTP middleware

[David Négrier]

ctor meaningful or interesting in the 
> first place, is that this is how a class defines it's dependencies. The 
> need for delegates in the first place arises from trying to remove control 
> from the middleware - but middleware components are going to have other 
> dependencies besides the delegate, and, as discussed, sometimes do not 
> depend on a delegate, and at other times depend on multiple delegates.
>
> You can make it seem as though there's always a delegate, but you're 
> actually trying to hide important facts - and you pay for that with 
> run-time exceptions, extra complexity, and middleware stacks that silently 
> malfunction because you didn't order the components correctly.
>
> > - it's harder to wire in DI containers
> > - lazy middlewares are doable but not as easy
>
> Both of these kind of revolve around the same concern.
>
> Yes, it's harder wire in DI containers for individual middleware 
> components.
>
> It's a matter of changing your thinking from the idea of middleware as 
> individual components.
>
> If you really think about it, the dispatchers for the current proposal's 
> middleware exists mainly to implement a means of making individual 
> middleware components work as a single unit.
>
> What I'm proposing makes middleware compose naturally as a single unit, 
> rather than having to "simulate" this composition at run-time by 
> synthesizing delegates inside a dispatcher.
>
> I can still only see one potential draw-back to what I'm proposing - that 
> middleware needs to be constructed up front in order to compose it.
>
> To me, given the real use-cases for middleware, that's a very small 
> draw-back, and I did already post very simple workarounds that you could 
> apply in those rare cases where a middleware component is rarely used and 
> expensive to construct.
>
> The large majority of middleware won't need those workarounds - but they 
> are very simple, and could be included in the standard package for 
> completeness.
>
> We will need the handler interface eventually, regardless of the current 
> middleware proposal - as discussed here:
>
> https://groups.google.com/forum/#!topic/php-fig/HD5meon7TX0
>
> This need has been widely discussed in issues and threads related to 
> PSR-15 and PSR-17 as well.
>
> We've been trying to avoid it, because we want PSR-15 to close, and as a 
> result, we ended up including it in the middleware proposal itself:
>
>
> https://github.com/http-interop/http-middleware/blob/master/src/DelegateInterface.php
>
> As you can see, this interface is precisely identical to that of any 
> general-purpose handler.
>
> Including this interface in the middleware proposal is bad, because the 
> handler-interface is by no means useful only in a middleware context.
>
> And the reason it's even possible to dispatch a middleware instance behind 
> this delegate-interface, is because that interface describes the only real 
> need and true purpose of the underlying implementation: takes a request, 
> returns a response. That's the only real transaction here. Everything else 
> is framework and artifacts.
>
> The thing is that any existing middleware can be ported to the 
> handler-interface, without losing any functionality at all, and while 
> making it's dependency on a delegate (or absence thereof) explicit.
>
> Take a trivial example like this middleware that adds a header to the 
> response:
>
> class XHelloMiddleware implements MiddlewareInterface {
> public function process(ServerRequestInterface $request, 
> DelegateInterface $delegate) {
> return $delegate->process($request)->withHeader("X-Hello", "Hello 
> World");
> }
> }
>
> We can extract a handler from this middleware, and the actual middleware 
> becomes just a dumb dispatcher:
>
> class XHelloHandler implements HandlerInterface {
> private $delegate;
> public function __construct(HandlerInterface $delegate) {
> $this->delegate = $delegate;
> }
> public function handle(RequestInterface $request) {
> return $this->delegate->handle($request)->withHeader("X-Hello", 
> "Hello World");
> }
> }
>
> class XHelloMiddleware implements MiddlewareInterface {
> public function process(ServerRequestInterface $request, 
> DelegateInterface $delegate) {
> $handler = new XHelloHandler($delegate);
> return $handler->handle($request);
> }
> }
>
> Note that this won't work because the interface names (DelegateInterface, 
> HandlerInterface) are different - but the method signatures are identical, 
> so ignore that for a moment and consider the fa

Re: Minimal HTTP middleware

[David Négrier]

Hey guys,

I think the main concerns with the approach highlighted by Rasmus have been 
raised by Matthieu:


- AFAIK it didn't work. And it was not tried in some weekend project: it 
> was built on Symfony's interfaces, so pretty solid stuff and it got a good 
> chance for success. On the other hand PSR-7 middlewares were incompatible 
> with most of the existing architectures at the time (incompatible with 
> Symfony for example) and without a standard interface (rather a "callable" 
> convention) and it worked out! So to me that's a clear sign.
> - it's harder to compose middlewares because they are all nested: the 
> "pipe" pattern was a huge help IMO in spreading the concept
> - it's harder to write reusable middlewares because you need to 
> standardize the constructor (see the Stack "convention" about the 
> constructor which is less than ideal)
> - it's harder to wire in DI containers
> - lazy middlewares are doable but not as easy



Yet, I understand concerns raised by Rasmus, especially regarding the fact 
that some middlewares may very well have several delegate (just imagine a 
middleware that dispatches on several middlewares based on the domain name 
for instance).

I just came up with another idea that might solve both problems. I'd be 
interested in your feedback.

The idea is this: 

- let's adopt a MiddlewareInterface the way StackPHP was doing it.
- let's provide a StackedMiddlewareFactoryInterface that can build a 
middleware when passed the "next" middleware. Those 
StackedMiddlewareFactoryInterface could be stacked/piped.


interface ServerMiddlewareInterface
{
public function __invoke(ServerRequestInterface $request) : 
ResponseInterface
}


interface StackedMiddlewareFactoryInterface
{
public function createMiddleware(ServerMiddlewareInterface $next) : 
Middleware
}


Middlewares that have several "next" middlewares (because they are actually 
dispatchers) would only provide an implementation for 
the ServiceMiddlewareInterface.

A typical implementation would look like this:

class SessionMiddleware implements ServerMiddlewareInterface
{
private $next;

public function __construct(ServerMiddlewareInterface $next)
{
$this->next = $next;
}

public function __invoke(RequestInterface $request)
{
// Do some stuff

// Then call the next middleware
return $this->next($request);
}
}

class SessionMiddlewareFactory implements StackedMiddlewareFactoryInterface
{
public function createMiddleware(Middleware $next) : Middleware
{
return new SessionMiddleware($next);
}
}


This solves both issues raised by Matthieu and by Rasmus.

A typical "server" would accept an array of middleware factories (we are 
piping factories instead of piping middlewares). It would then be able to 
wire all the middlewares together starting with the last in the array and 
going up.

This plays nice with DI containers, and is easy to understand.

What do you think?
David.




Le lundi 24 avril 2017 13:59:35 UTC+2, Rasmus Schultz a écrit :
>
> Having just replied, I now realize what you probably meant, haha ;-)
>
> You're saying the name of the interface should be handler, not middleware, 
> right?
>
> So yeah, I agree - some handlers may be middleware, but that's the role of 
> the component in some context, it's not what makes it a handler. 
>
> I honestly hadn't thought much about the interface name - was more 
> concerned with presenting the concept :-)
>
>
>
> On Mon, Apr 24, 2017 at 1:57 PM, Rasmus Schultz  > wrote:
>
>> Hi Michael,
>>
>> I'm at work right now, so I'll just comment on middleware pattern issue.
>>
>> Yeah, I think shelf is what I was looking at when I picked up the idea.
>>
>> From the documentation:
>>
>> > A handler is any function that handles a shelf.Request and returns a 
>> shelf.Response. It can either handle the request itself--for example, a 
>> static file server that looks up the requested URI on the filesystem--or it 
>> can do some processing and forward it to another handler--for example, a 
>> logger that prints information about requests and responses to the command 
>> line.
>> > 
>> > The latter kind of handler is called "middleware", since it sits in the 
>> middle of the server stack. 
>>
>> So I'm not the only who thinks it's fair to call this "middleware".
>>
>> The fact that many other types of handlers would be able to adhere to the 
>> same interface signature should be additional huge benefit - a router, for 
>> example, could implement that interface directly, making it useful as a 
>> handler anywhere, not just as middleware.
>>
>> It's one of the things I like about this pattern - it fits for so many 
>> different scenarios, which means these components will potentially useful 
>> in so many cases.
>>
>> We'll need that interface under any circumstances - I would be totally 
>> fine with terming it a handler rather than middleware interface, because it 
>> is 

Re: Service providers PSR: seeking members for a working group

[David Négrier]

Hey guys,

Thanks a lot for all the feedback.

Before we form a working group, it might be a good idea to have a clear 
idea of where we are headed. We are currently exploring 2 alternative 
options.

The first one is : 
https://github.com/container-interop/service-provider/issues/
The alternative one, proposed by Rasmus is 
here: https://github.com/container-interop/service-provider/issues/40

I'd love to have some feedback of you above those 2 proposals.
Maybe the first step would be to "watch" 
https://github.com/container-interop/service-provider and then send us some 
feedback in the related issues?

Best regards,
David.


Le vendredi 14 avril 2017 20:45:37 UTC+2, Stephan Hochdörfer a écrit :
>
> I'd love to help to drive this forward!
>
> Am Dienstag, 28. März 2017 12:01:48 UTC+2 schrieb David Négrier:
>>
>> Hey list!
>>
>>
>> PSR-11 has been accepted so we have standardized how to fetch entries 
>> from containers.
>>
>> The next logical step is to find a common way to put things into a 
>> container. More generally, the goal we are seeking is to make it possible 
>> for a package author to provide/modify entries in any container (rather 
>> than having to write a module/bundle for each framework as it's the case 
>> today as I described in this talk: 
>> https://thecodingmachine.github.io/forumphp2016talk/index_en.html#60).
>>
>>
>> Let's be clear that the goal is NOT to define a single way of configuring 
>> a container. Each container has its own strategy (configuration files, 
>> autowiring, PHP code...) that makes it worthwhile. What we are trying here 
>> is to find an additional *shared* way of putting things into a container 
>> specifically for package authors. Because it's almost impossible for 
>> package authors to write a bridge for every framework out there).
>>
>>
>>
>> Also, since FIG 3.0 has passed, it's time that we officially create a 
>> working group.
>>
>>
>> As a reminder, we (the container-interop participants) explored several 
>> strategies:
>>
>>
>> - unified file format
>>
>> - common interfaces for container definitions
>>
>> - common interfaces for dumping PHP code representing container 
>> definitions
>>
>> - service providers
>>
>>
>> I have summarized this in those 2 blog posts: 
>> https://www.thecodingmachine.com/psr-11-an-overview-of-interoperable-php-modules/
>>  
>> and 
>> https://www.thecodingmachine.com/psr-11-get-ready-for-universal-service-providers/
>>  
>> .
>>
>>
>> The conclusion we reached was that standardized service providers are the 
>> way to go. Among many criteria, they are easy to write, and if done right, 
>> can be properly optimized by compiled containers.
>>
>>
>> We started working on it at 
>> https://github.com/container-interop/service-provider/
>>
>>
>> Work is well advanced: we have prototype integrations available with the 
>> major frameworks out there.
>>
>>
>> There is still a lot of work to be done:
>>
>>
>> - Recently, Rasmus Schultz came up with an alternative proposal. The idea 
>> is that rather than trying to provide factories to the containers (what 
>> service providers do), a module could provide its own container and publish 
>> to the "main container" the list of entries it contains. Rasmus detailed 
>> the idea here: 
>> https://github.com/container-interop/service-provider/issues/40 . This 
>> idea looks a bit like the "delegate lookup feature" that was removed from 
>> PSR-11 in the philosophy (several containers running side-by-side), but is 
>> different in the implementation. I'd be interested to gather feedback from 
>> the community on Rasmus' proposal (I suspect it might be complementary to 
>> container-interop/service-provider rather than opposite)
>>
>> - With the current proposal, we can already add services and extend 
>> existing services. We need to know if we want to be able to do more (like 
>> adding/extending services conditionally based on the container's 
>> configuration). More generally, we need to discuss the exact scope of the 
>> PSR (limited to simple use cases? extended?)
>>
>> - Finally, there will be a huge amount of work waiting for us in the 
>> nitty-gritty (exceptions handling, etc...)
>>
>>
>> I'm hereby calling *interested members to step up* to create a working 
>> group, and for member projects to give as much feedback as possible. PSR-11 
>> has made a big leap forward in the very last days bec

Re: Service providers PSR: seeking members for a working group

[David Négrier]

eps coming up 
> again and again, as I seem to have described a solution which involves 
> multiple containers. Of course, for this to work some sort of lookup 
> delegation has to be in place.
>
> With regard to "sharing the same namespace", that's true. Especially true 
> in an environment like a CMS, where you expect many plugins in one system 
> to provide services while being ignorant of other plugins' services. For 
> this reason, we prefix the services which are scoped to specifically the 
> plugin, or the plugin's extension. Internally, we have a method often 
> called `_p()` which prefixes a service ID with something that is configured 
> on the service provider. So, when we want to scope something to the 
> particular plugin, or we want to retrieved something scoped to the plugin 
> from its service provider, we pass the key through that method first; 
> otherwise, if we want something that is globally scoped, e.g. WP's DB 
> connection, we don't use that method.
> Maybe by optimizing and formalizing this approach it could be possible to 
> solve the issue of namespaces.
>
> As for cases where one team doesn't know what another team is doing - 
> maybe they are different teams in the same organisation, or independent 
> extension developers - I don't feel that this is a problem. Teams that work 
> in the same organisation simply need to coordinate their effort if they are 
> working on adjacent/overlapping areas, such as decide who has authority to 
> develop the database-related services in a period of time. In any case, 
> generally, when you consume some API, you need to know about that API. You 
> don't go invoking/declaring random functions and instantiating/declaring 
> random classes willy-nilly; instead, you research what the available API 
> is. Same thing here: if you are consuming services provided by somebody, 
> you research what they provide. Otherwise, you run into a conflict, which 
> has to be resolved, and that's OK. It's the same thing with functions and 
> classes. I don't believe that the mechanism of conflict resolution is in 
> the scope of a service provider standard.
>
> On Tuesday, March 28, 2017 at 12:01:48 PM UTC+2, David Négrier wrote:
>>
>> Hey list!
>>
>>
>> PSR-11 has been accepted so we have standardized how to fetch entries 
>> from containers.
>>
>> The next logical step is to find a common way to put things into a 
>> container. More generally, the goal we are seeking is to make it possible 
>> for a package author to provide/modify entries in any container (rather 
>> than having to write a module/bundle for each framework as it's the case 
>> today as I described in this talk: 
>> https://thecodingmachine.github.io/forumphp2016talk/index_en.html#60).
>>
>>
>> Let's be clear that the goal is NOT to define a single way of configuring 
>> a container. Each container has its own strategy (configuration files, 
>> autowiring, PHP code...) that makes it worthwhile. What we are trying here 
>> is to find an additional *shared* way of putting things into a container 
>> specifically for package authors. Because it's almost impossible for 
>> package authors to write a bridge for every framework out there).
>>
>>
>>
>> Also, since FIG 3.0 has passed, it's time that we officially create a 
>> working group.
>>
>>
>> As a reminder, we (the container-interop participants) explored several 
>> strategies:
>>
>>
>> - unified file format
>>
>> - common interfaces for container definitions
>>
>> - common interfaces for dumping PHP code representing container 
>> definitions
>>
>> - service providers
>>
>>
>> I have summarized this in those 2 blog posts: 
>> https://www.thecodingmachine.com/psr-11-an-overview-of-interoperable-php-modules/
>>  
>> and 
>> https://www.thecodingmachine.com/psr-11-get-ready-for-universal-service-providers/
>>  
>> .
>>
>>
>> The conclusion we reached was that standardized service providers are the 
>> way to go. Among many criteria, they are easy to write, and if done right, 
>> can be properly optimized by compiled containers.
>>
>>
>> We started working on it at 
>> https://github.com/container-interop/service-provider/
>>
>>
>> Work is well advanced: we have prototype integrations available with the 
>> major frameworks out there.
>>
>>
>> There is still a lot of work to be done:
>>
>>
>> - Recently, Rasmus Schultz came up with an alternative proposal. The idea 
>> is that rather than trying to provide factories to the contain

Service providers PSR: seeking members for a working group

[David Négrier]

 

Hey list!


PSR-11 has been accepted so we have standardized how to fetch entries from 
containers.

The next logical step is to find a common way to put things into a 
container. More generally, the goal we are seeking is to make it possible 
for a package author to provide/modify entries in any container (rather 
than having to write a module/bundle for each framework as it's the case 
today as I described in this talk: 
https://thecodingmachine.github.io/forumphp2016talk/index_en.html#60).


Let's be clear that the goal is NOT to define a single way of configuring a 
container. Each container has its own strategy (configuration files, 
autowiring, PHP code...) that makes it worthwhile. What we are trying here 
is to find an additional *shared* way of putting things into a container 
specifically for package authors. Because it's almost impossible for 
package authors to write a bridge for every framework out there).



Also, since FIG 3.0 has passed, it's time that we officially create a 
working group.


As a reminder, we (the container-interop participants) explored several 
strategies:


- unified file format

- common interfaces for container definitions

- common interfaces for dumping PHP code representing container definitions

- service providers


I have summarized this in those 2 blog posts: 
https://www.thecodingmachine.com/psr-11-an-overview-of-interoperable-php-modules/
 
and 
https://www.thecodingmachine.com/psr-11-get-ready-for-universal-service-providers/
 
.


The conclusion we reached was that standardized service providers are the 
way to go. Among many criteria, they are easy to write, and if done right, 
can be properly optimized by compiled containers.


We started working on it at 
https://github.com/container-interop/service-provider/


Work is well advanced: we have prototype integrations available with the 
major frameworks out there.


There is still a lot of work to be done:


- Recently, Rasmus Schultz came up with an alternative proposal. The idea 
is that rather than trying to provide factories to the containers (what 
service providers do), a module could provide its own container and publish 
to the "main container" the list of entries it contains. Rasmus detailed 
the idea here: 
https://github.com/container-interop/service-provider/issues/40 . This idea 
looks a bit like the "delegate lookup feature" that was removed from PSR-11 
in the philosophy (several containers running side-by-side), but is 
different in the implementation. I'd be interested to gather feedback from 
the community on Rasmus' proposal (I suspect it might be complementary to 
container-interop/service-provider rather than opposite)

- With the current proposal, we can already add services and extend 
existing services. We need to know if we want to be able to do more (like 
adding/extending services conditionally based on the container's 
configuration). More generally, we need to discuss the exact scope of the 
PSR (limited to simple use cases? extended?)

- Finally, there will be a huge amount of work waiting for us in the 
nitty-gritty (exceptions handling, etc...)


I'm hereby calling *interested members to step up* to create a working 
group, and for member projects to give as much feedback as possible. PSR-11 
has made a big leap forward in the very last days because "big players" 
joined the party a bit late :). For this PSR, it would be great to have 
some feedback from you guys early on in the process.


++

David.

Twitter: @david_negrier

Github: @moufmouf

-- 
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/1573992a-355d-42a8-bd1f-c53ebaa43fd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

>
>
> > 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 January: Deadline for any PSRs which entered review before the 17th 
> December to form a Working Group with a CC sponsor if they failed their 
> approval vote/didn’t get to their approval vote in time
>  
> Where's a 17th deadline for January? In general, I don't think rushing 
> specifications because of a strict dead line is a good thing.
>

Actually, the updated timeline is here: 
https://groups.google.com/forum/#!msg/php-fig/FU_IJjrIJSs/AtCevnZsAQAJ

> 17th January: Latest date for any PSRs to enter review under the old 
system
> 31st January: Latest date for any PSRs to start approval votes under the 
old system

Honestly, we are not rushing anything. The PSR was been discussed for 
years, first under container-interop and now in PSR-11. It went through 2 
review periods and we are just discussing a minor issue (IMHO)

++
David.

-- 
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/a625409c-72da-4fa6-8cf4-33b662cb54d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

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  | PR 1 | PR 2 | PR 3
--|--|--|---
Chuck Burgess |  --  |  --  |  ++
Daniel Plainview  |  ??  |  ??  |  --
David Négrier |  ++  |  ++  |  -
Larry Garfield|  --  |  --  |  ++
Matthieu Napoli   |  ++  |  +   |  +
Matthew Weier O'Phinney   |  -   |  ++  |  -
Nicolas Grekas|  ??  |  ++  |  ??
@unkind   |  ??  |  -   |  ??


Sum of (totally not scientific) results so far:

PR 1: +4/-5
PR 2: +7/-5
PR 3: +5/-4

So overall, it's a debated idea. I'm sure by tweaking a bit the numbers, we 
could get whatever result we want.

What I find interesting however, is that both Matthew Weier O'Phinney (Zend 
Framework) and Nicolas Grekas (Symfony) agree on this. And since they are 
representing 2 major DI containers, I guess we should listen to them 
carefully.

++
David

-- 
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/6a519848-a45b-401e-a111-92c79cdb0860%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

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 MissingDependencyException*
Link: https://github.com/php-fig/fig-standards/pull/870/files

This PR simply improves the current wording. It is easier to understand but 
is strictly equivalent to PSR-11 as it is today.


*PR 2: NotFoundExceptionInterface CAN bubble up*
Link: https://github.com/php-fig/fig-standards/pull/869/files

This PR let's NotFoundExceptionInterface bubble up. So a 
`NotFoundExceptionInterface` means either "entry not found" OR "missing 
dependency". The user can make the difference between the 2 using the `has` 
method.

*PR 3: NotFoundExceptionInterface CANNOT bubble up, but we add a 
MissingDependencyException*
Link: https://github.com/php-fig/fig-standards/pull/871/files

This PR adds an explicit MissingDependencyExceptionInterface.


Could I ask each of you to have a brief look at these PR and to tell us how 
you like those?
Also, for the voting member, please indicate* if one of these PRs would 
change your vote* from -1 to +1 (or the other way around)


Ok, so I'm opening this "flash poll" so I'll start:

*PR 1: Status Quo *https://github.com/php-fig/fig-standards/pull/870/files

++: I'm happy with the rewording, thanks to Nicolas comments.


*PR 2: NotFoundExceptionInterface CAN bubble up *
https://github.com/php-fig/fig-standards/pull/869/files

++: I'm equally happy with this proposal. Looking at most container-interop 
implementations (for instance acclimate), they failed to propertly prevent 
NotFoundExceptionInterface from bubbling up. So they are actually already 
implementing this PR (by accident).

*PR 3: NotFoundExceptionInterface CANNOT bubble up, but we add a 
MissingDependencyException *
https://github.com/php-fig/fig-standards/pull/871/files

-: I could perfectly live with an explicit 
MissingDependencyExceptionInterface (it cannot break anything), but as 
explained earlier, I find no good reason to catch it, and it prevents us 
from migration Container-interop to PSR-11 automatically. So if possible, 
I'd like to avoid that (but this is not a show stopper for me and I'm ok to 
go that way if needed)

Please answer this as soon as possible (since if we do any big changes to 
the PSR, tomorrow is the last day we can put PSR-11 for review).

++
David.

-- 
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/398f3c10-6e15-4248-ae89-2193968cffa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

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 before.


Namely:

   - The NotFoundExceptionInterface duplicates the concept of the has 
   method (in Nicolas post)
   - Using exceptions for control flow is often a questionable design 
   choice (in Matthew post)

Based on these 2 assertions (I agree with both), we should question the 
usefulness of NotFoundExceptionInterface as it is defined today.


We spent a lot of time to make sure that containers implementing PSR-11 are 
differentiating the NotFoundExceptionInterface from a "missing dependency 
exception" (that should exist in the container even if it is not 
standardized). This involves that implementing containers MUST catch the 
NotFoundExceptionInterface and rethrow another exception. So we are forcing 
an "implementation detail" into implementors.


And I've come to realize that contrary to what I believed, we absolutely 
don't need that.


The change I'm proposing is dead simple: 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.


If a user of a container wants to make the distinction between "not found" 
and "missing dependency", he can simply perform a call to has before 
calling get:


if (!$container->has($id)) {// The requested instance does not exist// 
Let's do some stuff like display an error messagereturn;}try {$entry = 
$container->get($id);} catch (NotFoundExceptionInterface $e) {// Since the 
requested entry DOES exist, a NotFoundExceptionInterface means that a 
dependency is missing!}


Advantages:

   - it is dead simple
   - we don't dictate that NotFoundExceptionInterface must not bubble up 
   (no forced catch and rethrow, which feeled a bit flacky)
   - containers can do whatever they want: 
  - either let NotFoundExceptionInterface bubble up
  - or catch the NotFoundExceptionInterface and wrap it in a 
  "MissingDependencyException" of their own that must itself implement the 
  NotFoundExceptionInterface
   
Inconvenient:

   - slight incompatibility with container-interop, since in 
   container-interop, the "MissingDependencyException" was not supposed to 
   implement the NotFoundExceptionInterface (this is actually not clearly 
   stated in the container-interop documentation)


The more I think about it, the more I'm seduced by this solution. It is 
simple, it leaves complete freedom to implementors, and container users can 
still figure out if the exception they get is a "not found" or a "missing 
dependency" with a simple has call.


It also enforces best practices as users that want to check if an entry 
exists will use has instead of NotFoundExceptionInterface (the exception 
can no more be used for control flow)


Note: I haven't had a chance to speak with Matthieu, the other editor, 
about it yet since deadlines are tight, I'm sharing it right now. Matthieu, 
if you think this is foolish, we can cancel that.


As you can see, the PR makes PSR-11 even more simple, which is generally a 
good sign: https://github.com/php-fig/fig-standards/pull/869


What do you guys think?


++

David.

-- 
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/228fa8aa-1046-4598-a3dc-e8c3a4ca2037%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

> > > 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 helps. What does missing mean? Eg does 
> a brokenly configured first level service qualify as such? 
> > Reasoning from the inside of the container, you may say no. 
> > But reasoning from the outside, the user might expect a yes, so that eg 
> a chained-container can continue with the next container in the chain 
> (provided NotFoundExceptionInterface VS ContainerExceptionInterface could 
> be the trigger to decide if the chain should break or continue? what is it 
> for otherwise? doesn't that concept duplicate the "has()" method?) 
>
> This sounds like using exceptions for control flow, which is often a 
> questionable design choice. 
>
> I agree with Nicolas here, however, in that I'd likely allow the 
> NotFoundExceptionInterface to bubble out in this case, not for control 
> flow, but 
> to make it clear to the end user that a dependency is missing from the 
> container. 
>


Ok, let me just explain how we decided to handle exceptions this way. This 
might help the debate here.

*Our first idea was that the NotFoundExceptionInterface should have a 
`getMissingIdentifier()` method.*

Let's pretend you are using a PSR-11 container. In my case, I was building 
a UI that was letting you explore a container. The user types an entry 
name, the UI displays informations about the returned service.

If I catch a NotFoundExceptionInterface, it has a very different meaning if 
the NotFoundException is thrown by my first `get` call or an inner get 
call. In one case, the user typed a buggy entry name, in the other case, 
the container is misconfigured.

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 
exist
} else {
// Oops, I should not have caught that in the first place, I don't 
know what to do with this, let's rethrow this.
throw $e;
}
}

When someone catches the "NotFoundException", the "if" statement inside the 
"catch" was almost systematic.

This is because we actually have 2 different exceptions. One is "the user 
provided an invalid identifier", and the other is: "the container 
configuration somewhere has an error, with probably an invalid identifier 
stored".

So we decided that those 2 exception cases should be treated differently.

By restricting the scope of the NotFoundExceptionInterface to the first 
outermost `get` call, one user can write:

try {
$service = $container->get($id);
} catch (NotFoundExceptionInterface $e) {
// Display an error message to the user saying the service does not 
exist
// No need to bother checking that the caught exceptions relate to $id, 
this is sure.
}

Now, I understand this can be discussed in many ways.

For instance, one could argue that my example is buggy, because I'm using 
exceptions for control flow. If I'm dealing with user input, I should first 
use "has" (and therefore, I'm sure the entry does exist, so if a 
"XxxNotFoundException" is triggered, it has to be a "missing dependency 
exception".

I don't think there is "one and only one" truth regarding the definition of 
exceptions. It really depends on where one puts the cursor, and the FIG has 
never defined clearly which exceptions should be part of a PSR and which 
should be out of it.

@Nicolas, @Mwop, if you think the exception handling of PSR-11 can be 
improved, could you describe precisely what you would change, why and how? 
Is this a wording issue or is this a design issue? Also, is this completely 
blocking you from implementing PSR-11? And is this a subject that could 
change a -1 to a +1 vote (that question is for Fabien and Larry :) )

As you might guess, I'm pretty happy with the exceptions the way they are 
defined currently.

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 your comments as 
quickly as possible.

++
David.

-- 
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/39878c6b-d9ce-4db3-ae1d-85e4ce1db73e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

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 you see other people that contributed and are missing from the 
contributors list, please tell us in this thread, or even better, submit a 
PR: 
https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#93-contributors

Regards,
David.
Twitter: @david_negrier
Github: @moufmouf

Le mardi 10 janvier 2017 13:02:34 UTC+1, Stefano Torresi a écrit :
>
> 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 spec 
> is not up to par to speak their mind before Friday the 13th! To accomplish 
> this, I would also suggest to spam this thread all around your favourite 
> mediums.
>
> That said, I personally think the spec is sound. I'm sure this PSR will be 
> a huge success, and will set an important precedent regarding 
> prior-to-acceptance adoption of PSR drafts, paving the road for future WGs.
>
> See you around.
>
> Il giorno lun 9 gen 2017 alle ore 16:46 Chuck Burgess  > ha scritto:
>
>> 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 possibility of starting a vote
>>> under the existing FIG 2.0 by-laws possible immediately thereafter.
>>>
>>> The changes since the previous review period started include:
>>>
>>> - All exceptions were moved into the `Psr\Container` namespace
>>> (instead of the `Psr\Container\Exception` namespace as was done
>>> previously).
>>>
>>> - Clarifications were added around inclusion of OPTIONAL parameters to
>>> the `get()` method by _implementing libraries_, noting that doing so
>>> is allowed by PHP, but discouraged, due to ambiguity in behavior
>>> between implementations.
>>>
>>> - Added a formal definition of an entry identifier for use with
>>> `get()` and `has()`, noting that these may be any valid non-empty
>>> string.
>>>
>>> - Removed all verbiage around the delegate lookup feature. Consensus
>>> was that this is an interesting feature, but something that may be
>>> implemented by libraries while still following the specification. If
>>> anybody feels the need to formalize this detail, it can be done in a
>>> later specification without breaking compatibility with the current
>>> proposal.
>>>
>>> We have also rejected the proposed
>>> `MisconfiguredServiceExceptionInterface`.  David has previously noted
>>> reasons not to include it
>>> (https://groups.google.com/d/msg/php-fig/2pnhudRUpQg/ewoGoNtFCgAJ),
>>> which received no rebuttal. We feel it does not add value to consumers
>>> currently, would likely be problematic in terms of performance, and
>>> dictates too many details around implementation.
>>>
>>> Please review the specification again at this time, and let us know as
>>> soon as possible if you see any potential problems that remain to be
>>> addressed.
>>>
>>> --
>>> Matthew Weier O'Phinney
>>> mweiero...@gmail.com 
>>> https://mwop.net/
>>>
>>> --
>>> 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/CAJp_myU%2BwCPNbmhdMGztNvzmgrjpO-giGBE8fuuJT4Lj%3DDVVGg%40mail.gmail.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+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/CANsgjnuVHjWScCCkuuf5LkT7OHXZAa%3DmvyvRVMB4sC%3DXLOhcVA%40mail.gmail.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 

Re: [VOTE] First Core Committee Elections

[David Négrier]

1. David Négrier

2. Beau Simensen

3. Matthew Weier O’Phinney

4. Korvin Szanto

5. Larry Garfield
6. Lukas Kahwe Smith

7. Sara Golemon

8. Gary Hockin
9. Stefano Torresi  
10. Tobias Nyholm

-- 
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/4ca8940f-c6f3-4fde-8b4f-6cc03cd5c500%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Exceptions

[David Négrier]

Hi people!

This issue has been standing for the last 2 weeks with no activity.

Let's revive this and try to close it.

There is currently one PR made by Larry 
(https://github.com/php-fig/fig-standards/pull/844) proposing to add a 
"MisconfiguredServiceExceptionInterface" to PSR-11. There is support for 
this PR from @GeeH and from the people attending PHPWorld (although we 
don't know who was at this meeting). Larry, could you let us know who 
attended the FIG meeting at PHPWorld?

Also, Matthieu, Daniel and myself are reluctant to add this exception 
because we don't see why you would catch this exception? The question has 
been asked by Matthieu and so far, we haven't had any proposition of a use 
case where catching "MisconfiguredServiceExceptionInterface" would make 
sense. If you can highlight such a use case, please let us know.

Meanwhile, I've been thinking a bit more about what would be the impact of 
adding a "MisconfiguredServiceExceptionInterface" to PSR-11.

Impact of a "MisconfiguredServiceExceptionInterface"

I realized a few days ago that adding this exception could actually be 
detrimental to users and hinder adoption.

Let me give you a sample based on Simplex (the Pimple 3 PSR-11 fork):

The PR reads:

> A call to the get method for a a service that is defined but cannot be 
instantiated due to misconfiguration, missing dependency, or other issue 
related to the container MUST throw a 
Psr\Container\Exception\MisconfiguredServiceExceptionInterface.

Now, let's assume we have a Simplex container declared like this:

$container->set('boom', function() {
// $container variable is not defined, this will fail.
return $container->get('foo');
});

$container->set('cache.apcu', function() {
// Let's say the constructor below will throw an exception because APCU 
is not available on my server.
return new ApcuCache();
});


Here, I have 2 entries that will cause errors / throw exceptions.

When a call:

- $container->get('boom')
- $container->get('cache.apcu')

should I get a 
'Psr\Container\Exception\MisconfiguredServiceExceptionInterface' ?

This question is hard to answer! Do we consider that what happens in a 
factory is part of the container or not?

I would certainly not wrap `$container->get('boom')` in an exception (so it 
means the container should not be catching Throwable). It makes absolutely 
no sense as this is most typically an "unchecked" exception. And yet, if 
you have a look at the wording of the PR, to me, it qualifies as a 
"misconfiguration" of the container.

So what about the exception thrown by `$container->get('cache.apcu')`? If 
the container wraps it into a 'MisconfiguredServiceExceptionInterface' 
exception, this makes catching the initial exception a lot harder.

Have a look at this other service:

// This service returns an APCU cache when available, a file cache service 
otherwise
$container->set('best.possible.cache', function($container) {
try {
return $container->get(cache.apcu);
} catch (NoApcuExtensionException $e) {
return $container->get(cache.file);
}
});

The code above will only work if the container does not catch the 
exceptions. Otherwise, we would need to write something like:

$container->set('best.possible.cache', function($container) {
try {
return $container->get(cache.apcu);
} catch (MisconfiguredServiceExceptionInterface $e) {
if ($e->getPrevious() instanceof NoApcuExtensionException) {
return $container->get(cache.file);
} else {
throw $e;
}
}
});

I'm sure we all can agree that this is a code-smell :)

So we have a problem because the wording surrounding 
'MisconfiguredServiceExceptionInterface' will be extremely hard to get 
right. It should catch enough, but not too much while not saying exactly 
what to catch because this is container specific...

Another issue: depending on the container used, the exceptions are not 
thrown at the same moment. Let's consider a "CyclicDependencyException". It 
is fair to think it should implement the '
MisconfiguredServiceExceptionInterface'. But in compiled containers, this 
exception will be thrown at build time (so not when calling `get`). 
Actually, I expect most exceptions to be thrown at build time for 
compiled/cached containers, and I expect runtime containers to throw very 
few exceptions apart the NotFoundException / DependencyMissingException.

So my feeling is that the 'MisconfiguredServiceExceptionInterface' is 
opening a can of worms. It will be very hard to define precisely what goes 
in and what goes out of this exception.

And we haven't even heard of a practical use case yet.

On the other end, there is *one real impact* to adding this exception:

Existing containers implementaing container-interop might need a *major 
version bump* to be compatible with PSR-11 (because some exceptions that 
would previously have bubbled up could be wrapped inside a '

Re: [PSR-11] Review of the delegate lookup feature

[David Négrier]

Le jeudi 17 novembre 2016 18:58:24 UTC+1, Larry Garfield a écrit :
>
> My main concern is that as presented the delegate 
> feature is not really a feature, more a "by the way, here's this cool 
> thing you can do." 


It's more something like: "by the way, if you implement DDL, your users can 
do cool things", but I get your point.
 

> The composite container isn't defined at all, and as 
> you note the question of what happens when the delegate container has 
> its own services is also completely undefined. 


The wording certainly needs some polishing.

Regarding what happens if a composite container contains its own services, 
I would look at it this way: such a container is both a "pure composite 
container" and a "real container".

See the picture below:

<https://lh3.googleusercontent.com/-SETcQ3U-FPw/WDLUW6BVdmI/B9w/bTgPH5j6JoAIg12o1DxSCXgMWnhF9_AXACLcB/s1600/advanced_composite.PNG>
In the case of a composite container with entries, I would expect this 
composite container to have methods like: "prependChildContainer" or 
"appendChildContainer". Everything else is exactly the same as described:

- Container 1, 2 and 4 should implement DDL. They should refer to the root 
container (in this case the "composite container with entries").

For the sake of crazyness, we could also envision a truly complex case (I 
don't know what this could be used for in real-life). See picture below.

<https://lh3.googleusercontent.com/-g2Rrcbzyrcg/WDLWC6jrZgI/B98/0fyH_XZXgtAFdVc1ItSmkCr6xnE8aINNQCLcB/s1600/root_composite.PNG>
Here, composite containers are nested and one composite container is 
containing entries. It still works :) Every container containing entries 
(including the composite one) must point back to the top-most container 
when looking for dependencies. It's as simple as that.




 

>  Yet that is a valid use 
> case, and in fact the main one that I'd see being useful: Allowing a 
> library to provide its own mini-container for its services, which then 
> simplifies adding a large and more complex library (Doctrine, Guzzle, 
> etc.) to an application without the need for a custom bridge 
> module/bundle/whatever. 
>
> It may be that case is better handled through the forthcoming container 
> registration spec.  If that's the case, then I see insufficient reason 
> to include DDL here.  


Agree. This use case would definitely be better handled through the 
forthcoming container registration PSR. Although you can indeed use DDL and 
composite containers to provide "one container per lib", it's not very 
efficient and also, there is no way you can easily "extend" a service from 
one lib into another (hence the need for another PSR). I'd not recommend 
this use case. The only use cases I envision are "migration" and "adding 
additional features" (as stated in my post above).


Yet, I still believe this is a useful (and unknown) design pattern and that 
including it in the PSR will increase interoperability between containers 
(even if it is seldomly used)

That being said, so far, we've been few to be truly vocal about this 
feature (lately, that's mostly me and XedinUnknown). I'd still like to get 
a bit more feedback before putting a nail in the coffin of DDL :s

@Larry, that's really great you could have a PHP-FIG IRL meeting at 
PHPWorld. Did you speak about the delegate lookup feature? Was there a 
general concensus there? Also, could you tell us who was present at this 
meeting?


Best regards,
David.

 

> If it is kept, it needs to be considerably 
> overhauled to clarify those many edge cases, and suggest, well, what if 
> anything would be more than a "by the way, this quirk would be 
> possible." 
>
> One or the other: Remove, or revamp to be more clear and useful. 
>
> -- 
>   Larry Garfield 
>   la...@garfieldtech.com  
>
> On Thu, Nov 17, 2016, at 10:30 AM, GeeH wrote: 
> > Thanks David for such a comprehensive roundup of what's being proposed. 
> I 
> > personally found the time and effort you put into explaining the problem 
> > a 
> > great help. 
> > 
> > I am against adding this functionality for reasons already stated - I 
> > believe it's out of the scope of this PSR and would be an implementation 
> > detail rather than an actual part of the standard. With that said, I am 
> > only slightly against it, we do something similar in Zend\ServiceManager 
> > where we allow people to travel up to the composite container (although 
> > it's not really a composite container as it can contain services) so I'm 
> > very interested in possibly using the pattern you explained in place of 
> > this. 
> > 
> > I'm not convinced it should be in the spec, but would hap

[PSR-11] Review of the delegate lookup feature

[David Négrier]

Ok folks!

I've been delaying this for a while to give some room for the rest of the
questions about PSR-11, but now is the time to dwelve into the details of
the delegate lookup feature :)

I know some of you have doubts about this part of the PSR, so the first
thing might be to decide whether we want to keep it or not. If we decide to
keep it, I'm sure there are plenty of things we can do to improve the
wording :)

(post is quite long and contains images. If it does not display well,
I cross-posted
here

)

*What is it?*

The *delegate dependency lookup feature* (let's call it DDL) is a *design
pattern.*
It is the only way we have found to compose containers.

*What problem does it solve?*

Let's admit you want to compose/chain containers (more on why you might
want to do this later).
To do this, you would typically use a "CompositeContainer
"
(a container without any entry whose role is to ask each "child" container
in turn "do you contain the entry I'm looking for?")

[image: composite.png]

The CompositeContainer is not enough. Let's admit container 1 contains your
controller. You fetch your controller. Your controller has a dependency on
your ORM's entity manager. If the entity manager is part of container 2,
container 1 will be unable to fetch it (because internally, it will perform
a call "$this->get()" to fetch the entityManager dependency. Similarly, the
entityManager should be able to fetch a dependency (for instance the
dbConnection) inside another container...

The delegate lookup feature simply states that containers should not fetch
their dependencies locally, but instead, they should fetch their
dependencies from the top-most container (in this example, this is the
CompositeContainer).

In our example, this would go like this:

- The framework asks for the "controller" entry to the CompositeContainer
- The CompositeContainer asks Container 1: "do you have "Controller".
Container 1 answers yes
- The CompositeContainer asks Container 1: "give me "Controller".
- Container 1 needs to fetch the "EntityManager" dependency, so Container 1
calls *$compositeContainer->get('EntityManager')*; (here! container 1 is
"delegating" the dependency lookup to the composite container)
- The CompositeContainer asks Container 1: "do you have "EntityManager"? =>
response is no.
- The CompositeContainer asks Container 2: "do you have "EntityManager"? =>
response is yes. The CompositeContainer asks Container 2: "give me
"EntityManager".
- ... and do on


*Do we want this?*

To be honest, PSR-11 is already useful without the DDL feature. The
ContainerInterface is enough to allow users to swap container
implementations.

Being able to compose containers is a nice feature, but it's optional.
PSR-11 can be useful without DDL.

*What are valid use cases for this?*

First of all, I do not expect major full-stack frameworks to use this. It
is obvious from the example above that there is a performance hit when
using a composite container (you have to ask each container in turn whether
it contains the instance you are looking for or not).

Frameworks very focused on performance (like Symfony full-stack) should
stay away from CompositeContainers (more on performance below).

Yet, here are a few use cases where composite containers are valuable:

1- Migration!

Let's admit you started a small app with Slim3 and Pimple. Your app is
getting bigger. You now have more than 200 services declared in Pimple and
you want to migrate away to something more powerful (maybe you want to
benefit from Autowiring or maybe you need lazy services for performance
issues...)
The DDL feature allows you to put Pimple side-by-side with your new
container of choice and migrate entries slowly, one by one. This is really
cool because it makes a daunting task a lot easier.

2- I don't care about performance, give me features!

Running containers side-by-side is a great away to enhance a container with
the features of another container. For instance, you could enhance your
existing container with a sidekick containers dedicated to creating aliases
or serving a "lazy" version of your services, etc...

Not everybody cares for container performance. For instance, if you are
doing async PHP (with ReactPHP or another lib), container performance is
not a concern at all (since services are created once at the beginning of
the script and are reused across requests).

*By the way, what is the real performance impact of using a
CompositeContainer and DDL?*

I've been doing some tests using a modified version of Symfony.
You can read my old article about the performance impact on DDL here
.
Spoiler alert: impact is quite low, I was not able to measure it.


*How do we implement this?*

DDL 

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

[David Négrier]

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 container any possible identifier from the proposed set of
characters.

Now, let's consider the container below:


class ConfigurationContainer implements ContainerInterface
{
public function get($id)
{
$value = getenv($id);
if ($value === false) {
throw new NotFoundException("Entry ".$id." not found.");
}
return $value;
}

public function has($id)
{
return getenv($id) !== false;
}
}


This container simply exposes the environment variables as entries. You
might say: "hey, this is not even a real 'container' ". And you are right.
Still, this piece of code can be very valuable if we use it along another
container (using the delegate dependency feature for instance).

Of course, since this container only exposes environment variables, and
since environment variables cannot contain ".", it does not fulfill the
criteria to be an eligible PSR-11 container (which makes me sad because in
my opinion, this is a legit use case).

At this point, I realize this might certainly be the right moment to speak
about the "delegate lookup feature" of PSR-11. I'll try to open a separate
thread regarding the "delegate lookup" feature in the next few days (busy
week!). Thinking about it might shed a different light on this particular
thread.

++
David.


Le lun. 14 nov. 2016 à 10:28, GeeH  a écrit :

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 "-" 

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

[David Négrier]

Hi Pedro,

First of all, I thank you again for your comments. Do not believe we do not 
consider them. Actually, your argument about the Liskov substitution 
principle got me thinking the last 24 hours (hence my lack of quick reply 
:) ) Your comments are always welcome as they force us to think harder 
about what we are doing and in the end, they lead to a better standard.

So... what about the Liskov Substitution Principle. Are we violating it?

>From Wikipedia: *Liskov's notion of a behavioral subtype defines a notion 
of substitutability for objects; that is, if S is a subtype of T, then 
objects of type T in a program may be replaced with objects of type S 
without altering any of the desirable properties of that program*

Liskov Substitution Principle does not state that "S" that is a subtype of 
"T" can be replaced with "S' " that is also a subtype of "T".

Also, we are subtyping an interface (not a class). To violate the LSP, the 
implementation must be "semantically different" from what is described in 
the documentation of the interface. So actually, the less we put in the 
documentation and the less we are likely to violate the LSP. In that 
regard, I'm leaning (like Matthew) towards solution 1 (let's simply remove 
the whole 2 sentences and let's not specify at all that 2 successive calls 
to "get" SHOULD return the same value. We simply don't care).

As such, I'm willingfully lowering the expectation a user can have on the 
interface (the interface does not say much about what a container is). 
Therefore, I'm putting the "burden" of checking that the container he is 
choosing actually does what he expects to do 

 (and 
is properly configured) But this is alright.

The more I think about it, the more I believe this is the right thing to do.

For the sake of the example, let's make a contraposition and let's try a 
"reductio ad absurdum".

If we want ANY implementation to be replaceable by ANY other 
implementation, we obviously need to define that 2 successive calls to 
"get" MUST return the same value.
But that's not enough. Currently, the spec states that "A call to get can 
return anything (a *mixed* value)"

We would need to rewrite that as: "Containers implementing this spec MUST 
be able to return anything (any possible *mixed* value returnable by PHP)".

At this point, we are actually dictating that the container implementations 
MUST support a way to define entries via a callback (because it is really 
the only way you can return any possible mixed value). For instance, it 
would be very hard for a container based on configuration alone to be able 
to return a resource, or a generator (which are valid return values).

Another solution could be to restrict the allowed return types (for 
instance: a container MUST only return objects, or a container MUST only 
return objects and scalars). If we write this, then Pimple and all 
containers supporting the creation of services via a factory (i.e. most 
containers out there) need to be rewritten to actually prevent the return 
of other values.

At this point, maybe you start to realize that having strong expectations 
on the behaviour of a container is actually "dictating" how it should work 
internally.

If you need yet another argument, let's have a look at PSR-6 and the values 
that are allowed to be passed: http://www.php-fig.org/psr/psr-6/#data

PSR-6 states that: *Implementing libraries MUST support all serializable 
PHP data types*
PSR-6 does not state that: *Implementing libraries MUST NOT support PHP 
data types that are not serializable*

Now, let's have a look at Stash's Ephemeral driver (
https://github.com/tedious/Stash/blob/master/src/Stash/Driver/Ephemeral.php)
This driver is essentially storing data in an array. This means that I can 
store a database connection or a GD image resource in this array (these are 
not serializable). It is absurd but it will work. Of course, if I do this, 
I cannot expect to switch from the Ephemeral driver to a MemcacheDriver 
later. Is it a problem with the Ephemeral driver? I don't think so. Does 
the Ephemeral driver violates the LSP? Nope. The Ephemeral driver is simply 
extending what is allowed by the PSR-6 and the user is having wrong 
expectations that these extended features are available in all 
implementations.


To sum it up, we are having this debate because counter-intuitively, PSR-11 
does not define what a container is. By not defining it, it leaves the user 
*in charge* of choosing a container that answers its needs. We could of 
course go the other way and define precisely what a container is, but 
containers are so different out there that we would be excluding most of 
them by doing so. If we go that way, we need a good reason to do it. But so 
far, I don't see a real use case good reason. Our experience with 
container-interop has 

Re: [CC][Nomination] David Négrier

[David Négrier]

Woot! Thanks a lot Michiel. I obviously accept your nomination. :)

--
David.

Le mercredi 9 novembre 2016 20:43:01 UTC+1, Michiel Rook a écrit :
>
> I hereby nominate David Négrier for the Core Committee!
>
> Michiel
>

-- 
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/30176e6e-ef1e-48e9-871d-6e2cf7ae4498%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internals][FIG 3.0] Extending Nomination Period & Delaying FIG 3.0 Transition

[David Négrier]

Hi Michael,

The PHP-FIG Core Commitee deserves to have the best members we can find. 
The 10 days timeline was certainly too short and if we need to choose 
between the respecting the fixed timeline or giving us more time to find 
the best people, I'm definitely for the later solution.

I'm not a voting member but I'm +1 on extending the Core Committee 
nomination period.

--
David.



Le mercredi 9 novembre 2016 18:09:44 UTC+1, Michael Cullum a écrit :
>
> Hi all,
>
> Does anyone have any objections to extending the Core Committee nomination 
> period one month and pushing the FIG 3.0 implementation timetable back a 
> month (so the new implementation date will be 1st February)?
>
> There are still a number of people looking to be nominated or considering 
> standing; meanwhile right now we only have 7 candidates when 15-20 would be 
> a much more appropriate number for a fair election and we think at least 12 
> at a minimum is still achievable if given a little more time.
>
> --
> FIG Secretaries
>

-- 
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/a45013d0-7c30-4cfc-906d-26a6921a82f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC Nomination Request] David Négrier

[David Négrier]

To all FIG project representatives:

I'm writing to the list today to request a nomination to the FIG 3.0 Core 
Committee.

If you read this list regularly, you probably already know me as the 
co-editor of PSR-11 and container-interop. I'm also the lead developer of 
Mouf  (a graphical DI framework) and Packanalyst 
 (the search engine that let's you find all 
classes implementing a given interface). Being a "small framework" author, 
I grew pretty fond of PHP-FIG as I see in its mission a great way to rely 
on others code without "vendor lock-in". I'm pretty sure the PHP-FIG is 
going in the right direction with FIG 3.0 as working groups are quite close 
to what we did with container-interop (test first, grow a user base, then 
standardize).

Just like Jason, I am asking for this nomination through the mailing list 
as I do not have a lot of strong personal relationships with any other FIG 
members at this time (even if I have interacted with many of you in the 
past months). I used to speak a lot with Beau, but he left the group a year 
ago. Also, to be honest, I probably would not ask for a nomination if there 
were dozens of framework leaders applying for the CC (that would really be 
the ideal situation for PHP-FIG). But there are currently some free seats 
at the table, so here I am! Any member project would be kind enough to 
endorse me? :)

Best regards,
David.

-- 
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/fe46aecc-4840-4a1c-88fb-92351aad5e3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Négrier]

t 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 end user badly screws up its configuration 
> and 
> >> decides to configure a non-shared event dispatcher, that's its problem 
> (it's 
> >> a bug), not a problem with PSR-11. Of course, with a more restrictive 
> PSR-11 
> >> (that would force shared services only), this kind of bug would not be 
> >> possible. But we loose compatibility with all the containers out there 
> and 
> >> it's just not worth it in my opinion. 
> >> 
> >> Finally, we will inevitably end up working on a PSR that defines how we 
> >> put things in a container. In this PSR, we will need to be very strict 
> >> regarding the fact that we set a shared or a non-shared service. 
> >> If you haven't done so yet, you should definitely take a look at 
> >> container-interop/service-provider. This project proposes a wa

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

[David Négrier]

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 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 in PSR-11 (or at least I want to be 
>> able to create an adapter for those) and putting a "MUST" in the 
>> requirements makes this impossible. So if we decide to force containers to 
>> always return the same value, we'd better have a very good reason to do so.
>>
>> Now, what is the real impact of this?
>>
>> You all seem to imply that if we don't put a "MUST" here, then we cannot 
>> "trust" the container to give us a usable instance. The container might be 
>> "vicious" and decide to fool its user by giving him a new instance while 
>> the user was expecting the same instance. But this is not how it works. The 
>> typical use case for ContainerInterface is to allow a consumer (like a 
>> router) to be "container agnostic". As a user, I can decide to plug any 

Re: [PSR-11] Review: remove the sentence about optional "get" parameters

[David Négrier]

Ok, I tried a synthesis of Matthieu's and Larry's point of view in this PR: 
https://github.com/php-fig/fig-standards/pull/831

Let me know if you find it acceptable.

David
--
Twitter: @david_negrier
Github: @moufmouf

Le jeudi 3 novembre 2016 15:54:32 UTC+1, Larry Garfield a écrit :
>
> Suggestion: Make no comment in the spec itself, but note in the metadoc 
> that "some existing implementations have extra optional parameters; that's 
> technically legal for backward compatibility but discouraged".  So that way 
> Symfony's DIC, for instance, can remain compatible but anyone writing a new 
> implementation knows they're not supposed to do that.
>
> --Larry Garfield
>
> On 11/03/2016 03:42 AM, Matthieu Napoli wrote:
>
> Hi Niklas, I think there is a misunderstanding.
>
> - if you use the interface, then you use the parameters defined in that 
> interface => so yes, you should NOT pass extra parameters (we agree on 
> that, that doesn't make sense)
> - if you don't use the interface but the implementation directly, then 
> it's OK to use the extra parameters (because you code against the 
> implementation)
>
> That's why OOP (and PHP) allows implementations to have more parameters 
> than defined in the interface (because you stay compatible with the 
> interface).
>
> Now we usually say "code against interfaces", because obviously that's 
> much better. But here for container interoperability we have to consider 
> the fact that not all frameworks can switch containers entirely. So some 
> pieces of code will still use the implementation, that's why we have to be 
> compatible with this.
>
> In any case, it doesn't make sense that an interface forbids extra 
> optional parameters, because again OOP and PHP allows it. The question is 
> whether we want to make that explicit or not in the document: I usually 
> like explicit because it removes confusion for implementors (DIC authors).
>
> Matthieu
>
> Le Jeu 03 nov 2016, à 09:21, Niklas Keller a écrit :
>
> So just to get this straight: we remove the sentence (because it sounds 
> weird to have it in a standard), but we agree that it's still completely 
> fine if implementations have extra *optional* parameters right?
>
>
> If it were completely fine, we wouldn't remove the sentence, no? Optional 
> parameters are *not* fine. It hurts interoperability. If a consumer passes 
> them, it assumes a concrete implementation. If the implementation is 
> swapped, they might be ignored, but it's even worse if that implementation 
> also has optional parameters, then they might be interpreted wrongly.
>
> Because we obviously want to keep all containers compatible.
>
>
> They *are* still compatible, because these parameters are *optional*, so 
> don't have to be provided. 
>
> I just don't want to force implementations to have exactly 1 parameter, 
> which doesn't make sense in PHP and in OOP in general
>
>
> Yes, it does make sense. If you only code to interfaces, optional 
> parameters that are not defined in the interface do not make sense. 
>
>

-- 
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/bff598b3-0448-4ab3-b5bf-be3faf16eeeb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Exceptions

[David Négrier]

, 
>> wat?"  If the parent container is going to catch it and handle it, then it 
>> needs to wrap that inner Not-Found with... something.  That something 
>> should be standardized.
>>
>> If I as the caller don't care which type of exception is thrown, well, 
>> that's where interfaces that cover both exceptions are helpful. :-)
>>
>> --Larry Garfield
>>
>> On 11/03/2016 03:53 AM, David Négrier wrote:
>>
>> @Larry: the DependencyNotFoundException was discussed quite recently.
>>
>> Here is the relevant link explaining the story behind it and why there is 
>> no DependencyNotFoundException: 
>> https://github.com/php-fig/fig-standards/pull/810
>>
>>
>> Le mercredi 2 novembre 2016 22:53:13 UTC+1, Matthieu Napoli a écrit : 
>>>
>>> Splitting off the main review thread, quoting Larry: 
>>>
>>> > 1) What other exceptions might get($id) throw besides 
>>> NotFoundException? 
>>>
>>> \Exception (because any exception could be thrown when creating 
>>> services) => are you suggesting we should document it in the standard?
>>>
>>> > 2) I would much prefer to see a DependencyNotFoundException defined 
>>> for 
>>> that case than leaving that up to individual implementers. Standard 
>>> error handling is just as important if not moreso than the happy path.  
>>>
>>> Why/when would one want to catch that exception (use case)? This is not 
>>> a need we have seen when using container-interop as of now, I'm of course 
>>> not against adding new stuff but we should do it for a reason.
>>>
>>> Matthieu
>>>
>> -- 
>> 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/c341150d-2834-42ba-a7ac-058510f4cb7c%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/c341150d-2834-42ba-a7ac-058510f4cb7c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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/79211317-71e6-4763-92e0-328d292e9484%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Exceptions

[David Négrier]

@Larry: the DependencyNotFoundException was discussed quite recently.

Here is the relevant link explaining the story behind it and why there is 
no DependencyNotFoundException: 
https://github.com/php-fig/fig-standards/pull/810


Le mercredi 2 novembre 2016 22:53:13 UTC+1, Matthieu Napoli a écrit :
>
> Splitting off the main review thread, quoting Larry:
>
> > 1) What other exceptions might get($id) throw besides NotFoundException? 
>
> \Exception (because any exception could be thrown when creating services) 
> => are you suggesting we should document it in the standard?
>
> > 2) I would much prefer to see a DependencyNotFoundException defined for 
> that case than leaving that up to individual implementers. Standard 
> error handling is just as important if not moreso than the happy path. 
>
> Why/when would one want to catch that exception (use case)? This is not a 
> need we have seen when using container-interop as of now, I'm of course not 
> against adding new stuff but we should do it for a reason.
>
> Matthieu
>

-- 
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/c341150d-2834-42ba-a7ac-058510f4cb7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Négrier]

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+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/5fa24b40-1b48-4c0e-907b-3fc88cc965dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[David Négrier]

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 in PSR-11 (or at least I want to be 
able to create an adapter for those) and putting a "MUST" in the 
requirements makes this impossible. So if we decide to force containers to 
always return the same value, we'd better have a very good reason to do so.

Now, what is the real impact of this?

You all seem to imply that if we don't put a "MUST" here, then we cannot 
"trust" the container to give us a usable instance. The container might be 
"vicious" and decide to fool its user by giving him a new instance while 
the user was expecting the same instance. But this is not how it works. The 
typical use case for ContainerInterface is to allow a consumer (like a 
router) to be "container agnostic". As a user, I can decide to plug any 
container to a given router. The router will then be able to fetch the 
correct controller (or the correct action if you do ADR) based on the 
controller name. In this scenario, the user is the one in charge of 
configuring the container (and putting the controller in the container). If 
the user decides that he wants to use a container that can act as a factory 
and that he wants to configure some services that are created on each 
request, it is his responsibility. Keep in mind that since we do not 
standardize how to put things in the container, it has to be the user 
responsibility to configure his container.

So saying that a container MUST return always the same instance is 
premature. When we will start to standardize how to put things in a 
container, then we can define that configured instances MUST be the same. 
But we can do this in the next PSR (the one that defines how to put things 
into a container) and not in this one.


Now, even if I'm really convinced that we should keep the "SHOULD" in 
place, I understand from the numerous comments that the way the spec is 
written is clumsy (or rather worrisome).

Why did I propose this sentence in the first place? I was thinking that a 
"CompositeContainer" could try to cache in an array the list of services 
already fetched from its children. This is something you can do if you know 
the children containers will always return the same instance but that you 
cannot do if you don't know if the container will return the same or a new 
instance. So really, the "SHOULD" prevents us to write composite containers 
that "cache" the result from children. This is actually not a very big 
deal, as composite containers are very seldomly used. What I was trying to 
say here was: "Hey, don't cache the services returned by a container, it 
might return a new instance on the next call". I proposed this wording 2 
years ago in container-interop. In hindsight, this is certainly too 
specific to be part of a PSR.

I see 3 possible solutions to replace this:

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

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.
Instead, in the coming days, I'll open new threads to address each 
individual issue raised (starting with the MUST vs SHOULD debate :) )

This way, we can keep the PSR-11 review readable and understandable.

Thanks,
David.


Le lundi 31 octobre 2016 12:57:05 UTC+1, Pedro Cordeiro a écrit :
>
> 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 instances or not. 
> Since I can't know if the objects are shared, I have to assume they're not. 
> Doesn't matter if I'm an application or a framework developer. I can't 
> think of how a framework could reliably implement something that consumes a 
> service from a PSR-11 container without having this information. I agree 
> with Larry 100% here.
>
> $obj = $container->get("something");
> $obj->setThing("myValue");
> $obj2 = $container->get("something");
> var_dump($obj2->getThing());
>
> This snippet here has unknown behavior, not because I don't know the 
> properties of the service (which is completely out of scope), but because I 
> don't know the behavior of the "get" method (which is completely in-scope).
>
> I understand we don't want to hinder adoption of PSR-11 by being too 
> restrictive (and thus locking some implementations out) and I don't have a 
> solution to this problem. However, I still believe this is something to be 
> addressed. 
>
> While writing a framework (as a set of reusable components), I wouldn't 
> invoke any containers directly, I'd just rely on having something elsewhere 
> injecting my components' dependencies. While writing my application (or a 
> bootstrapper/kernel for the framework, which acts as a bridge between the 
> framework and the application) is when the container is most useful - and I 
> 100% need to know how it behaves there! As an example, Symfony provides a 
> kernel can be thought as part of the application domain, not the framework 
> domain. It's the base of the "skeleton application" that wires everything 
> together. The other components have no knowledge of a container. The 
> application is doing all the wiring/retrieving of services - and thus needs 
> to know how the wiring behaves (or, at the very minimum, how fetching a 
> service from a container behaves).
>
> > * The allowance for additional parameters on get() is worrisome. That 
> > implies ANY use of a second or further parameter sets me up for an 
> > incompatibility, but implementations are free to add those 
> > implementation-specific hooks that I can couple to.  I would much prefer 
> > to omit that allowance entirely.  (Technically optional parameters 
> > cannot be prevented, but we shouldn't encourage it.) 
>
> Two different implementations of PSR-11 should be compatible between 
> themselves and switching between them shouldn't break any implementations 
> that depend on a generic PSR-11 container. If anything, I'd specify that 
> there MUST NOT be any additional parameters in that call. I'm 100% with 
> Larry on this one too.
>
> I don't really have a strong opinion on the other issues Larry raised, 
> even though I agree with most of them.
>
> Em quinta-feira, 27 de outubro de 2016 18:29:53 UTC-2, David Négrier 
> escreveu:
>>
>> Hi Pedro,
>>
>> > However, as an application developer, this PSR doesn't help me much as 
>> is...
>>
>> Absolutely true. You are also right to note that this PSR is not directly 
>> targeted at end users but rather at frameworks.
>>
>> You should view container interoperability as a multistage rocket.
>>
>> The first stage of the rocket is PSR-11. Out of the box, even if you 
>> can't put things into the container, PSR-11 is still useful. Have a look at 
>> Zend-Expressive if you want a great example. Zend-expressive is allowing 
>> you to use many routers and many containers. The router is instantiating 
>> the controller through ContainerInterface `get` method. This way, the 
>> router is not dependant on one specific container (consider how this better 
>> than in Silex for instance, where Pimple is the only possible container). 
>> This is already a great win.
>>
>> The second s

Re: [PSR-15] Falsehoods About The Client-side

[David Négrier]

Hey Woody,

I was speaking with Matthieu Napoli and Joel Wurtz (HTTPlug contributor) 
about PSR-15 last week at Paris ForumPHP. If I correcly remember the 
discussion we had, the general consensus was that PSR-15 should indeed 
focus on the server side middlewares.
Client middlewares are a different kind of beast. I don't think you will 
face a big pushback if you decide to focus PSR-15 on server side 
middleware. This is what people expect from PSR-15.

Furthermore, HTTPlug is already trying to standardize client side 
middlewares (see 
http://docs.php-http.org/en/latest/plugins/introduction.html) and they may 
want to push a PSR based on their work in the future.

++
David.


Le lundi 31 octobre 2016 14:50:39 UTC+1, Woody Gilk a écrit :
>
> Michael,
>
> Thanks for bringing this up. For historical context, I have always thought 
> of "client middleware" as middleware that does not require the additional 
> methods defined in ServerRequestInterface. The consideration of async vs 
> sync requests was never something that entered my mind.
>
> Reviewing the Guzzle docs again (as the most mature PSR-7 client-focused 
> package I know of) it certainly appears that the current PSR-15 signatures 
> would not work there. That is obviously a serious flaw.
>
> However, since there is not currently a ratified PSR for async, perhaps 
> the best thing to do would be to repurpose PSR-15 to be entirely 
> server-focused middleware? I would rather defer the creation of a spec for 
> client middleware until the async PSR is complete.
>
> Would that be an acceptable situation for you? I don't want to create 
> something that async clients will never be able to use.
>
> Regards,
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> On Sat, Oct 29, 2016 at 4:47 PM, Michael Mayer  > wrote:
>
>> Hi everyone,
>>
>> I'm a little bit surprised to see so many suggestions about how 
>> ServerMiddlewareInterface and ClientMiddlewareInterface should look like, 
>> obviously without much knowledge about the client-side.
>>
>> The current state 
>> 
>>  
>> is:
>>
>> interface MiddlewareInterface {}
>>
>> interface ClientMiddlewareInterface extends MiddlewareInterface
>> {
>> public function process(RequestInterface $request, DelegateInterface 
>> $next);
>> }
>>
>> interface ServerMiddlewareInterface extends MiddlewareInterface
>> {
>> public function process(ServerRequestInterface $request, 
>> DelegateInterface $frame);
>> }
>>
>> interface DelegateInterface
>> {
>> public function next(RequestInterface $request);
>> }
>>
>>
>> 
>>
>>
>>
>> Here are some falsehoods about the client-side, the list seems, by far, 
>> not exhaustive.
>>
>> *1. HTTP Clients return their results synchronously*
>> It would be very clumsy to load a web page nowadays with all its assets 
>> sequentially. Thus HTTP clients like Guzzle 
>>  use asynchronous techniques like 
>> Promises (e.g. Guzzle Promises ), 
>> callbacks (e.g. node.js), generator based control flow, etc.
>>
>> An example:
>>
>> $request = new \GuzzleHttp\Psr7\Request('GET', 'http://httpbin.org');
>> $promise = $client->sendAsync($request)->then(function ($response) {
>> echo 'I completed! ' . $response->getBody();
>> });
>>
>>
>> *2. Client Middlewares just transform Requests to Responses, doing it 
>> **synchronously 
>> is not a problem*
>> Maybe, this is appropriate on the server side, but not on the client. 
>> Just think about a Middleware which adds cookies to requests.
>>
>> From GuzzleHttp/Middleware 
>> 
>> :
>> return function ($request, array $options) use ($handler) {
>> // …
>> $request = $cookieJar->withCookieHeader($request);
>> return $handler($request, $options)
>> ->then(function ($response) use ($cookieJar, $request) {
>> $cookieJar->extractCookies($request, $response);
>> return $response;
>> }
>> );
>> };
>>
>> The Middleware have to:
>>
>>1. add the current cookie to the header: ->withCookieHeader($request)
>>2. call the delegate: $handler($request, $options)
>>3. extract the cookie
>>
>> As the delegate returns a promise, we need to: $handler(…)->then(…).
>> Can we do better, e.g. use a sync delegate/handler? Nope, this would lead 
>> to call $promise->wait() within the delegate, which isn't performant. 
>>
>> *3. Client Middlewares call their delegate almost once*
>> For the client-side it's absolutely valid to retry a request, e.g. 
>> GuzzleHttp/RetryMiddleware 
>> 

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

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 is stating: "*Two successive calls to get with 
the same identifier SHOULD return the same value.*"

Because this is what we expect overall from a container.

Yet, some containers give you the freedom to have a new entry returned at 
each call. In this case, the container acts as a factory. Should we 
completely forbid that?
I see no point in putting a hard ban on it.

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.

Also, many containers already allow creating new entries at each call to 
get. For instance, in Pimple, you can do this with the `factory` method.

If the PSR stated "*Two successive calls to get with the same identifier 
MUST return the same value.*", Pimple (and many other containers) could 
never be compatible with PSR-11.
This would be a shame as it would hinder adoption, without so far any clear 
benefits.

So I'd really want to keep this "SHOULD" in place.
However, maybe the second sentence can be worked upon.

Maybe the problematic part is: "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."

Of course, the user knows how it configured its container so it can rely on 
it to return the same entry on SOME known identifiers. If you have an idea 
on how to rephrase this in a more intelligible way, I'd be interested.

Best regards,
---
David.
Twitter: @david_negrier
Github: @moufmouf

Le jeudi 27 octobre 2016 15:09:06 UTC+2, Pedro Cordeiro a écrit :
>
> 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 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+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/2c879363-54ca-4723-8a6e-01c1c9917718%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> *Pedro Cordeiro*
> Produto
>  
> Phone: +55 31 3024 1115
>
> [image: Logo assinatura] 
> 
>
>
> 

Re: [REVIEW] PSR-11 Container Interface

[David Négrier]

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 value on 2 successive calls.
>
> I don't want to drag everyone again to the same discussion. But I wonder 
if
> there is any implementors having any concern about the same.

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?

We can of course work on standardizing the notion of "factories" like 
described here 
(https://github.com/container-interop/container-interop/issues/44) but this 
is IMHO a whole different PSR as factories may/should not be containers.

Thanks a lot,
David.

-- 
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/e5f1473f-e652-4732-a46b-d2d2a1ed3390%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Comments please: Asset Scheme

[David Négrier]

Hey Rasmus,

Interesting!
I have a few questions. It seems you are looking to keep the spec as simple 
as possible. But how do you plan to work with more complex "asset pipes" 
like minifying / concatenating / compiling LESS/SASS files...?

Also, @webmozart tackled the same problem in a very different way with Puli 
(http://docs.puli.io/en/latest/).

Have you had a look at it? Any reason not to use Puli?

++
David.




Le lundi 17 octobre 2016 09:12:47 UTC+2, Rasmus Schultz a écrit :
>
> > Why do you want the folder name to be named assets itself ? 
>
> The folder has to have a name - "assets" seemed like the logical choice. 
>
> Perhaps what you're really wondering is, why a single folder and not a 
> map like in the Aura library? 
>
> Because it's simpler. A map would require more than a standard - it 
> would require at least a configuration file format specification, 
> and/or possible a library or interfaces. 
>
> Also, because we learned from doing something similar at work, that 
> being able to symlink vendored asset folders into the project's public 
> asset folder is really useful - it enables you to run an installation 
> script once, and the continue to add more files to the vendor 
> packages, since every file in the symlinked folder becomes 
> automatically available. 
>
> Another reason is that a map cannot be interpreted or resolved at 
> design-time, by the browser - things like source-maps of relative 
> paths fall apart, since the relative public URLs do not map directly 
> to physical files. This is perhaps the main reason we came up with 
> this approach - anything else has proven to be highly impractical to 
> work with. Having to run a build or deploy script between every change 
> is cumbersome. 
>
> Finally, the length or appearance of asset URLs is typically 
> completely irrelevant - about as irrelevant as the physical 
> file-system structure is to Composer packages. For the most part, no 
> person will ever see the URL of your CSS or JS files - wanting shorter 
> or neater URLs is purely vanity, it has no practical consequence. 
> Having a simple, predictable URL structure that prevents collissions, 
> is much more valuable than having pretty URLs. 
>
> Good question though, thanks for reviewing this :-) 
>
>
> On Mon, Oct 17, 2016 at 3:00 AM, Hari K T  
> wrote: 
> > Thank you Rasmus Schultz for the nice write up. 
> > 
> > After looking at it I think, it was something similar to what we had for 
> > Aura  https://github.com/friendsofaura/Aura.Asset_Bundle . 
> > 
> > I recently added psr-7 support : https://github.com/harikt/psr7-asset ( 
> Not 
> > saying it is perfect ) 
> > 
> > I like some of the good things you mentioned towards the end of "A 
> component 
> > responsible for the delivery of vendor-supplied assets:" 
> > 
> > 
> https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee#12-asset-url-scheme
>  
> > 
> > Also I have question : 
> > 
> > Why do you want the folder name to be named assets itself ? ( But I do 
> agree 
> > it is good to have a folder not to expose other files ;-) ) 
> > 
> > What Aura.Asset_Bundle was using was mapping the folder with the package 
> > path. So it don't necessary to be in vendor folder you mentioned. It 
> gives 
> > flexibility for the users to choose the path for their vendor specific 
> css. 
> > 
> > Eg : In our case you can alter the css / js behaviours of the vendor/a/b 
> > with your own if you are mapping to /web/project-specific-assets . 
> > 
> > I do understand it needs some configuration though. 
> > 
> > And thanks for bringing this up, and it will be nice feature to have for 
> > considering psr-7, psr-15 etc. 
> > 
> > Thank you 
> > 
> > Hari K T 
> > 
> > You can ring me : +91 9388 75 8821 
> > 
> > http://harikt.com , https://github.com/harikt , 
> > http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT 
> > 
> > Skype  : kthari85 
> > Twitter : harikt 
> > 
> > On Mon, Oct 17, 2016 at 3:10 AM, Rasmus Schultz  > wrote: 
> >> 
> >> The webroot folder can have any name - a folder needs to be designated, 
> I 
> >> thought the spec was pretty clear on this point? :-) 
> >> 
> >> 
> >> On Oct 16, 2016 23:00, "Christopher Pitt"  > wrote: 
> >>> 
> >>> Nice write-up. Do you think it would be possible to survey member 
> >>> projects (including recently departed projects, like Laravel), to 
> determine 
> >>> things like the most common/preferred name for the webroot folder? 
> >>> 
> >>> -- 
> >>> You received this message because you are subscribed to a topic in the 
> >>> Google Groups "PHP Framework Interoperability Group" group. 
> >>> To unsubscribe from this topic, visit 
> >>> https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe. 
> >>> To unsubscribe from this group and all its topics, send an email to 
> >>> php-fig+u...@googlegroups.com . 
> >>> To post to this group, send email to 

Re: [PSR-11] Delegate Lookup > Interface Proposal

[David Négrier]

Hey,

Ok I spent the week-end trying to think about the pros and cons of this 
proposal.

@XedinUnknown, I'm not sure I understood 100% of your proposal so I'll try 
to rephrase it. If I'm wrong, let me know.

I understand you are trying to improve the "delegate lookup feature". Your 
goals are:

- to make it "explicit" that a container is implementing the "delegate 
lookup feature"
- to make it possible to nest containers at an unlimited level (to be able 
to nest a composite container in another composite container...)

To do so, you propose to add a new interface named 
ParentAwareContainerInterface 
.
 
This interface is exposing a single method "getParentContainer()" that 
returns the parent container if any (i.e. the composite container 
containing this container).
When resolving a dependency, the container goes up the chain of parent 
containers 

 
until it reaches the root container. It uses the root container to look up 
any dependency (just like in the current delegate lookup feature).

Here are a few thoughts about this idea:

First: who is consuming the ParentAwareContainerInterface 
?
 
This interface is consumed by "child" containers. If a container is a leaf 
in the container tree (so if it is not a composite container), then there 
is no need for it to implement the ParentAwareContainerInterface 
.
 
The interface is trivial to implement and is a good declaration of intent 
(your container states it supports delegate lookup feature) but it is none 
the less useless. This interface is only useful for composite containers 
(so that they can also be bundled into parent composite containers).

Second, each container now needs to find the root container by going up the 
container tree. In your sample, you do this while resolving a service 
.
 
This is a bit of a problem performance-wise because this will slow service 
resolving (and this is a major no no for many implementors). Of course, 
there is a simple way around that. Finding the root container could be done 
only once, possibly in the constructor. This assumes that the parent 
container is passed to the child container constructor (or at build time). 
This also assumes that the parent container will never change in the life 
of a container (this is a safe assumption). Looking at @XedingUnknown code, 
this means that stuff like containers with mutable parents 

 
should be forbidden and only containers with immutable parents 

 
should be allowed.

If we assume that the "parent" container is always passed to containers in 
their constructor, it means that containers MUST be constructed in the 
order of the tree (from top to bottom).






I made a picture so it would be more clear. If the "root container" exists 
before "Composite A" and if "Composite A" exists before "Container 1", then 
when "container 1" is created, instead of passing an instance of composite 
A, it should directly be passed an instance of the root container. That 
way, "container 1" does not have to go up the tree to find the root 
container. This makes the proposed "ParentAwareContainerInterface" useless, 
because finding the root container can be and should be done *before* the 
container is created.

@XedingUnknown, I understand your concerns that the "delegate lookup 
feature" of PSR-11 is not backed by a solid interface. After careful 
consideration, I'm not sure your proposal of adding a getter really solves 
any issues (because we already can nest several containers). However, you 
are making clear that we never spoke about the way containers should be 
created (and who should come first between the parent and the child 
container). After thinking about your proposal, what is now clear to me is 
that the parent should be created before the children (and maybe we should 
stress that out in the META 

Re: Output escaping PSR

[David Négrier]

Hey Woody,

I'm pretty sure there is a lot of things that need to be discussed if we go 
the template way.

The render method could be:

public function render(array|object $parameters) : string;

In that case, it would be up to the implementators to adapt to the passed 
parameter. This is mostly a solved problem with packages like 
symfony/property_access 
<http://symfony.com/doc/current/components/property_access.html> that let 
you access a property of whatever underlying object/array you have.
Or the interface could dictate that the parameters MUST be an array, in 
which case you could always wrap your object as a property of the 
parameters array:

$template->render(['obj'=>$myObject]);

Anyway, I'm sure there are a lot of things that can be discussed here. The 
render method could also return a PSR-7 ResponseInterface object or a strem 
instead of a string...
I don't want to dive deep into the details in this thread (mostly because 
it was initially about output escaping and I don't want to hijack too much 
the initial theme of the post) but I'd be interested in knowing if this 
approach has some support amongst the people reading this list.

What do you think?

++
David.



Le jeudi 6 octobre 2016 14:15:04 UTC+2, Woody Gilk a écrit :
>
> What if my templates use objects?
>
> On Thu, Oct 6, 2016, 04:34 David Négrier <david@gmail.com 
> > wrote:
>
>> Hey,
>>
>> I would simply like to give a huge +1 to Larry's answer because he did 
>> nail the problem perfectly.
>>
>> Escaping is done in the template, therefore is used by template engine 
>> authors. There are not a hundred different ways to do escaping and an 
>> escaping PSR would really dictate an implementation which is not what FIG 
>> is doing.
>>
>> On the other end, there are huge interoperability issues at the template 
>> level. There are indeed a hundred different ways to write a template (Twig, 
>> Blade, Mustache, Smarty, pure PHP, you name it...), but all templates have 
>> in common that they take an array of parameters and that they spit out some 
>> HTML (or more precisely a string of content).
>>
>> Therefore, IMHO, efforts to increase interoperability might be better 
>> focused it the template level rather than at the espcaping level.
>>
>> For instance:
>>
>> interface TemplateInterface
>> {
>> public function render(array $parameters) : string;
>> }
>>
>> Such an interface could be used to abstract template rendering from the 
>> actual implementation (think about rewriting all Smarty templates into Twig 
>> templates in a project without touching the PHP code base, just swapping 
>> the implementation of the template). Each template engine is internally in 
>> charge of the escaping so we don't need to focus on that.
>>
>> ++
>> David.
>>
>>
>> Le jeudi 6 octobre 2016 10:45:47 UTC+2, Matteo Beccati a écrit :
>>>
>>> Hi, 
>>>
>>> On 06/10/2016 09:53, Alessandro Lai wrote: 
>>> > Maybe the aim of this PSR should be a test suite (or at least a data 
>>> > provider of common and edge cases for tests) instead of an interface: 
>>> if 
>>> > your escaper pass all the tests, it's PSR-x compliant. 
>>> > 
>>> > This could be a really good standard, which any implementer can look 
>>> up 
>>> > to to see if its implementation is up to the task. 
>>>
>>> Still, I don't think it's a suitable goal for a PSR. We'd be defining 
>>> the output of an implementation, which is more or less like providing 
>>> one. What would be the benefit? 
>>>
>>>
>>> Cheers 
>>> -- 
>>> Matteo Beccati 
>>>
>>> Development & Consulting - http://www.beccati.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/08a4aa53-7fd1-46db-a237-2a1d2fed43fd%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/08a4aa53-7fd1-46db-a237-2a1d2fed43fd%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
>
> Woody Gilk
> http://about.me/shadowhand
>

-- 
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/9c6981c1-5309-42a3-a25f-4b4ec897f994%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Output escaping PSR

[David Négrier]

Hey,

I would simply like to give a huge +1 to Larry's answer because he did nail 
the problem perfectly.

Escaping is done in the template, therefore is used by template engine 
authors. There are not a hundred different ways to do escaping and an 
escaping PSR would really dictate an implementation which is not what FIG 
is doing.

On the other end, there are huge interoperability issues at the template 
level. There are indeed a hundred different ways to write a template (Twig, 
Blade, Mustache, Smarty, pure PHP, you name it...), but all templates have 
in common that they take an array of parameters and that they spit out some 
HTML (or more precisely a string of content).

Therefore, IMHO, efforts to increase interoperability might be better 
focused it the template level rather than at the espcaping level.

For instance:

interface TemplateInterface
{
public function render(array $parameters) : string;
}

Such an interface could be used to abstract template rendering from the 
actual implementation (think about rewriting all Smarty templates into Twig 
templates in a project without touching the PHP code base, just swapping 
the implementation of the template). Each template engine is internally in 
charge of the escaping so we don't need to focus on that.

++
David.


Le jeudi 6 octobre 2016 10:45:47 UTC+2, Matteo Beccati a écrit :
>
> Hi, 
>
> On 06/10/2016 09:53, Alessandro Lai wrote: 
> > Maybe the aim of this PSR should be a test suite (or at least a data 
> > provider of common and edge cases for tests) instead of an interface: if 
> > your escaper pass all the tests, it's PSR-x compliant. 
> > 
> > This could be a really good standard, which any implementer can look up 
> > to to see if its implementation is up to the task. 
>
> Still, I don't think it's a suitable goal for a PSR. We'd be defining 
> the output of an implementation, which is more or less like providing 
> one. What would be the benefit? 
>
>
> Cheers 
> -- 
> Matteo Beccati 
>
> Development & Consulting - http://www.beccati.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/08a4aa53-7fd1-46db-a237-2a1d2fed43fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Question about PSR-11

[David Négrier]

Hey Sara,

Actually, the name of the interface was the first issue we discussed when 
starting container-interop (the test-bed for PSR-11).

You can have a look at the Github issue that explains why we ended up with 
ContainerInterface here: 
https://github.com/container-interop/container-interop/issues/1 (and the 
results of the vote here: 
https://github.com/container-interop/container-interop/wiki/%231-interface-name:-Vote)

> I think the impedance mismatch here is that PSR-11 isn't about generic 
Containers, but rather about a specialization of Containers aimed at 
dependency injection.

Interesting. I think it is the first time this issue is raised. We use the 
term "Container" as a diminutive for "Dependency Injection Container" 
(because PSR-11 is definitely about DI containers). I think in the PHP 
world, the term Container mostly refer to DI containers (rather than the 
more general datastructure), but I might be wrong. Well, naming is hard! If 
you have a better alternative for the name, please feel free to make a 
suggestion, but we have been a lot to discuss about it and so far, and 
"ContainerInterface" has the very large majority of supporting votes.

> Further, it strikes me as more useful to have that generic container 
implementation in place, then define a DI model based around it, since the 
containers presented here are obviously Map specializations.

Indeed, this is a specialization of a Map, but if we ever need an interface 
to describe a map, well... we could name it MapInterface, couldn't we?

-David

Le lundi 3 octobre 2016 23:06:06 UTC+2, Sara Golemon a écrit :
>
> On Monday, October 3, 2016 at 10:54:30 AM UTC-7, Pedro Cordeiro wrote:
>>
>> Anyway, how do I prepare my application to have interoperable containers, 
>> since they don't agree on how to add new services? I will have to write 
>> adapters for each specific implementation... doesn't that defeat the 
>> purpose of the PSR? Shouldn't "adding services" be in-scope, rather than 
>> 'let some implementations rely on autowiring, others have specific methods 
>> for registering'...?
>>
>>>
> I think the impedance mismatch here is that PSR-11 isn't about generic 
> Containers, but rather about a specialization of Containers aimed at 
> dependency injection.  From that point of view, I think the has/get 
> limitation makes more sense, but I personally would like to see the 
> interfaces named in a way which more precisely reflects that use case 
> scenario so that we leave the door more open to generic container 
> interfaces (e.g. Vector, Set, Map type containers).  Further, it strikes me 
> as more useful to have that generic container implementation in place, then 
> define a DI model based around it, since the containers presented here are 
> obviously Map specializations.
>
> -Sara
>

-- 
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/93db7065-67d8-4cb9-822c-32345bb6f87d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PSR-11] New coordinator and sponsor

[David Négrier]

Hey list!

PSR-11 was missing a sponsor (after AWS and Jeremy Lindblom left the group) 
and with the departure of Paul, we were orphan of sponsors.

Hopefully, 2 new sponsors agreed to step in:

- Matthew Weier O'Phinney (Zend) will be acting as coordinator
- Korvin Szanto (concrete5) will be our sponsor

First of all, many thanks to Paul and Jeremy for the trust they put in us 
editors and for the help they brought to improve PSR-11.
And many thanks to Matthew and Korvin for sponsoring us.

Matthieu Napoli and I believe PSR-11 is now ready for review. So according 
to Michael's transition time table to FIG 3, we will definitely try to pass 
it before the end of the year.
Since in review, we are basically handling the keys of the PSR to our 
sponsors, I'll leave Matthew to declare the start and end date of the 
Review phase based on his very busy schedule.

To all voting members, if you are not familiar with PSR-11 yet, do not 
hesitate to have a look at:

- The PSR 

- The meta doc 

- The psr/container package 

Best regards,
--
David
Github: @moufmouf
Twitter: @david_negrier

-- 
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/cb58da1f-5ba7-4eb1-b745-33ac8b2f5e4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0: Encourage *-interop projects

[David Négrier]

I wholeheartedly support Mathieu's and Keith's point of view.

The MIT license was applied to container-interop from the very start and 
the copyright notice was added according to the MIT license.

PSR-11 constitutes a derivative work based on container-interop and as 
such, modified work done by PHP-FIG should also by copyrighted (to the 
PHP-FIG group).

The fact that part of the copyright belongs to "container-interop" is a 
none issue unless FIG wants to change the license to something else than 
MIT (which is unlikely to happen).
Furthermore, since PSR-11 is a derivative work based on a MIT license 
project, container-interop cannot claim ownership of PSR-11 either.

So in my opinion the only thing we really need to do is to add a copyright 
notice for PHP-FIG in addition to the copyright notice of container-interop.

Also, the FIG bylaws do not indicate that the license should be copyrighted 
to PHP-FIG. It only dictates that it must be MIT (see 
https://github.com/php-fig/fig-standards/blob/master/bylaws/005-licensing-policies.md)
Finally, the whole idea of open-source is to be able to improve and extend 
the work of others. If each project forking another had to deal with 
copyright issues, open-source would be pointless.

++
David.


Le vendredi 2 septembre 2016 04:00:53 UTC+2, Keith Casey a écrit :
>
>
> That's the key point.
>
> The license is the license. As long as the license is acceptable - *as 
> MIT it was* - ownership of the work is irrelevant.
> Ownership is only relevant if you want to change the license.
>
> Larry says that's not the intent, so it appears you're adding unnecessary 
> work and potential complications for no reason.
>
> keith
>
>
> On Wednesday, August 31, 2016 at 11:43:13 PM UTC-7, Matthieu Napoli wrote:
>>
>> Larry, there was still no actual explanation given as to why we had to 
>> change the original license which *was* MIT license.
>>
>> I'm really uncomfortable with this whole thing, and the fact that people 
>> present that as "a problem" makes me even more uncomfortable.
>>
>

-- 
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/f94a454b-75be-4004-9a4c-0377359514bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[David Négrier]

Hey Krzysiek!


>
> 1. ContainerException
>
> - One interface to represents a runtime and logic exceptions so at the end 
> we should always base on the implementation. - No clear context. - Enforces 
> exception implementation.
>
>
I do agree that the fact that the ContainerExceptionInterface can be 
implemented by both runtime and logic exception makes it very impractical 
to use. I think everybody here agrees with this point of view (even the 
proponents for keeping this interface). I you read carefully Matthew's 
mail, his point is that the exception could be used for some reporting 
tools (like Zend's Z-Ray or Blackfire). He would like to keep the exception 
in place for these use cases.

 

>
> 2. NotFoundException
>
> - Not found what? Container was not found? - No clear context.
>
>
The current PSR draft is quite clear:

A call to the get method with a non-existing id MUST throw a 
Psr\Container\Exception\NotFoundExceptionInterface 

.

I'm not sure I understand your comment. Do you mean we should rename it to 
something more specific, like EntryNotFoundExceptionInterface?

 

>
> The whole idea to use interfaces with exceptions to mark 'something' is 
> totally impractical. If we think that something is very important we should 
> provide the exception classes derived from standard exception hierarchy, 
> just like we do providing PSR interfaces, because classes are just 
> interfaces.
>
>
I strongly disagree with you here. Each framework has its own hierarchy of 
exceptions. Requiring an existing framework to throw an exception provided 
by this PSR would likely cause breaking changes in the framework. Have a 
look at Symfony for instance. The container has already a "has" and a "get" 
method. Implementing PSR-11 would be a breeze (if they want to). If however 
we require them to use a ContainerException "class" (instead of an 
interface), that adoption could not be done before Symfony 4 (because 
Symfony currently has its own NotFoundException and it cannot change it 
without breaking the API).


Best regards,
David.

-- 
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/cef2ebf6-8d01-4417-98c1-2f8508370644%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PSR-11] Clarifying exceptions

[David Négrier]

The current draft for PSR-11 contains this text relative to exceptions:

1.2 Exceptions 

Exceptions directly thrown by the container MUST implement the 
Psr\Container\Exception\ContainerExceptionInterface 

.

A call to the get method with a non-existing id SHOULD throw a 
Psr\Container\Exception\NotFoundExceptionInterface 

.



We have already had a discussion regarding the usefulness of 
ContainerExceptionInterface. Even if I'd like to see it gone, the majority 
seems to be in favor of keeping it. However, there are 2 other things I'd 
like to discuss:

Regarding the *NotFoundExceptionInterface*:

The current text says a container SHOULD throw an exception. Searching 
through the history of container-interop, I cannot find why we put a 
"should" here.
I'd like to propose replacing it with a MUST. For instance, it is never ok 
if a container returns null instead of throwing an exception. Therefore, 
the need for "MUST". Does anyone has any objection regarding this change?

Regarding the *ContainerExceptionInterface*:

I'd like to make the opposite move and switch from MUST to SHOULD, as in: 
"Exceptions directly thrown by the container SHOULD implement the 
ContainerExceptionInterface".
Furthermore, I'd like to emphasize the "directly" part. For instance, I 
understand perfectly that a cyclic dependency or a config file typo should 
throw an exception implementing ContainerExceptionInterface. However, if 
the user is using a container based on factories (like Disco or 
PimpleInterop), and if the factory written by the user is throwing an 
exception, I find it useless to wrap that exception in another exception 
implementing the ContainerExceptionInterface. To me, it adds noise and 
nothing more.

Here is a sample using Disco:

/** * @Configuration */class MyConfiguration{/** * @Bean */
public function myDbService() : DbService{
...
...
throw new MissingDbDriverException();
...
...
}}


When calling `$container->get('myDbService')`, I would expect the container 
to throw a MissingDbDriverException directly. I don't want to make it 
compulsory for the container to wrap the MissingDbDriverException into 
another container-specific exception (but I don't want to forbid it either, 
I think it should be implementation specific...) Do you agree with this 
point of view? If there is a general concensus on this, maybe I can work on 
a few sentences in the META doc to make this clear?

++
David.

-- 
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/af7addd5-ff51-4987-acd1-9599d97bcfb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[David Négrier]

Hey Chuck,

PEAR FAQ says:

> By implementing the base package exception interface, all exceptions for
a given pear package can be caught with catch (\PEAR2\PackageName\Exception
$e).

But in PSR-11, there is only one (useful) exception interface:
NotFoundException.

Aknowledging the fact there is only one (and will be only one) useful
exception interface for this package, does it still make sense to keep the
base exception interface?

David.



Le mer. 17 août 2016 à 12:57, Chuck Burgess  a écrit :

> PEAR most definitely wants to keep the package-level base exception, as it
> is a convention we always expect to be available.  We have *required* this
> for years, originally as a class in PEAR1 standards, until we came up with
> the idea of it instead being an interface while working on the PEAR2
> standards.  We were quite happy with its demonstrated benefits, which
> proved even better as an interface than a class [1], and were tickled to
> see the use of it spread into the community after we published it.
>
> We would prefer to *not* lose the base exception interface requirement.
> CRB
>
> [1] -- https://wiki.php.net/pear/rfc/pear2_exception_policy
>
> On Aug 15, 2016 7:35 PM, "Paul Jones"  wrote:
>
>>
>> > On Aug 15, 2016, at 14:10, Matthieu Napoli  wrote:
>> >
>> > Hi,
>
>
>> >
>> > PSR-11, aka ContainerInterface, has been sleeping for too long. Let's
>> get that PSR moving!
>>
>> Woohoo!
>>
>>
>> > Here is a change I would like to suggest: remove the interface
>> ContainerException.
>> ...
>> > After years of using container-interop and ContainerInterface I have
>> not seen a use case for that exception. We initially added it to represent
>> any exception that could happen in a container.
>>
>> On principle alone, I usually like to see a package-specific base
>> exception class, so that you can catch any/every exception from a
>> particular package. (Maybe that's more an unnecessary consistency on my
>> part.)
>>
>>
>> --
>>
>> 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/325BF45B-4638-43AA-9D6F-59BADB38C65E%40gmail.com
>> .
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/php-fig/_vdn5nLuPBI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CANsgjnuZ%2B-MW1Avdu67RCqKQXkEA2YUSs%2BMrJqerRK3gXn6q%2BA%40mail.gmail.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/CABAasbd7c4Z79jY0XDf3gDDG8JKu-h7ODeWggUkuP3kygqx-8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.