Re: Routing PSR

[Benni Mack]

Hey Hari,

> On 18 Nov 2016, at 06:27, Hari K T  wrote:
> 
> I believe , we should allow Router to do one thing, finding / matching the 
> route, generating the route.
Well, I think it should exactly do one thing - namely finding/match the route. 
The generation is IMHO separate, and belongs to a route generator or even 
URI/URL generator.

I agree, dispatching is somewhere else on the implementation level...

Best,
Benni.

-- TYPO3 Core Team Leader
Support the project: http://typo3.org/donate/

-- 
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/A8BB6ABD-75E9-4678-9180-F6EE02FA2A4E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Hari K T]

I believe , we should allow Router to do one thing, finding / matching the 
route, generating the route.

Dispatching based on the route should be done by dispatcher.

If you are curious what I am talking consider looking into the examples 
https://github.com/auraphp/Aura.Dispatcher#closures-and-invokable-objects .

I believe that is the best way you can remove complexity of dispatching on 
the router.

-- 
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/aaec1fff-1095-4780-8986-3fc0cbe6484b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Woody Gilk]

What would the use case for that be? I've never seen a system that worked
that way.

Here is how I would define the interfaces:
https://gist.github.com/shadowhand/543e4e507bf90feffd6bc63427c7e53b

See comment at the end for implied usage.

--
Woody Gilk
http://about.me/shadowhand

On Thu, Nov 17, 2016 at 5:24 PM, Damiano Petrungaro <
damianopetrung...@gmail.com> wrote:

> I didn't realize that you meant only the naming, my fault.
>
> Anyway i imagine the RouterMatcherInterface as an object that will
> contains one or more RouterInterface, and handle the matching of the uri
> with a Route and will invoke the callable.
>
> Example having different RouterInterfaces, the RouterMatcherInterface
> could prefer to use one of many.
>
> So the routing system will be able to handle different RouterInterfaces
> implementation.
>
> Maybe i am just over engeneering the moment of dispatching.
>
> On Friday, November 18, 2016 at 12:09:14 AM UTC+1, Woody Gilk wrote:
>>
>> I wasn't implying it should be static, just stating naming. I think I
>> agree with you about the first two interfaces. What is the purpose of
>> RouteMatcherInterface?
>>
>> On Thu, Nov 17, 2016, 17:03 Damiano Petrungaro 
>> wrote:
>>
>>> I would like to avoid static methods, they are harder to test.
>>> I prefer something (very basic example) like this
>>>
>>> https://gist.github.com/damianopetrungaro/d3da280e20bd5b22c0
>>> 9c64174114ac2a
>>>
>>> We should also discuss if is better to call the "add" method or "map".
>>> I don't know which one is the most diffused.
>>>
>>> I imagine like some interfaces like:
>>> RouteInterface as representation of the single route,
>>> RouterInterface as collector of Routes,
>>> RouteMatcherInterface as object that can contains more RouterInterface
>>> that will match and dispatch the action.
>>>
>>> On Thursday, November 17, 2016 at 11:34:46 PM UTC+1, Woody Gilk wrote:
>>>
 To me, the expressive implementation goes way beyond what a router
 does, which is:

 Map an http method and a URI expression to a callable:

 Router::add(method, urix, callable)
 Router::get(urix, callable)
 Router::post(...)
 // etc for http methods

 And then match a URI to a registered route:

 Router::match(uri) : Route

 Middleware is a totally separate thing and I think it's weird to put it
 here. Especially since middleware can do routing for you, no need for a
 separate step.


 On Thu, Nov 17, 2016, 16:08 Matthew Weier O'Phinney <
 mweiero...@gmail.com> wrote:

>>> On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro
>
  wrote:
> > I'm doing a microframework (for educational purposes), with the goal
> of use
> > in the core only methods derived from the PSR interfaces, so as to
> give
> > maximum flexibility and not be bound to an implementation rather than
> > another.
> >
> > Now i'm thinking about a routing system, and i'm wondered, how a so
> crucial
> > component to web applications (used by all the frameworks) haven't a
> > standard.
> >
> > What do you think to propose it as a possible PSR?
>
> With Expressive, we've actually started down this direction already,
> and Michael has been urging me to submit our ideas around this as well
> as templating as potential recommendations.
>
> Maybe take a look at zend-expressive-router and its RouterInterface,
> Route class, and RouteResult as a place to start?
> (https://github.com/zendframework/zend-expressive-router)
>
> I'm certainly willing to discuss!
>
>
> --
> 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_myW7zjLEFRhaN
> g4Qtz9gLFf4JWpfXwZcK2wszLCuiKS3Rw%40mail.gmail.com.
> 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+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/ms
>>> gid/php-fig/2d837646-e3bd-4735-b8ce-ac269bbca9a1%40googlegroups.com
>>> 

Re: Routing PSR

[Damiano Petrungaro]

I didn't realize that you meant only the naming, my fault.

Anyway i imagine the RouterMatcherInterface as an object that will contains 
one or more RouterInterface, and handle the matching of the uri with a 
Route and will invoke the callable.

Example having different RouterInterfaces, the RouterMatcherInterface could 
prefer to use one of many.

So the routing system will be able to handle different RouterInterfaces 
implementation.

Maybe i am just over engeneering the moment of dispatching.

On Friday, November 18, 2016 at 12:09:14 AM UTC+1, Woody Gilk wrote:
>
> I wasn't implying it should be static, just stating naming. I think I 
> agree with you about the first two interfaces. What is the purpose of 
> RouteMatcherInterface?
>
> On Thu, Nov 17, 2016, 17:03 Damiano Petrungaro  > wrote:
>
>> I would like to avoid static methods, they are harder to test.
>> I prefer something (very basic example) like this
>>
>> https://gist.github.com/damianopetrungaro/d3da280e20bd5b22c09c64174114ac2a
>>
>> We should also discuss if is better to call the "add" method or "map".
>> I don't know which one is the most diffused.
>>
>> I imagine like some interfaces like:
>> RouteInterface as representation of the single route,
>> RouterInterface as collector of Routes,
>> RouteMatcherInterface as object that can contains more RouterInterface 
>> that will match and dispatch the action.
>>
>> On Thursday, November 17, 2016 at 11:34:46 PM UTC+1, Woody Gilk wrote:
>>
>>> To me, the expressive implementation goes way beyond what a router does, 
>>> which is:
>>>
>>> Map an http method and a URI expression to a callable:
>>>
>>> Router::add(method, urix, callable)
>>> Router::get(urix, callable)
>>> Router::post(...)
>>> // etc for http methods
>>>
>>> And then match a URI to a registered route:
>>>
>>> Router::match(uri) : Route
>>>
>>> Middleware is a totally separate thing and I think it's weird to put it 
>>> here. Especially since middleware can do routing for you, no need for a 
>>> separate step.
>>>
>>>
>>> On Thu, Nov 17, 2016, 16:08 Matthew Weier O'Phinney <
>>> mweiero...@gmail.com> wrote:
>>>
>> On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro

>>>  wrote:
 > I'm doing a microframework (for educational purposes), with the goal 
 of use
 > in the core only methods derived from the PSR interfaces, so as to 
 give
 > maximum flexibility and not be bound to an implementation rather than
 > another.
 >
 > Now i'm thinking about a routing system, and i'm wondered, how a so 
 crucial
 > component to web applications (used by all the frameworks) haven't a
 > standard.
 >
 > What do you think to propose it as a possible PSR?

 With Expressive, we've actually started down this direction already,
 and Michael has been urging me to submit our ideas around this as well
 as templating as potential recommendations.

 Maybe take a look at zend-expressive-router and its RouterInterface,
 Route class, and RouteResult as a place to start?
 (https://github.com/zendframework/zend-expressive-router)

 I'm certainly willing to discuss!


 --
 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_myW7zjLEFRhaNg4Qtz9gLFf4JWpfXwZcK2wszLCuiKS3Rw%40mail.gmail.com
 .
 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+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/2d837646-e3bd-4735-b8ce-ac269bbca9a1%40googlegroups.com
>>  
>> 
>> .
>> 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 

Re: Routing PSR

[Woody Gilk]

I wasn't implying it should be static, just stating naming. I think I agree
with you about the first two interfaces. What is the purpose of
RouteMatcherInterface?

On Thu, Nov 17, 2016, 17:03 Damiano Petrungaro 
wrote:

> I would like to avoid static methods, they are harder to test.
> I prefer something (very basic example) like this
>
> https://gist.github.com/damianopetrungaro/d3da280e20bd5b22c09c64174114ac2a
>
> We should also discuss if is better to call the "add" method or "map".
> I don't know which one is the most diffused.
>
> I imagine like some interfaces like:
> RouteInterface as representation of the single route,
> RouterInterface as collector of Routes,
> RouteMatcherInterface as object that can contains more RouterInterface
> that will match and dispatch the action.
>
> On Thursday, November 17, 2016 at 11:34:46 PM UTC+1, Woody Gilk wrote:
>
> To me, the expressive implementation goes way beyond what a router does,
> which is:
>
> Map an http method and a URI expression to a callable:
>
> Router::add(method, urix, callable)
> Router::get(urix, callable)
> Router::post(...)
> // etc for http methods
>
> And then match a URI to a registered route:
>
> Router::match(uri) : Route
>
> Middleware is a totally separate thing and I think it's weird to put it
> here. Especially since middleware can do routing for you, no need for a
> separate step.
>
>
> On Thu, Nov 17, 2016, 16:08 Matthew Weier O'Phinney 
> wrote:
>
> On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro
>
>  wrote:
> > I'm doing a microframework (for educational purposes), with the goal of
> use
> > in the core only methods derived from the PSR interfaces, so as to give
> > maximum flexibility and not be bound to an implementation rather than
> > another.
> >
> > Now i'm thinking about a routing system, and i'm wondered, how a so
> crucial
> > component to web applications (used by all the frameworks) haven't a
> > standard.
> >
> > What do you think to propose it as a possible PSR?
>
> With Expressive, we've actually started down this direction already,
> and Michael has been urging me to submit our ideas around this as well
> as templating as potential recommendations.
>
> Maybe take a look at zend-expressive-router and its RouterInterface,
> Route class, and RouteResult as a place to start?
> (https://github.com/zendframework/zend-expressive-router)
>
> I'm certainly willing to discuss!
>
>
> --
> 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_myW7zjLEFRhaNg4Qtz9gLFf4JWpfXwZcK2wszLCuiKS3Rw%40mail.gmail.com
> .
> 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/2d837646-e3bd-4735-b8ce-ac269bbca9a1%40googlegroups.com
> 
> .
> 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/CAGOJM6Kv0mtSxLEGOhPb5qMS%2BcKKwu3QsFyQGJPkrhO0YpnkVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Routing PSR

[Matthew Weier O'Phinney]

On Thu, Nov 17, 2016 at 3:12 PM, Damiano Petrungaro
 wrote:
> I'm doing a microframework (for educational purposes), with the goal of use
> in the core only methods derived from the PSR interfaces, so as to give
> maximum flexibility and not be bound to an implementation rather than
> another.
>
> Now i'm thinking about a routing system, and i'm wondered, how a so crucial
> component to web applications (used by all the frameworks) haven't a
> standard.
>
> What do you think to propose it as a possible PSR?

With Expressive, we've actually started down this direction already,
and Michael has been urging me to submit our ideas around this as well
as templating as potential recommendations.

Maybe take a look at zend-expressive-router and its RouterInterface,
Route class, and RouteResult as a place to start?
(https://github.com/zendframework/zend-expressive-router)

I'm certainly willing to discuss!


-- 
Matthew Weier O'Phinney
mweierophin...@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+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/CAJp_myW7zjLEFRhaNg4Qtz9gLFf4JWpfXwZcK2wszLCuiKS3Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Andrew Carter]

Not sure I fully understand that - as a user I can't rely on common sense 
implementations doing it right. If it's not part of the standard, I can't 
guarantee it as a feature and I can't use it.

My only course of action for using that feature would be tightly coupling 
to a cache library that did support items which don't expire, and losing 
interoperability (as I have done in the past).

On Wednesday, November 16, 2016 at 4:15:21 PM UTC, Jordi Boggiano wrote:
>
> This was carried over from PSR-6 tbh, and my understanding is that "an 
> Implementing Library MAY use a configured default duration" means you 
> can very well treat null as "do not expire ever". 
>
> If you read the symfony cache docs for example [1], it shows that by 
> default they treat it that way, and I'd expect others do that too but I 
> havent' researched in depth. 
>
> As such I am ok leaving it as is because the common-sense 
> implementations will do it right, and it doesn't warrant breaking away 
> from PSR-6 IMO. 
>
> Cheers 
>
> [1] 
>
> https://symfony.com/doc/current/components/cache/cache_items.html#cache-item-expiration
>  
>
> On 16/11/2016 17:03, Andrew Carter wrote: 
> > Good work. 
> > 
> > One thing that always bothered me from a user perspective was not being 
> > able to put an item in the cache that doesn't expire (different from a 
> > default expiration time). Having to create times really far in advance 
> > is messy, and you never know if you're going to run into 2038 bugs etc. 
> > It's also quite common to have an entry that you don't want to expire, 
> > because you'll invalidate it yourself or wait for the cache to drop it 
> > when it's full. 
> > 
> > For me, saying that a NULL ttl means some default value somewhere is a 
> > waste of a feature. If I wanted a default value, my code can (and 
> > should) explicitly take care of that. I think documenting NULL to mean 
> > "This item doesn't expire. If the cache driver doesn't not support items 
> > that do not expire, the ttl will be set to the maximum possible." 
> > 
> > Cheers, 
> > 
> > Andrew 
> > 
> > On Wednesday, November 16, 2016 at 2:22:20 PM UTC, Jordi Boggiano wrote: 
> > 
> > Heya, 
> > 
> > We believe PSR-16, Simple Cache, is now ready for final review. As 
> > coordinator, I hereby open the mandatory review period prior to a 
> > formal 
> > acceptance vote; voting will begin no earlier than December 1st, 
> 2016. 
> > 
> > Here are links to the most current version and its meta document: 
> > 
> > 
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md
>  
> > <
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md>
>  
>
> > 
> > 
> > 
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md
>  
> > <
> https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md>
>  
>
> > 
> > 
> > 
> > The package containing the interfaces is there: 
> > 
> > https://github.com/php-fig/simplecache 
> >  
> > 
> > 
> > The latest important changes to the interfaces can be found at: 
> > 
> > https://github.com/php-fig/simplecache/releases/tag/0.2.0 
> >  
> > 
> > 
> > And FWIW, Scrapbook already provides a PSR-16 implementation in its 
> > upcoming release: 
> > 
> https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php
>  
> > <
> https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php>
>  
>
> > 
> > 
> > 
> > Thanks for your time reviewing! 
> > 
> > Cheers 
> > 
> > -- 
> > Jordi Boggiano 
> > @seldaek - http://seld.be 
> > 
> > -- 
> > 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/2dadde75-0559-4a64-a77d-e13bbe1e5690%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/php-fig/2dadde75-0559-4a64-a77d-e13bbe1e5690%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> Jordi Boggiano 
> @seldaek - http://seld.be 
>

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

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

[GeeH]

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 happily concede if 
others were all in favour.

G

On Thursday, 17 November 2016 06:29:31 UTC-5, David Négrier wrote:
>
> 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 
> 

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

[Alessandro Lai]

I agree with Alessandro.
Since this seems a pretty controversial point, I would drop it, in favor of 
continuing the discussion into a new separate PSR, or maybe the "add stuff 
in the container" PSR.
PSR-11 is just a stepping stone for everything in this area, so I would 
prefer to drop it and push it to approval.

Il giorno giovedì 17 novembre 2016 12:52:29 UTC+1, Alessandro Pellizzari ha 
scritto:
>
> On 17/11/2016 11:29, David Négrier wrote: 
>
> > 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 :) 
>
> I see the advantages of using delegate containers (I use them daily), 
> but honestly I don't think they should go in this PSR. 
>
> PSR-11 is focused on getting things from a container, and delegates are 
> completely transparent from this POV. 
>
> As long as a Container implements get() it can become a delegate of a 
> (possibly) more powerful Container that implements delegation. 
>
> I think it would be better in a "Container creation and configuration" 
> PSR. 
>
> Bye. 
>
>

-- 
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/59576a50-0bbe-4901-ae45-c0a4d98a9484%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alessandro Pellizzari]

On 17/11/2016 11:29, David Négrier wrote:


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 :)


I see the advantages of using delegate containers (I use them daily), 
but honestly I don't think they should go in this PSR.


PSR-11 is focused on getting things from a container, and delegates are 
completely transparent from this POV.


As long as a Container implements get() it can become a delegate of a 
(possibly) more powerful Container that implements delegation.


I think it would be better in a "Container creation and configuration" PSR.

Bye.

--
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/c116b27b-1924-5d7e-74f4-61aa9a8d7c18%40amiran.it.
For more options, visit https://groups.google.com/d/optout.

[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: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

We had a quick chat off list and I believe Cees-Jan agrees with me that 
this is not really feasible as is.


Having promise responses without a promise spec is not doable, and 
having optional promise responses means the interface can not be relied 
upon at all in libraries as it may return values or may return promises 
depending on which PSR-16 implementation you'd use.


One can still use a promise-based cache library in their app of course, 
but they'd have to use a PSR-6 or PSR-16 one to pass into libraries that 
require a cache.


Cheers

On 16/11/2016 22:59, Cees-Jan Kiewiet wrote:

This PSR looks splendid, well done. There are how ever a few concerns
with regards to async PHP. I'm aware there isn't a Promise PSR yet but
is it acceptable within this spec to return a promise instead of the
actual value on a get? Or to resolve or reject a promise on set instead
of returning true/false directly.

On Wed, Nov 16, 2016 at 8:04 PM, Stefano Torresi > wrote:


Il giorno mer 16 nov 2016 alle ore 17:19 Jordi Boggiano
> ha scritto:

This was also carried over from PSR-6 where Pool::save() returns
bool.

I am not really sure what's best here, I expect most
implementation will
throw anyway if they can't connect to the cache, and in other
instances
there is no reason a write should fail AFAIK.

Any other opinions on this?


I don't see any compelling advantage in the boolean return value and
I'd prefer leaving it out, but there were a few people who argued in
favor of it during PSR-6 review.

As a side note, out of the most downloaded non-PSR-6 libraries
listed in the first pages of Packagist, Zend\Cache and
Doctrine\Cache do follow this convention, while almost every other
don't.

--
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/CAFojS1sV1YTy5A-rjqq5syGPMbVAcBn1WA-D62BDsgV0yVp3wg%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/CAPY1sU8tU7VrWvuSMjxMwd5qMvDfQbgmc0E_P2dowJMoHt%3D%2BDQ%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.



--
Jordi Boggiano
@seldaek - http://seld.be

--
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/34f70364-2cdd-2d78-3e2c-d0c488bf29af%40seld.be.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Jordi Boggiano]

Thanks for the clarifications Larry.

On 16/11/2016 23:13, Larry Garfield wrote:

The reasoning here for PSR-6 was that a broken cache should not result
in a broken program.  If your cache is b0rked, then everything becomes a
cache miss but the app continues to run, just slowly.  (Maybe unbearably
slowly, but technically still runs.)  If a failed set threw an exception
then your cache server hiccuping would crash your whole application,
which is doubleplusungood.

I believe the same logic applies equally well to PSR-16.

--Larry Garfield

On 11/16/2016 11:19 AM, Jordi Boggiano wrote:

This was also carried over from PSR-6 where Pool::save() returns bool.

I am not really sure what's best here, I expect most implementation
will throw anyway if they can't connect to the cache, and in other
instances there is no reason a write should fail AFAIK.

Any other opinions on this?

On 16/11/2016 17:08, Andrew Carter wrote:

Sorry for the double post, what's the reasoning behind returning a
boolean if the set() operation fails? I'd naturally expect that to be an
exception (it's not the same as a cache miss, there must have been some
error).

On Wednesday, November 16, 2016 at 2:22:20 PM UTC, Jordi Boggiano wrote:

Heya,

We believe PSR-16, Simple Cache, is now ready for final review. As
coordinator, I hereby open the mandatory review period prior to a
formal
acceptance vote; voting will begin no earlier than December 1st,
2016.

Here are links to the most current version and its meta document:

https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache.md





https://github.com/php-fig/fig-standards/blob/1cf169c66747640c6bc7fb5097d84fbafcd00a0c/proposed/simplecache-meta.md






The package containing the interfaces is there:

https://github.com/php-fig/simplecache



The latest important changes to the interfaces can be found at:

https://github.com/php-fig/simplecache/releases/tag/0.2.0



And FWIW, Scrapbook already provides a PSR-16 implementation in its
upcoming release:
https://github.com/matthiasmullie/scrapbook/blob/master/src/Psr16/SimpleCache.php






Thanks for your time reviewing!

Cheers

--
Jordi Boggiano
@seldaek - http://seld.be

--
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/8fb9871d-2e1b-4922-bfc7-b123bec6528f%40googlegroups.com

.

For more options, visit https://groups.google.com/d/optout.








--
Jordi Boggiano
@seldaek - http://seld.be

--
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/024c9c8d-2269-0611-ce7c-4c0ed7213fa0%40seld.be.
For more options, visit https://groups.google.com/d/optout.