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

[Daniel Plainview]

I mean, converting class into interface or vice versa is regular operation 
in my codebase, and it doesn't make huge diff: using of a contract is just 
the same.

On Friday, December 6, 2019 at 2:27:35 AM UTC+3, Daniel Plainview wrote:
>
> > I saw this being said above by Daniel Plainview:
> > You would still break BC for anyone who instantiates the Logger class.
>
> True, but it breaks potentially less amount of code.
> For example, it's a common to use bundles that instantiate services. So 
> these bundles may keep BC, but code which just uses Logger won't be 
> affected at all.
> Invalid instantiation in many cases may be detected at compile-time 
> (compilation of container), and it's way safer than runtime BC breaks.
>
> On Sunday, October 13, 2019 at 7:30:29 PM UTC+3, Andreas Hennings 
> (donquixote) wrote:
>>
>> This is an interesting discussion.
>>
>> I could imagine an ideal world where "Response" is the interface name, 
>> and "SimeKindOfResponse" is a specific implementation / class.
>> In such an utopia, if you see a "Response" as a parameter type hint, you 
>> immediately know this is an interface.
>>
>> The world that I live in has a lot of legacy code where "Response" can 
>> very well be a one-off class, and no interface is to be seen anywhere.
>> Even worse, the class might have a lot of public methods or even some 
>> public properties (or anonymous properties) which are used by some consumer 
>> code, but which we don't want to extract into an interface.
>>
>> In such a world, the suffix "Interface" offers a welcome distinction to 
>> the one-off legacy classes.
>>
>>
>> I saw this being said above by Daniel Plainview:
>>
>> Ironically, I think this is disadvantage: you don't need to know about 
>>> it. 
>>> Further, if you don't allow inheritance like this: final class Logger, 
>>> you would be allowed to convert Logger into an interface without breaking 
>>> BC.
>>
>>
>> You would still break BC for anyone who instantiates the Logger class.
>>
>>
>>
>>
>>
>>
>> On Saturday, December 22, 2018 at 9:12:12 AM UTC+1, Dmitriy Zhirnov wrote:
>>>
>>> it's time to redesign Zend framework at all
>>>
>>> понедельник, 15 августа 2016 г., 23:02:46 UTC+3 пользователь Woody Gilk 
>>> написал:
>>>>
>>>> How do you propose to resolve this common problem?
>>>>
>>>>
>>>> namespace Zend\Diactoros;
>>>>
>>>> use Psr\Http\Message\ServerRequestInterface;
>>>>
>>>> class ServerRequest implements ServerRequestInterface { ... }
>>>>
>>>>
>>>> When the class name is the same as the interface name, you have to use 
>>>> aliases. The correct approach for the problem you put forward is:
>>>>
>>>>
>>>> use Psr\Http\Message\ServerRequestInterface as ServerRequest;
>>>> use Psr\Http\Message\ResponseInterface as Response;
>>>>
>>>> public function __invoke(ServerRequest $request, Response, callable 
>>>> $next) { ... }
>>>>
>>>>
>>>> To wit, alias the interface in code that uses the interface if you find 
>>>> it annoying.
>>>>
>>>> I am strongly AGAINST this change as it results in churn for an a huge 
>>>> number of projects without adding any value.
>>>>
>>>> --
>>>> Woody Gilk
>>>> http://about.me/shadowhand
>>>>
>>>> On Mon, Aug 15, 2016 at 2:53 PM, Matthieu Napoli  
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> This is a 2 weeks discussion before going to a vote.
>>>>>
>>>>> The "Interface" suffix has been questioned a few times already, I'm 
>>>>> suggesting we put that up to a vote and avoid future debates. Here are 
>>>>> relevant threads I could find on the topic:
>>>>>
>>>>> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
>>>>> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
>>>>> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
>>>>> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>>>>>
>>>>> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST 
>>>>> be suffixed by Interface"* from 
>>

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

[Daniel Plainview]

> I saw this being said above by Daniel Plainview:
> You would still break BC for anyone who instantiates the Logger class.

True, but it breaks potentially less amount of code.
For example, it's a common to use bundles that instantiate services. So 
these bundles may keep BC, but code which just uses Logger won't be 
affected at all.
Invalid instantiation in many cases may be detected at compile-time 
(compilation of container), and it's way safer than runtime BC breaks.

On Sunday, October 13, 2019 at 7:30:29 PM UTC+3, Andreas Hennings 
(donquixote) wrote:
>
> This is an interesting discussion.
>
> I could imagine an ideal world where "Response" is the interface name, and 
> "SimeKindOfResponse" is a specific implementation / class.
> In such an utopia, if you see a "Response" as a parameter type hint, you 
> immediately know this is an interface.
>
> The world that I live in has a lot of legacy code where "Response" can 
> very well be a one-off class, and no interface is to be seen anywhere.
> Even worse, the class might have a lot of public methods or even some 
> public properties (or anonymous properties) which are used by some consumer 
> code, but which we don't want to extract into an interface.
>
> In such a world, the suffix "Interface" offers a welcome distinction to 
> the one-off legacy classes.
>
>
> I saw this being said above by Daniel Plainview:
>
> Ironically, I think this is disadvantage: you don't need to know about it. 
>> Further, if you don't allow inheritance like this: final class Logger, 
>> you would be allowed to convert Logger into an interface without breaking 
>> BC.
>
>
> You would still break BC for anyone who instantiates the Logger class.
>
>
>
>
>
>
> On Saturday, December 22, 2018 at 9:12:12 AM UTC+1, Dmitriy Zhirnov wrote:
>>
>> it's time to redesign Zend framework at all
>>
>> понедельник, 15 августа 2016 г., 23:02:46 UTC+3 пользователь Woody Gilk 
>> написал:
>>>
>>> How do you propose to resolve this common problem?
>>>
>>>
>>> namespace Zend\Diactoros;
>>>
>>> use Psr\Http\Message\ServerRequestInterface;
>>>
>>> class ServerRequest implements ServerRequestInterface { ... }
>>>
>>>
>>> When the class name is the same as the interface name, you have to use 
>>> aliases. The correct approach for the problem you put forward is:
>>>
>>>
>>> use Psr\Http\Message\ServerRequestInterface as ServerRequest;
>>> use Psr\Http\Message\ResponseInterface as Response;
>>>
>>> public function __invoke(ServerRequest $request, Response, callable 
>>> $next) { ... }
>>>
>>>
>>> To wit, alias the interface in code that uses the interface if you find 
>>> it annoying.
>>>
>>> I am strongly AGAINST this change as it results in churn for an a huge 
>>> number of projects without adding any value.
>>>
>>> --
>>> Woody Gilk
>>> http://about.me/shadowhand
>>>
>>> On Mon, Aug 15, 2016 at 2:53 PM, Matthieu Napoli  
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> This is a 2 weeks discussion before going to a vote.
>>>>
>>>> The "Interface" suffix has been questioned a few times already, I'm 
>>>> suggesting we put that up to a vote and avoid future debates. Here are 
>>>> relevant threads I could find on the topic:
>>>>
>>>> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
>>>> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
>>>> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
>>>> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>>>>
>>>> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be 
>>>> suffixed by Interface"* from 
>>>> http://www.php-fig.org/bylaws/psr-naming-conventions/
>>>>
>>>> I do not suggest accepted PSRs are changed.
>>>>
>>>> Please share your reasons to vote FOR or AGAINST the change, let's 
>>>> debate for 2 weeks or more, and then let's have a vote to settle this.
>>>>
>>>> Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).
>>>>
>>>> ---
>>>>
>>>> Here are my arguments to vote FOR the change:
>>>>
>>>> *- the Interface suffix makes simple names very long*
>>>>
&

Re: [PSR-14] Meeting Summary - 2018-09-13

[Daniel Plainview]

> Task - A Task is a specific case of an Event that is bidirectional. 

I think this definition is not correct: Task (whatever it is) is not 
specific case of Event, because Event is never bidirectional. 

> Message - A Message is a specific case of an Event 

Event is special case of a message (likewise command), not vice versa.

I think these definitions would confuse people very much.

P.S. 

> renaming TaskInterface to TaskEventInterface and MessageInterface 

-Interface suffix brrrns.

On Saturday, September 15, 2018 at 12:34:47 AM UTC+3, Larry Garfield wrote:
>
> This is a special double-header edition, as we had a partial meeting last 
> week 
> with just 3 of us (damned scheduling conflicts!) and then a full meeting 
> this 
> week.  Highlights include: 
>
> * We've added some more guidance to the metadoc on when to use Messages/ 
> Notifiers and when to use Tasks/Processors. 
> * Based on the survey results, we are going to split the interfaces into 3 
> packages (the common bits, tasks, and messages).  We're sticking with a 
> single 
> spec/Working Group, however, and probably a single namespace. 
> * We're still chewing on naming things.  (It's hard, OK?)  Tentatively 
> we're 
> considering renaming TaskInterface to TaskEventInterface and 
> MessageInterface 
> to MessageEventInterface, so that the "event" term is still in both.  That 
> makes it a shorter conceptual jump for existing implementations and their 
> users.  Still not finalized; we're going to sleep on it a bit and discuss 
> again next week. 
> * We're going to remove stopPropagation() from the stoppable interface. 
>  It 
> will just have the isPropagationStopped() method for the Processor to use; 
> task implementers should define their own 
> semantically-meaningful-in-their- 
> context method for indicating that propagation should be stopped.  (Which 
> if 
> they want to call it stopPropagation(), hey, that's their business.) 
> * The recommendation to use *Task and *Message suffixes on event classes 
> will 
> be removed, because Rich Hickey says so. 
> * We're tightening up the error handling so that Processors must allow 
> exceptions to bubble up, even if they catch-and-rethrow in order to do 
> additional error handling.  That way it's consistent across 
> implementations 
> and callers don't need to wonder whether they'll get an exception back or 
> not. 
> * Time permitting we're going to try building bridge implementations to 
> make 
> sure that Zend and Symfony's current event systems can peacefully coexist 
> with 
> PSR-14 in a naturally-upgrading way.  If someone wants to try bridging to 
> another existing implementation, now is a great time to do it! 
>
> At present we are hoping to call a Readiness Vote within the next month or 
> two, although of course no promises are made here. 
>
> --Larry Garfield, PSR-14 Editor 
>

-- 
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/7e3c9f7d-1f43-46fe-bf1c-3f1db98d4abd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-14] Meeting Summary - 2018-08-30 (ACTION REQUIRED!)

[Daniel Plainview]

>  commands and events are both events

are both messages*

On Friday, September 14, 2018 at 9:35:10 AM UTC+3, Daniel Plainview wrote:
>
> > In practice, the Message is essentially a command bus.
>
> This is kinda inaccurate language when you say that "message" is a "bus"...
> But more importantly, message can be either command or event: why do you 
> make accent on "command" bus?
> Command bus MAY return something (it doesn't violate CQRS: 
> https://vladikk.com/2017/03/20/tackling-complexity-in-cqrs/; CQRS is 
> about write and read models [look at the definition]; it's a widespread 
> fallacy that CQRS says something about what method should return or not) 
> from the command handler; on other hand, event bus is not able to do this.
>
> I suggest to do not use abstract "message" word: commands and events are 
> both events, but they can be handle way differently.
>
> On Thursday, August 30, 2018 at 11:49:03 PM UTC+3, Larry Garfield wrote:
>>
>> We had another energetic call today.  At this point we're arguing about 
>> minutia and details, which I take as a good sign.  Highlights include: 
>>
>> * We're going to rename StoppableTaskInterface::isStopped() to 
>> isPropagationStopped(), since that's what both Symfony and Zend Framework 
>> call 
>> it now. 
>>
>> * Cees-Jan showed a React Promises-based proof of concept.  By and large 
>> it 
>> looks like the spec is compatible with that workflow as is with no need 
>> for 
>> further revision.  See: https://github.com/WyriHaximus/php-broadcast 
>>
>> * We discussed performance considerations, especially prompted from 
>> discussion 
>> with the Doctrine team who have concerns about event handling at extreme 
>> scale.  Larry has added benchmarks to his implementation that suggest 
>> performance should be more than fine.  We will continue to monitor the 
>> performance question though and make sure there's no unexpected gotchas. 
>>
>> * We spent quite a bit of time discussing the fate of the Message vs Task 
>> use 
>> cases.  In practice, the Message is essentially a command bus.  Task is 
>> what 
>> nearly all PHP libraries today call Events, even if that is academically 
>> inaccurate.  We're OK with that, and I'll be adding more clarity on that 
>> to 
>> the spec or metadoc.  While they overlap considerably, they also do have 
>> different use cases.  Are they enough that we should split the spec in 
>> two?   
>> Or that we should keep a unified spec but split up the packages?  We're 
>> not 
>> sure, and we want to get input from others.  (That means you, reading 
>> this, we 
>> want your input!) 
>>
>> **PLEASE TAKE A MOMENT FOR THE BRIEF ASK BELOW** 
>>
>> I've put together a very quick survey we'd like to have people respond to 
>> to 
>> help gather input on that point.  This is *not a vote*, it's a 
>> non-binding 
>> survey for feedback.  We actively want feedback from everyone, whether 
>> you're 
>> a "formal" member of FIG or not.  Please take 30 seconds to respond to 
>> the 
>> following survey within the next week or so. 
>>
>>
>> https://docs.google.com/forms/d/1fvhYUH6xvPgJ1UW9I-3pMGPUtxkt5_Ph6_x_3qXHIuM/
>>  
>> viewform 
>>
>> --Larry Garfield 
>> PSR-14 Editor 
>>
>

-- 
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/f724a8e6-1fe2-4336-a11a-e48a4cbe9b69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-14] Meeting Summary - 2018-08-30 (ACTION REQUIRED!)

[Daniel Plainview]

> In practice, the Message is essentially a command bus.

This is kinda inaccurate language when you say that "message" is a "bus"...
But more importantly, message can be either command or event: why do you 
make accent on "command" bus?
Command bus MAY return something (it doesn't violate CQRS: 
https://vladikk.com/2017/03/20/tackling-complexity-in-cqrs/; CQRS is about 
write and read models [look at the definition]; it's a widespread fallacy 
that CQRS says something about what method should return or not) from the 
command handler; on other hand, event bus is not able to do this.

I suggest to do not use abstract "message" word: commands and events are 
both events, but they can be handle way differently.

On Thursday, August 30, 2018 at 11:49:03 PM UTC+3, Larry Garfield wrote:
>
> We had another energetic call today.  At this point we're arguing about 
> minutia and details, which I take as a good sign.  Highlights include: 
>
> * We're going to rename StoppableTaskInterface::isStopped() to 
> isPropagationStopped(), since that's what both Symfony and Zend Framework 
> call 
> it now. 
>
> * Cees-Jan showed a React Promises-based proof of concept.  By and large 
> it 
> looks like the spec is compatible with that workflow as is with no need 
> for 
> further revision.  See: https://github.com/WyriHaximus/php-broadcast 
>
> * We discussed performance considerations, especially prompted from 
> discussion 
> with the Doctrine team who have concerns about event handling at extreme 
> scale.  Larry has added benchmarks to his implementation that suggest 
> performance should be more than fine.  We will continue to monitor the 
> performance question though and make sure there's no unexpected gotchas. 
>
> * We spent quite a bit of time discussing the fate of the Message vs Task 
> use 
> cases.  In practice, the Message is essentially a command bus.  Task is 
> what 
> nearly all PHP libraries today call Events, even if that is academically 
> inaccurate.  We're OK with that, and I'll be adding more clarity on that 
> to 
> the spec or metadoc.  While they overlap considerably, they also do have 
> different use cases.  Are they enough that we should split the spec in 
> two?   
> Or that we should keep a unified spec but split up the packages?  We're 
> not 
> sure, and we want to get input from others.  (That means you, reading 
> this, we 
> want your input!) 
>
> **PLEASE TAKE A MOMENT FOR THE BRIEF ASK BELOW** 
>
> I've put together a very quick survey we'd like to have people respond to 
> to 
> help gather input on that point.  This is *not a vote*, it's a non-binding 
> survey for feedback.  We actively want feedback from everyone, whether 
> you're 
> a "formal" member of FIG or not.  Please take 30 seconds to respond to the 
> following survey within the next week or so. 
>
>
> https://docs.google.com/forms/d/1fvhYUH6xvPgJ1UW9I-3pMGPUtxkt5_Ph6_x_3qXHIuM/ 
> viewform 
>
> --Larry Garfield 
> PSR-14 Editor 
>

-- 
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/60176c24-4c03-4c6e-b482-2fdab172442c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

> Plus, FWIW I recently decided to switch from one convention to another in 
every new project I happen to work on, and I comfortably obtained the 
suffix-less style by aliasing third party interfaces with a bunch of 
`use` statements. Why can't you all do the same?

If you ask seriously, you can read the discussion, but in short:
* [minor issue] obviously, it is impossible to alias everything (especially 
when you use unpopular convention) unless PhpStorm can do it automatically 
(it has no such feature so far, but probably there is a plugin?);
* aliasing solves very minor part of the issue, the real impact is that it 
forces people to think about corresponding class names, allows to change 
interface with class and vice versa for many consumers without BC break, 
sometimes it moves design in the right direction (don't create interface 
for no reason), etc.; 

On Tuesday, February 28, 2017 at 9:33:13 PM UTC+3, Stefano Torresi wrote:
>
> This is a non issue, please, leave this discussion alone, it has been 
> settled a long time ago!
>
> Plus, FWIW I recently decided to switch from one convention to another in 
> every new project I happen to work on, and I comfortably obtained the 
> suffix-less style by aliasing third party interfaces with a bunch of 
> `use` statements. Why can't you all do the same?
>
> We have to accept that people will always have different opinions on the 
> matter, and consensus is *impossible* to achieve.
>
> Consistency with the status-quo is a more valuable thing on the table.
>
> Can we just leave it at that?
>
> Il giorno mar 28 feb 2017 alle ore 19:16 Rivera, John  > ha scritto:
>
>> Hello all, 
>>
>> I’m a new face here, and has been lurking the mailing list with interest.
>>
>> I decided to de-lurk because this issue has always bothered me, and I’m 
>> very happy to see that I’m not alone, and that it’s under discussion — 
>> albeit possibly long over, looking at the dates :(
>>
>> In my opinion (and many others that I’ve worked with), an interface 
>> having ‘I’ or ‘Interface in its name is an anti-pattern. This begun, I 
>> think, with the whole “interface all the things!” design ‘pattern' that was 
>> all the rage around 2010 — you know, where every single class has an 
>> interface, even if there would ever be one implementation of said 
>> interface. The ‘I’ prefix (or the ‘Interface’ suffix as we have here) arose 
>> because, as Phil Karlton famously said, naming things is hard.
>>
>> But in this situation, it shouldn’t be. If you are hard pressed to think 
>> up of a name for an interface that does not include ‘I’ or ‘Interface’, 
>> you’re most likely doing it wrong.
>>
>> Let’s take the Logger example from below. Let’s imagine that we’re 
>> implementing a Logger for the first time ever. The first thing that’d come 
>> to mind when one thinks of logging is probably a file-based log on the 
>> local filesystem. So we go forth and write up that Logger class, which 
>> writes to said log file. It all works, we use it all over the code (with a 
>> composite root and dependency injection, of course) and the stakeholders 
>> are happy.
>>
>> But then suddenly, a developer pipes up and says, “files are annoying, 
>> let’s log to the database!”. Brilliant! So now we want a SQL logger. Being 
>> good developers, we refactor the Logger class into an interface, and write 
>> up the FileLogger and SQLLogger implementations.
>>
>> And what about the rest of the code? That’s right. We only need to update 
>> the composite root to instantiate a SQLLogger (or a FileLogger) and pass 
>> that in. The rest of the object graph does not have to be updated — as far 
>> as it is concerned, the Logger is still the same Logger it’s always been. 
>> It doesn’t know, nor cares, whether it is an interface or not.
>>
>> As you can see, naming things should be easy here. The interface should 
>> tell you what it is, and the implementation should tell you what it does. 
>> Simple.
>>
>> Matthieu argued that the name should make the interface the most 
>> important part — I think it should strive to be the opposite — the name 
>> should make the interface attribute irrelevant to the object graph.
>>
>> John
>>
>> On Feb 28, 2017, at 12:32 PM, Han Hui Teoh > > wrote:
>>
>> It'll be ironic if this passes. Because look at PSR-2 (and the proposed 
>> PSR-12), they're supposed to standardize coding style and prevent further 
>> endless arguments.
>>
>> But then FIG itself cannot / will not stick to that same philosophy? I 
>> hope not.
>>
>> On Tuesday, August 16, 2016 at 3:53:26 AM UTC+8, Matthieu Napoli wrote: 
>>>
>>> Hi all, 
>>>
>>> This is a 2 weeks discussion before going to a vote.
>>>
>>> The "Interface" suffix has been questioned a few times already, I'm 
>>> suggesting we put that up to a vote and avoid future debates. Here are 
>>> relevant threads I could find on the topic:
>>>
>>> - 

Re: Proposing PSR 18 'Singleton' Pre-Draft

[Daniel Plainview]

> I suppose I was thinking 'How should one implement for maximum 
portability?'

The irony here is that singleton makes portability harder by itself.
This "pattern" be avoided as much as possible especially for external API 
between libraries.
I don't see reason to standardize it.

On Monday, February 20, 2017 at 5:35:12 AM UTC+3, Richard T. Miles wrote:
>
> I suppose I was thinking 'How should one implement for maximum 
> portability?' A Skeleton system requires the use of methods that can not 
> be defined in a standard interface ( static members ). I do consider myself 
> a bit novice; however, the intention of the singleton isn't to limit the 
> creative process of the developer. I believe storing data in skeleton 
> pattern is a `Cleaner` abstraction model than a container system. I 
> definitely want to hear what the communities thoughts on the matter are. 
> I understand PHP-Fig tries to leave the creative process open to the next 
> innovation, and it may be that this abstraction is to detailed; however, I 
> figured I would try to add some code to this great community :) 
>
> Thanks,
> Richard Miles
>
> On Sunday, February 19, 2017 at 7:59:11 PM UTC-6, Korvin Szanto wrote:
>>
>> Hi Richard,
>> I took a really fast look at the repo since I'm currently waiting for a 
>> plane. I noticed that this seems to be more of an implementation than a set 
>> of interfaces to standardize on. Are you wanting to standardize the 
>> implementation?
>>
>> Thanks,
>> Korvin
>>
>> On Sun, Feb 19, 2017 at 5:55 PM Richard T. Miles  
>> wrote:
>>
>>> Hello to everyone here at PHP-FIG!
>>>
>>> I have been working on 'Singleton' in my spare time and think it may 
>>> have some use in this community. 
>>> I am a Computer Science student at the University of North Texas so 
>>> development starts and stops pretty
>>> sporadically ( 1 am and coffee ). I think it finally has enough content 
>>> to be presentable under a 'Pre-draft'
>>> context. 
>>>
>>> Singleton Github Repository: 
>>> https://github.com/RichardTMiles/Singleton-Standard
>>>
>>> All comments and constructive criticism welcome! 
>>>
>>> Thanks for your time,
>>> Richard Miles 
>>>
>>> -- 
>>> 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/19954bdc-3c2d-4dc4-a4d8-eee58c9891ec%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/e5ba2cbf-a4e8-416b-a79b-48f70e73638b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

> Are you suggesting that 2 different exceptions should be present?  It 
seems that MissingDependencyException would mean that the $id service 
exists but cannot be created since that service depends on another service 
that is not present.  

Exactly. 
However, as it was discussed in the past, I wouldn't suggest to put 
MissingDependencyException to the spec.
In fact, it can be simple \RuntimeException with proper exception message: 
as I said above, we read the message in our logs and fix the 
code/configuration.
It also can be more generic MisconfiguredServiceException, like someone 
suggested previously. It's matter of taste and should be framework-specific 
I think.

But NotFoundException is different story and should be present in the spec 
with proper meaning.

On Tuesday, January 17, 2017 at 7:11:31 PM UTC+3, Chuck Reeves wrote:
>
> Are you suggesting that 2 different exceptions should be present?  It 
> seems that MissingDependencyException would mean that the $id service 
> exists but cannot be created since that service depends on another service 
> that is not present.  
>
> My thoughts go to Zend\Db\Table\Gateway which needs a Zend\Db\Adapter in 
> order to work.  If the Adapter fails to be created a 
> MissingDependencyException would be thrown in that case
>
> On Tuesday, January 17, 2017 at 10:56:02 AM UTC-5, Daniel Plainview wrote:
>>
>> > This change is more in line with 
>> > existing implementations, and focuses on the primary issue faced by 
>> > consumers: determining when a service is missing from configuration.
>>
>> In order to determine it, we look in our logs or at debugging page. We 
>> read the exception message.
>> Different exceptions don't make it any harder I think. We still look at 
>> the message which may be identical.
>>
>> That separation was focused on semantic difference.
>> Catching NotFoundException is perfectly fine, but I wouldn't expect to 
>> catch it because of broken service or bad configuration.
>> If service is broken, I would expect to see it in my logs.
>>
>> By the way, "bubbling out" is an inaccurate wording.
>> You can make implementation of container so dependencies of service $id 
>> would never throw NotFoundException, but MissingDependencyException.
>> There will be no "bubbling out" at all.
>>
>> On Tuesday, January 17, 2017 at 6:14:00 PM UTC+3, Matthew Weier O'Phinney 
>> wrote:
>>>
>>> We are rebooting the PSR-11 review period again as of now; this marks 
>>> the third review period, and it will end at 11:59 UTC 29 Jan 2017, 
>>> with the prospect of holding a vote starting the following day. 
>>>
>>> The only change since the previous review period is a clarification of 
>>> the role of `NotFoundExceptionInterface`. Previously, the 
>>> specification stated that calls to `get()` MUST NOT allow such 
>>> exceptions to bubble out, but must instead convert them to the more 
>>> generic `ContainerExceptionInterface`. 
>>>
>>> The specification now states that `NotFoundExceptionInterface` 
>>> instances are allowed to bubble out, and that any call to `get()` 
>>> where `has()` would return `false` MUST raise a 
>>> `NotFoundExceptionInterface`. This change is more in line with 
>>> existing implementations, and focuses on the primary issue faced by 
>>> consumers: determining when a service is missing from configuration. 
>>>
>>> Please review the specification again at this time, and let us know as 
>>> soon as 
>>> possible if you see any remaining problems to address; ideally, please 
>>> do so in 
>>> the next 48 hours, so that we may fit within the FIG 2.0 by-law window. 
>>>
>>> -- 
>>> 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+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/8f37e32e-1483-432a-8d5e-0f9ce895875d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Daniel Plainview]

> Essentially, the try/catch block MUST be present. This is specifying 
> _internal implementation_, and, of more concern, specifying an 
> implementation based on try/catch which has significant performance 
> issues. 

Do I miss something or it can be implemented easier w/o try .. catch? 
Example:

public function get($id)
{
   if (!isset($this->services[$id])) {
   throw new NotFoundServiceException($id);
   }

return $this->getService($id);
}

private function getService()
{
   // This method may recursively call itself
   // And this method never throws NotFoundServiceException
}


I think it's possible to do in Symfony at least w/o BC break.

On Monday, January 16, 2017 at 6:48:24 PM UTC+3, Matthew Weier O'Phinney 
wrote:
>
> On Mon, Jan 16, 2017 at 8:41 AM, Larry Garfield  > wrote: 
> > On 01/16/2017 04:58 AM, David Négrier wrote: 
> > 
> > Ok, we have 3 options, and one day to decide which to choose. 
> > 
> > In order to ease the choice, I opened 3 PRs on Github. 
> > 
> > I'll ask everyone involved to give 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) 
> > 
> > 
> > Unsurprisingly I'd favor PR 3: Explicit exception. 
> > 
> > I'll be honest that I'm still very confused why there's so much 
> resistance 
> > from the Editors on using exception types for what they're supposed to 
> be 
> > used for.  Different error condition, different exception.  In 20 years 
> of 
> > writing code I cannot recall ever saying "damn, this error message is 
> too 
> > precise and specific".  I have said the opposite more times than I can 
> > count. 
> > 
> > PR 1 would resolve the awkward wording, although I do feel it is the 
> > inferior approach as it is less precise and provides less contextual 
> > information for callers.  (That we don't at the moment know when a 
> caller 
> > would want that extra information is, IMO, irrelevant as it's so easy to 
> > provide.) 
> > 
> > PR 2 actively works to make using the spec harder, and I cannot get 
> behind 
> > that at all. 
> > 
> > I am admittedly unlikely to vote +1 on the spec regardless, but should 
> it 
> > pass anyway I feel it should still be as good (or least bad) as 
> possible, 
> > and that is PR 3. 
>
> From a consumer standpoint, I can see why this would be useful. If PR 
> 1 is used, we end up with a call to get() raising a 
> NotFoundExceptionInterface instance if either of the following 
> conditions is true: 
>
> - The container does not have the "knowledge" necessary to create an 
> instance of $id. 
> - One of the dependencies of $id does not exist. 
>
> Being able to differentiate *may* be of use at that point. However, 
> from experience, if I see a NotFoundExceptionInterface, the only thing 
> of use to me as a consumer is determining *which* service is missing; 
> I do not care if it is a *dependency* of another service, just that 
> it's needed in my object graph, and I didn't provide relevant 
> information to create it. 
>
> From an implementer's standpoint, PR 3 is a nightmare, as it 
> *requires* that any attempt to retrieve a dependency is wrapped in a 
> try/catch block internally. As an example: 
>
> public function get($id) 
> { 
> if (isset($this->map[$id])) { 
> return $this->map[$id]; 
> } 
>
> try { 
> $instance = $this->create($id); 
> return $instance; 
> } catch (NotFoundExceptionInterface $e) { 
> throw new MissingDependencyException(sprintf( 
> 'Could not create "%s" due to a missing dependency', 
> $id 
> ), $e->getCode(), $e); 
> } 
> } 
>
> Essentially, the try/catch block MUST be present. This is specifying 
> _internal implementation_, 

Re: [REVIEW] PSR-11 Container Interface

[Daniel Plainview]

> If PR 
> 1 is used, we end up with a call to get() raising a 
> NotFoundExceptionInterface instance if either of the following 
> conditions is true: 
> - One of the dependencies of $id does not exist. 

PR 1 doesn't bubble out NotFoundException in this case.
PR 2 acts like you described, though.

On Monday, January 16, 2017 at 6:48:24 PM UTC+3, Matthew Weier O'Phinney 
wrote:
>
> On Mon, Jan 16, 2017 at 8:41 AM, Larry Garfield  > wrote: 
> > On 01/16/2017 04:58 AM, David Négrier wrote: 
> > 
> > Ok, we have 3 options, and one day to decide which to choose. 
> > 
> > In order to ease the choice, I opened 3 PRs on Github. 
> > 
> > I'll ask everyone involved to give 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) 
> > 
> > 
> > Unsurprisingly I'd favor PR 3: Explicit exception. 
> > 
> > I'll be honest that I'm still very confused why there's so much 
> resistance 
> > from the Editors on using exception types for what they're supposed to 
> be 
> > used for.  Different error condition, different exception.  In 20 years 
> of 
> > writing code I cannot recall ever saying "damn, this error message is 
> too 
> > precise and specific".  I have said the opposite more times than I can 
> > count. 
> > 
> > PR 1 would resolve the awkward wording, although I do feel it is the 
> > inferior approach as it is less precise and provides less contextual 
> > information for callers.  (That we don't at the moment know when a 
> caller 
> > would want that extra information is, IMO, irrelevant as it's so easy to 
> > provide.) 
> > 
> > PR 2 actively works to make using the spec harder, and I cannot get 
> behind 
> > that at all. 
> > 
> > I am admittedly unlikely to vote +1 on the spec regardless, but should 
> it 
> > pass anyway I feel it should still be as good (or least bad) as 
> possible, 
> > and that is PR 3. 
>
> From a consumer standpoint, I can see why this would be useful. If PR 
> 1 is used, we end up with a call to get() raising a 
> NotFoundExceptionInterface instance if either of the following 
> conditions is true: 
>
> - The container does not have the "knowledge" necessary to create an 
> instance of $id. 
> - One of the dependencies of $id does not exist. 
>
> Being able to differentiate *may* be of use at that point. However, 
> from experience, if I see a NotFoundExceptionInterface, the only thing 
> of use to me as a consumer is determining *which* service is missing; 
> I do not care if it is a *dependency* of another service, just that 
> it's needed in my object graph, and I didn't provide relevant 
> information to create it. 
>
> From an implementer's standpoint, PR 3 is a nightmare, as it 
> *requires* that any attempt to retrieve a dependency is wrapped in a 
> try/catch block internally. As an example: 
>
> public function get($id) 
> { 
> if (isset($this->map[$id])) { 
> return $this->map[$id]; 
> } 
>
> try { 
> $instance = $this->create($id); 
> return $instance; 
> } catch (NotFoundExceptionInterface $e) { 
> throw new MissingDependencyException(sprintf( 
> 'Could not create "%s" due to a missing dependency', 
> $id 
> ), $e->getCode(), $e); 
> } 
> } 
>
> Essentially, the try/catch block MUST be present. This is specifying 
> _internal implementation_, and, of more concern, specifying an 
> implementation based on try/catch which has significant performance 
> issues. 
>
> If we go with PR 1, the above can be simplified, based on the needs of 
> the implementation: 
>
> public function get($id) 
> { 
> if (isset($this->map[$id])) { 
> return $this->map[$id]; 
> } 
>
> 

Re: [REVIEW] PSR-11 Container Interface

[Daniel Plainview]

> Different error condition, different exception.  In 20 years of writing 
code I cannot recall ever saying "damn, this error message is too precise 
and specific".

@Larry nobody says the opposite, we all agree on this one.
Of course, it must be different exception with nice and precise class name 
and descriptive exception message
(we want to have straightforward messages in our error log, but in case of 
logging, we catch *all* exceptions).
We just say that it's out of the spec.

Just like CircularDependencyException.
There is no this exception in the spec.
And I really don't see why you make MissingDependencyException more special 
over CircularDependencyException.
They are both very important, but they don't bring value in this context.

P.S. I really don't want to offend anyone, I'm just very curious to 
understand opinions on this topic.

On Monday, January 16, 2017 at 5:41:23 PM UTC+3, Larry Garfield wrote:
>
> On 01/16/2017 04:58 AM, David Négrier wrote:
>
> Ok, we have 3 options, and one day to decide which to choose.
>
> In order to ease the choice, I opened 3 PRs on Github.
>
> I'll ask everyone involved to give 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)
>
>
> Unsurprisingly I'd favor PR 3: Explicit exception.
>
> I'll be honest that I'm still very confused why there's so much resistance 
> from the Editors on using exception types for what they're supposed to be 
> used for.  Different error condition, different exception.  In 20 years of 
> writing code I cannot recall ever saying "damn, this error message is too 
> precise and specific".  I have said the opposite more times than I can 
> count.
>
> PR 1 would resolve the awkward wording, although I do feel it is the 
> inferior approach as it is less precise and provides less contextual 
> information for callers.  (That we don't at the moment know when a caller 
> would want that extra information is, IMO, irrelevant as it's so easy to 
> provide.)
>
> PR 2 actively works to make using the spec harder, and I cannot get behind 
> that at all.
>
> I am admittedly unlikely to vote +1 on the spec regardless, but should it 
> pass anyway I feel it should still be as good (or least bad) as possible, 
> and that is PR 3.
>
> --Larry Garfield
>

-- 
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/19c6ff6b-cd20-4af6-b609-a362add4e58a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Daniel Plainview]

> Btw, don't we miss an "InvalidArgumentException", to be thrown when the 
arg passed to has/get is not a string?

It has as much value as documenting `@throws \Error` (compare it with 
scalar type hints).

On Sunday, January 15, 2017 at 5:40:10 PM UTC+3, Nicolas Grekas wrote:
>
>
>
> Regarding you last suggestion I'm having trouble seeing the difference 
>> with the current version of the spec, could you pinpoint it more explicitly?
>>
>
>
> There are two differences:
>
> The most important one is that the *wording* of the PSR need to be as 
> clear as possible. Finding a clear way to express things, so that the PSR 
> is self explanatory enough, is a must (the answers on the ML will be lost 
> in history.)
>
> The second one is a really technical consequence I didn't realize when 
> writing the previous comment:
>
> It makes this statements useless (which is a good thing since that's the 
> one we're worried about):
>
> > A call to get can trigger additional calls to get (to fetch the 
> dependencies). If one of those dependencies is missing, the 
> NotFoundExceptionInterface triggered by the inner get call SHOULD NOT 
> bubble out. Instead, it should be wrapped in an exception implementing the 
> ContainerExceptionInterface that does not implement the 
> NotFoundExceptionInterface.
>
> If one wants to be able to really differentiate these situations, one can 
> already do:
>
> just check "has" before "get". If, after doing so, "get" throws a 
> NotFoundExceptionInterface, then it's a second level missing dep. Isn't 
> it?
>
>
> Btw, don't we miss an "InvalidArgumentException", to be thrown when the 
> arg passed to has/get is not a string?
>
> Nicolas
>

-- 
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/ebba4447-f61a-4cfc-a9d8-11a1fc604e38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Daniel Plainview]

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

There is no such situation like B from consumer point of view, thus you 
don't need to describe what to do in this case.

You can rephrase text, e.g. "Throw NotFoundException when and only when the 
requested service is not found",
and define what "requested service" is.
Probably, it makes sense to add example of right and wrong pseudo 
implementations to the spec.

On Saturday, January 14, 2017 at 11:46:51 PM UTC+3, Larry Garfield wrote:
>
> On 01/14/2017 11:37 AM, David Négrier wrote:
>
> *snip*
>
> So my code was looking like this:
>
> try {
> $service = $container->get($id);
> } catch (NotFoundExceptionInterface $e) {
> if ($id === $e->getMissingIdentifier()) {
> // Display an error message to the user saying the service does 
> not 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.
>
>
> I agree entirely on this point!  These are two separate error conditions, 
> and thus should have 2 separate exceptions.
>
>
> 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.
>
>
> My "cursor" is that defining what code should do on the not-happy path is 
> at least as important if not moreso than what happens on the happy path, 
> especially for standards.  The history of HTML and CSS should have seared 
> that into our brains by now. :-)
>
> (Most of the incompatibility of different HTML engines in the bad old days 
> wasn't in how they handled perfect markup but in how they handled the 
> million ways in which markup could be broken.  The HTML5 spec is so 
> enormous precisely because it tries to retcon the many different ways of 
> handling invalid code into a coherent standard.)
>
> My main issue is that the current text says "In situation A, do X.  In 
> situation B, do any capital letter that is not A."  That is a construction 
> I simply cannot get behind in any specification of any sort, as it is 
> simply too vague and begs for inconsistent error handling.  (Eg, every 
> browser handling a missing  tag differently.)
>
> I have offered two alternatives that would be acceptable: In situation B, 
> throw MisconfiguredServiceException or MissingDependencyException.  Either 
> one would resolve the issue with the spec's error handling.  (Based on 
> earlier discussion I agree that MissingDependency is more specific and thus 
> a better approach.)  If neither of those are acceptable to you, please 
> offer your own alternative that resolves the incomplete error handling.
>
> --Larry Garfield
>

-- 
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/e1922c92-566b-4981-96f5-56ba99557c68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Daniel Plainview]

> Larry just gave one: better error handling.

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

Probably, explanation of NotFoundException should be more clear, but it 
isn't a reason to standardize new exception.

On Friday, January 13, 2017 at 6:31:19 PM UTC+3, Nicolas Grekas wrote:
>
> Hi all,
>
> for the shake of trying (meaning I come here with no announcement at all 
> that this is going to be merged), here is what this currently looks like on 
> the Symfony container:
> https://github.com/symfony/symfony/pull/21265
>
> the exception part is really where things start to look like a zoo. 
> Because we have many animals there in the "Exception" namespace, and 
> mapping them to PSR11's NotFoundExceptionInterface is going to be non 
> trivial and never perfect I'd say.
>
> If you read the thread, you'll see that this sentence "Exceptions directly 
> thrown by the container" is unclear for now - what does "directly" mean?
>
> 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?)
>
>  
>
>> "Don't standardize an *exception interface* for a known error case 
>> because *nobody* can think of a reason you'd catch that"
>>
>
> Larry just gave one: better error handling.
> Error handling is one of the very well done part of PSR-6 - far better 
> that eg how Doctrine Cache behaves. (eg when caching unserialisable 
> objects, PSR-6 tells what to do).
> Excellent error handling is a *strong* argument to me and a requirement 
> for a standard to me.
>
>
> - It is useful for routers to fetch a controller from the container.
>>
>
> What "id" should the router "get()"?
>  
>
>> - It is useful for writing adapters extending any containers. 
>>
> - It is useful for composing containers.
>>
>
> Sure - this is a very very thin and specific use case though to me. 
> Nothing as big as other accepted PSRs.
>  
>
>> - It is useful for writing factories that do not depend on a particular 
>> container.
>>
>
> Same here: what "id" should such factories "get()"?
> If this is left to the implementer, it means PSR11 doesn't solve anything 
> for this use case (and the router one).
>
>
> Also, I'd like to make a parallel with PSR-7 and PSR-15. PSR-7 is already 
>> useful by itself, but it will be immensely more useful when PSR-15 passes. 
>> It is the same with PSR-11. It will be the cornerstone of interoperable 
>> service providers. As soon as PSR-11 passes, we plan forming a working 
>> group on standardizing service providers (see 
>> https://github.com/container-interop/service-provider/ for more 
>> details). PSR-11 is a prerequisite.
>>
>
> This is running in circle to me - self referencing statements to me. 
> PSR-15 does not exist, thus it can't justify PSR-11.
> And looking at PSR-15, how does it solve the "what "id" should the service 
> provider "get()" from the container?"
>
>
> Last note, but not least: having the experience of implementing PSR-16 and 
> PSR-6, I *really strongly* suggest that next PSRs, this one included, 
> always come with a reference battle-ready test suite.
> We now have one that we share with php-cache on Symfony. And if we've had 
> it before the acceptance, I would eg have been more insistent on the need 
> for the "array" type hint on "*Multiple" methods there, because 
> "array|Traversable" is NOT easily resolved with iterator_to_array. That's 
> what I thought on the first implementation I submitted here. Then tests 
> reminded me that iterators can be non-rewindable - and that keys can be of 
> arbitrary types. And that it's a nightmare to deal with - thus PSR-16 is 
> NOT going to be easy to correctly implemented - which is bad for a standard 
> IMHO.
>
> So, back to PSR11, it'd be great - if not mandatory to me - to have a 
> reference test suite that provides actual side effects and verifiable 
> outcomes for every single sentence in the RFC. That would clearly help 
> implementers understand the sometimes too abstracts words - as spotted 
> before.
>
> Cheers,
> Nicolas
>

-- 
You received this message because you are subscribed to 

Re: Routing PSR

[Daniel Plainview]

Some things make frameworks special and routing, in my opinion, one of it.
If you want to eliminate this uniqueness among frameworks, you make 
pointless to choose between them.

> give maximum flexibility
> not be bound to an implementation

These are mutually exclusive statements.

On Friday, November 18, 2016 at 12:12:16 AM UTC+3, Damiano Petrungaro wrote:
>
> Hi everyone.
>
> 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?
>

-- 
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/b93caf66-0879-41cc-954e-9088ca31e3c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Exceptions

[Daniel Plainview]

> because create errors should be handled differently from service not 
being found

Sure. We already can do it:

try {
$this->container->get('foo');
} catch (NotFoundService $e) {
// ...
} catch (\Exception $e) {
// Configuration syntax error, circular dependencies, etc.
}

Why do you need CreationException, can you provide some use cases when you 
want to catch exactly this exception?

By the way, I don't know if you did it on purpose, but your name 
(CreationException) seems more vague than Larry's 
MisconfiguredServiceException. It sounds like more generic exception and 
means for me literally any error excepting NotFoundService exception. 
What's the difference with \Exception then?

On Wednesday, November 23, 2016 at 5:07:48 PM UTC+3, GeeH wrote:
>
> Yes we do need an explicit exception, because create errors should be 
> handled differently from service not being found.
>
> G
>
> On Wednesday, 23 November 2016 13:05:00 UTC, Daniel Plainview wrote:
>>
>> > These are different errors and could/should be handled differently.
>>
>> I think we all agree on this point. The question is do you need 
>> explicit CreationException and why?
>>
>> On Wednesday, November 23, 2016 at 2:08:40 PM UTC+3, GeeH wrote:
>>>
>>> My opinion is this:
>>>
>>> NotFoundException - we don't have a service for this key, you've messed 
>>> up your configuration somewhere
>>> CreationException - argh, something went wrong creating your service, 
>>> this is probably a bug or coding problem
>>>
>>> These are different errors and could/should be handled differently.
>>>
>>> G
>>>
>>> On Sunday, 20 November 2016 19:32:38 UTC, Daniel Plainview wrote:
>>>>
>>>> @Larry
>>>>
>>>> > Those would imply different people are doing something wrong, so it's 
>>>> a different person's responsibility to fix.
>>>>
>>>> It is already clear. If it is not NotFoundServiceException, then it is 
>>>> not user's fault. No need to have yet another exception.
>>>> So we return to the same question: what's the use case when you need to 
>>>> catch MisconfiguredServiceExceptionInterface?
>>>>
>>>> On Saturday, November 19, 2016 at 9:46:46 PM UTC+3, Larry Garfield 
>>>> wrote:
>>>>>
>>>>> We discussed the exception handling at the php[world] meeting, and the 
>>>>> general consensus from those in the room was that semantically "missing", 
>>>>> "broken", and "other" are distinct error conditions that should be 
>>>>> treated 
>>>>> separately.  To that end I offer the following PR so there's something 
>>>>> concrete to discuss:
>>>>>
>>>>> https://github.com/php-fig/fig-standards/pull/844
>>>>>
>>>>> As far as use case, beyond the semantic distinction "missing" implies 
>>>>> the caller is doing something wrong.  "Broken" means the configuration is 
>>>>> wrong.  (Even if the configuration in this case is a hard-coded class, 
>>>>> it's 
>>>>> still configuration so it's in-scope for PSR-11, not PSR-11-followup.)  
>>>>> Those would imply different people are doing something wrong, so it's a 
>>>>> different person's responsibility to fix.
>>>>>
>>>>> --Larry Garfield
>>>>>
>>>>> On 11/11/2016 01:42 PM, Daniel Plainview wrote:
>>>>>
>>>>> > So why even mention it then? 
>>>>>
>>>>> I think it's because most implementations are not aware of this 
>>>>> difference, but it's important.
>>>>> It doesn't automatically mean that the interface must reflect the 
>>>>> DependencyNotFoundException.
>>>>> @throws FooException means "it's your possible issue, take care of it".
>>>>> @throws DependencyNotFoundException means "My arm can be broken, take 
>>>>> care of it".
>>>>> @throws ConfigrationDoesNotExistException means "My leg is broken, 
>>>>> take care of it".
>>>>>
>>>>> > As someone building a framework that uses a container I would very 
>>>>> much care about the distinction between group 2 and group 3
>>>>>
>>>>> Could you, please, provide us a real use-case when you need to catch 
>>>>> DependencyNotFoundException?
>>>>>
>

Re: [PSR-11] Exceptions

[Daniel Plainview]

> These are different errors and could/should be handled differently.

I think we all agree on this point. The question is do you need 
explicit CreationException and why?

On Wednesday, November 23, 2016 at 2:08:40 PM UTC+3, GeeH wrote:
>
> My opinion is this:
>
> NotFoundException - we don't have a service for this key, you've messed up 
> your configuration somewhere
> CreationException - argh, something went wrong creating your service, this 
> is probably a bug or coding problem
>
> These are different errors and could/should be handled differently.
>
> G
>
> On Sunday, 20 November 2016 19:32:38 UTC, Daniel Plainview wrote:
>>
>> @Larry
>>
>> > Those would imply different people are doing something wrong, so it's a 
>> different person's responsibility to fix.
>>
>> It is already clear. If it is not NotFoundServiceException, then it is 
>> not user's fault. No need to have yet another exception.
>> So we return to the same question: what's the use case when you need to 
>> catch MisconfiguredServiceExceptionInterface?
>>
>> On Saturday, November 19, 2016 at 9:46:46 PM UTC+3, Larry Garfield wrote:
>>>
>>> We discussed the exception handling at the php[world] meeting, and the 
>>> general consensus from those in the room was that semantically "missing", 
>>> "broken", and "other" are distinct error conditions that should be treated 
>>> separately.  To that end I offer the following PR so there's something 
>>> concrete to discuss:
>>>
>>> https://github.com/php-fig/fig-standards/pull/844
>>>
>>> As far as use case, beyond the semantic distinction "missing" implies 
>>> the caller is doing something wrong.  "Broken" means the configuration is 
>>> wrong.  (Even if the configuration in this case is a hard-coded class, it's 
>>> still configuration so it's in-scope for PSR-11, not PSR-11-followup.)  
>>> Those would imply different people are doing something wrong, so it's a 
>>> different person's responsibility to fix.
>>>
>>> --Larry Garfield
>>>
>>> On 11/11/2016 01:42 PM, Daniel Plainview wrote:
>>>
>>> > So why even mention it then? 
>>>
>>> I think it's because most implementations are not aware of this 
>>> difference, but it's important.
>>> It doesn't automatically mean that the interface must reflect the 
>>> DependencyNotFoundException.
>>> @throws FooException means "it's your possible issue, take care of it".
>>> @throws DependencyNotFoundException means "My arm can be broken, take 
>>> care of it".
>>> @throws ConfigrationDoesNotExistException means "My leg is broken, take 
>>> care of it".
>>>
>>> > As someone building a framework that uses a container I would very 
>>> much care about the distinction between group 2 and group 3
>>>
>>> Could you, please, provide us a real use-case when you need to catch 
>>> DependencyNotFoundException?
>>>
>>> On Friday, November 11, 2016 at 9:19:11 PM UTC+3, Larry Garfield wrote: 
>>>>
>>>> I'm not suggesting converting all exceptions that might possibly happen 
>>>> to MisconfiguredServiceException.  I'm saying there's 3 broad categories:
>>>>
>>>> 1) What you asked for doesn't exist.
>>>> 2) What you asked for is broken.
>>>> 3) Something else happened, WTF?  (Eg, a database-backed container has 
>>>> a missing DB.)
>>>>
>>>> I agree that group 3 is out of scope.  Group 1 is already covered.  The 
>>>> question is group 2, where "there is something wrong with the container 
>>>> but 
>>>> it's not that what you asked for is missing" is, I assert, legitimately in 
>>>> scope.  As someone building a framework that uses a container I would very 
>>>> much care about the distinction between group 2 and group 3.  That doesn't 
>>>> mean fully exploring all possible details of group 2 and what might break, 
>>>> just indicating the separation between groups 2 and 3.
>>>>
>>>> The current text says, in essence, "for group 2, throw anything but the 
>>>> same as group 1".  So why even mention it then?  And no, that's not a 
>>>> suggestion to remove yet more things from the spec. :-)  (That way lies 
>>>> more incompatibility.)  I'm saying there should be a clearly defined 
>>>> exception for group 1, a clearly defi

Re: [PSR-11] Exceptions

[Daniel Plainview]

@Larry

> Those would imply different people are doing something wrong, so it's a 
different person's responsibility to fix.

It is already clear. If it is not NotFoundServiceException, then it is not 
user's fault. No need to have yet another exception.
So we return to the same question: what's the use case when you need to 
catch MisconfiguredServiceExceptionInterface?

On Saturday, November 19, 2016 at 9:46:46 PM UTC+3, Larry Garfield wrote:
>
> We discussed the exception handling at the php[world] meeting, and the 
> general consensus from those in the room was that semantically "missing", 
> "broken", and "other" are distinct error conditions that should be treated 
> separately.  To that end I offer the following PR so there's something 
> concrete to discuss:
>
> https://github.com/php-fig/fig-standards/pull/844
>
> As far as use case, beyond the semantic distinction "missing" implies the 
> caller is doing something wrong.  "Broken" means the configuration is 
> wrong.  (Even if the configuration in this case is a hard-coded class, it's 
> still configuration so it's in-scope for PSR-11, not PSR-11-followup.)  
> Those would imply different people are doing something wrong, so it's a 
> different person's responsibility to fix.
>
> --Larry Garfield
>
> On 11/11/2016 01:42 PM, Daniel Plainview wrote:
>
> > So why even mention it then? 
>
> I think it's because most implementations are not aware of this 
> difference, but it's important.
> It doesn't automatically mean that the interface must reflect the 
> DependencyNotFoundException.
> @throws FooException means "it's your possible issue, take care of it".
> @throws DependencyNotFoundException means "My arm can be broken, take care 
> of it".
> @throws ConfigrationDoesNotExistException means "My leg is broken, take 
> care of it".
>
> > As someone building a framework that uses a container I would very much 
> care about the distinction between group 2 and group 3
>
> Could you, please, provide us a real use-case when you need to catch 
> DependencyNotFoundException?
>
> On Friday, November 11, 2016 at 9:19:11 PM UTC+3, Larry Garfield wrote: 
>>
>> I'm not suggesting converting all exceptions that might possibly happen 
>> to MisconfiguredServiceException.  I'm saying there's 3 broad categories:
>>
>> 1) What you asked for doesn't exist.
>> 2) What you asked for is broken.
>> 3) Something else happened, WTF?  (Eg, a database-backed container has a 
>> missing DB.)
>>
>> I agree that group 3 is out of scope.  Group 1 is already covered.  The 
>> question is group 2, where "there is something wrong with the container but 
>> it's not that what you asked for is missing" is, I assert, legitimately in 
>> scope.  As someone building a framework that uses a container I would very 
>> much care about the distinction between group 2 and group 3.  That doesn't 
>> mean fully exploring all possible details of group 2 and what might break, 
>> just indicating the separation between groups 2 and 3.
>>
>> The current text says, in essence, "for group 2, throw anything but the 
>> same as group 1".  So why even mention it then?  And no, that's not a 
>> suggestion to remove yet more things from the spec. :-)  (That way lies 
>> more incompatibility.)  I'm saying there should be a clearly defined 
>> exception for group 1, a clearly defined parent exception for group 2 
>> (subclasses specific to a given implementation entirely welcome), and group 
>> 3 is not-our-problem.
>>
>> --Larry Garfield
>>
>> On 11/07/2016 12:20 PM, Daniel Plainview wrote:
>>
>> The major problem with unchecked exceptions is that it is not class 
>> consumer business.
>> What do you say when someone throws SomethingIsBrokenInsideOfMe to you? 
>> I'd say "hey, take a vacation, fix yourself, you look unhealthy". Is it not 
>> my business what exactly is broken (leg or arm, whatever, it doesn't help 
>> to fix my issue). But it is fair enough if library throws YouAreWrong 
>> exception in my face when I'm screwed up.
>>
>> When you make a typo in your Container implementation, it could fail with 
>> something like \TypeError. It is "unhappy-path", isn't it? Is 
>> it MisconfiguredServiceException? I don't think so. What do you do then? 
>> You go and fix your implementation. What happens if configuration is 
>> broken? You go and fix it as well. I don't see much difference here.
>>
>> MisconfiguredServiceException for me is an illusory solution for 
>> "unhappy-path". You c

Re: [PSR-11] Exceptions

[Daniel Plainview]

> So why even mention it then?

I think it's because most implementations are not aware of this difference, 
but it's important.
It doesn't automatically mean that the interface must reflect the 
DependencyNotFoundException.
@throws FooException means "it's your possible issue, take care of it".
@throws DependencyNotFoundException means "My arm can be broken, take care 
of it".
@throws ConfigrationDoesNotExistException means "My leg is broken, take 
care of it".

> As someone building a framework that uses a container I would very much 
care about the distinction between group 2 and group 3

Could you, please, provide us a real use-case when you need to catch 
DependencyNotFoundException?

On Friday, November 11, 2016 at 9:19:11 PM UTC+3, Larry Garfield wrote:
>
> I'm not suggesting converting all exceptions that might possibly happen to 
> MisconfiguredServiceException.  I'm saying there's 3 broad categories:
>
> 1) What you asked for doesn't exist.
> 2) What you asked for is broken.
> 3) Something else happened, WTF?  (Eg, a database-backed container has a 
> missing DB.)
>
> I agree that group 3 is out of scope.  Group 1 is already covered.  The 
> question is group 2, where "there is something wrong with the container but 
> it's not that what you asked for is missing" is, I assert, legitimately in 
> scope.  As someone building a framework that uses a container I would very 
> much care about the distinction between group 2 and group 3.  That doesn't 
> mean fully exploring all possible details of group 2 and what might break, 
> just indicating the separation between groups 2 and 3.
>
> The current text says, in essence, "for group 2, throw anything but the 
> same as group 1".  So why even mention it then?  And no, that's not a 
> suggestion to remove yet more things from the spec. :-)  (That way lies 
> more incompatibility.)  I'm saying there should be a clearly defined 
> exception for group 1, a clearly defined parent exception for group 2 
> (subclasses specific to a given implementation entirely welcome), and group 
> 3 is not-our-problem.
>
> --Larry Garfield
>
> On 11/07/2016 12:20 PM, Daniel Plainview wrote:
>
> The major problem with unchecked exceptions is that it is not class 
> consumer business.
> What do you say when someone throws SomethingIsBrokenInsideOfMe to you? 
> I'd say "hey, take a vacation, fix yourself, you look unhealthy". Is it not 
> my business what exactly is broken (leg or arm, whatever, it doesn't help 
> to fix my issue). But it is fair enough if library throws YouAreWrong 
> exception in my face when I'm screwed up.
>
> When you make a typo in your Container implementation, it could fail with 
> something like \TypeError. It is "unhappy-path", isn't it? Is 
> it MisconfiguredServiceException? I don't think so. What do you do then? 
> You go and fix your implementation. What happens if configuration is 
> broken? You go and fix it as well. I don't see much difference here.
>
> MisconfiguredServiceException for me is an illusory solution for 
> "unhappy-path". You can't trust it. What does it exactly mean? What if you 
> make a syntax typo in your PHP configuration (with arrays, let's say), 
> should it raise the MisconfiguredServiceException? Or it should bubble up 
> \ParseError? I mean, it is more like ConfigurationIsTotallyScrewedUp rather 
> than simple MisconfiguredService. It's vague exception that means 
> "something is wrong with *them*". I'd rather catch ALL other 
> (non-NotFoundException) exceptions if I want to avoid program crash for 
> some reason. I can trust \Exception (or even \Throwable). The meaning is 
> simply same: "something is wrong with them" and I don't really care what 
> exactly is.
>
> Can you please provide real-life example when you want to catch 
> MisconfiguredServiceException (excepting "I want to log it differently", 
> because it doesn't look real-life, honestly; and it is too universal answer 
> for any kind of exceptions)?
>
> On Monday, November 7, 2016 at 5:27:58 PM UTC+3, Larry Garfield wrote: 
>>
>> Container nesting is part of the spec, and a stated goal of the spec, so 
>> it's a valid use case to consider.
>>
>> True, there are many different ways that things can break.  Consistent 
>> and constructive handling of the not-happy path is a critical part of spec 
>> development.  See also: HTML5, the majority of which is not new stuff but 
>> standardizing the many different ways that browsers used to handle badly 
>> formed HTML.  It's a total mess because the unhappy path was never 
>> well-defined, so everyone did it differently, so code broke in a variety of

Re: [PSR-11] Exceptions

[Daniel Plainview]

The major problem with unchecked exceptions is that it is not class 
consumer business.
What do you say when someone throws SomethingIsBrokenInsideOfMe to you? I'd 
say "hey, take a vacation, fix yourself, you look unhealthy". Is it not my 
business what exactly is broken (leg or arm, whatever, it doesn't help to 
fix my issue). But it is fair enough if library throws YouAreWrong 
exception in my face when I'm screwed up.

When you make a typo in your Container implementation, it could fail with 
something like \TypeError. It is "unhappy-path", isn't it? Is 
it MisconfiguredServiceException? I don't think so. What do you do then? 
You go and fix your implementation. What happens if configuration is 
broken? You go and fix it as well. I don't see much difference here.

MisconfiguredServiceException for me is an illusory solution for 
"unhappy-path". You can't trust it. What does it exactly mean? What if you 
make a syntax typo in your PHP configuration (with arrays, let's say), 
should it raise the MisconfiguredServiceException? Or it should bubble up 
\ParseError? I mean, it is more like ConfigurationIsTotallyScrewedUp rather 
than simple MisconfiguredService. It's vague exception that means 
"something is wrong with *them*". I'd rather catch ALL other 
(non-NotFoundException) exceptions if I want to avoid program crash for 
some reason. I can trust \Exception (or even \Throwable). The meaning is 
simply same: "something is wrong with them" and I don't really care what 
exactly is.

Can you please provide real-life example when you want to catch 
MisconfiguredServiceException (excepting "I want to log it differently", 
because it doesn't look real-life, honestly; and it is too universal answer 
for any kind of exceptions)?

On Monday, November 7, 2016 at 5:27:58 PM UTC+3, Larry Garfield wrote:
>
> Container nesting is part of the spec, and a stated goal of the spec, so 
> it's a valid use case to consider.
>
> True, there are many different ways that things can break.  Consistent and 
> constructive handling of the not-happy path is a critical part of spec 
> development.  See also: HTML5, the majority of which is not new stuff but 
> standardizing the many different ways that browsers used to handle badly 
> formed HTML.  It's a total mess because the unhappy path was never 
> well-defined, so everyone did it differently, so code broke in a variety of 
> inconsistent ways.  My issue is that "throw anything other than X" is not a 
> consistent and constructive handling of the non-happy path.
>
> The biggest distinction I would draw would be between "you asked for 
> something that's not there" and "you asked for something that's broken".  
> Those are very different things; one implies I screwed up, the other 
> implies the configurer screwed up.  I can see the argument for not 
> specifying a separate exception for every possible way that the requested 
> service is broken (there are many, that's true), but a clear distinction 
> between those two broad categories ("missing" and "broken") seems like a 
> much better baseline.
>
> In that case, I would revise my ask to defining two exceptions:
>
> * NotFoundException extends ContainerExceptionInterface (thrown if the 
> requested service isn't defined anywhere)
> * MisconfiguredServiceException extends ContainerExceptionInterface 
> (thrown if the requested service is defined, but for whatever reason can't 
> be instantiated)
>
> And implementers are free to subclass the latter if they choose, but must 
> still have that exception flag on them.  (I'm flexible on the name, the one 
> I have there is likely not the best name.)
>
> --Larry Garfield
>
> On 11/05/2016 12:59 PM, Daniel Plainview wrote:
>
> > A situation of "if your child container throws exception X, you're 
> required to catch it and turn it into anything that's not X but is still Y" 
> seems needlessly convoluted 
>
> You did it by introducing "child container", Container contract doesn't 
> have any child containers, this contract is very simple 
> and straightforward. By saying about child containers, you mean that you 
> know how internals of the Container work, you know about "child 
> containers", but you shouldn't care about it when you want to use Container.
>
> > but doesn't provide me as a developer sufficient debug information.  I'd 
> potentially want to log differently depending on which exception it is, but 
> I can't do that if I have no idea what the second exception is going to be; 
> I just know what it's *not* going to be, which means I'd need a 
> Pokemon-catch if I wanted to log it.  That's what I am not comfortable with.
>
> I asked you above, what do you think ab

Re: [PSR-11] Exceptions

[Daniel Plainview]

> but because it doesn't know that it's a child it just throws "I don't 
have it", which gets thrown all the way up to the initial caller, who goes 
"wait, wat?"

It would be considered as bugged PSR-11 implementation. 

> then it needs to wrap that inner Not-Found with... something.  That 
something should be standardized.

Why?

On Thursday, November 3, 2016 at 6:32:15 PM UTC+3, Larry Garfield wrote:
>
> From moufmouf in that thread:
>
> " The logic behind this is that if a user is calling the get method on 
> 'foo' and 'foo' does not exist, it is very different from the user 
> calling get on 'foo' and the 'foo' service has a missing dependency. In one 
> case, maybe the user screwed up something (i.e. checked exception), in the 
> other case, it is the container configuration that is screwed up 
> (i.e. unchecked exception)."
>
> They are different error cases.  Different error cases should be different 
> exceptions.  If not, then based on the spec alone (no metadoc, no GitHub 
> threads) the following would be legal:
>
> try {
>   $c1->get('a');
> } catch (NotFoundExceptionInterface $e) {
>   print $e->getMessage();
>   // prints "Service 'b' not found"
> }
>
> Because a delegated container didn't have a particular dependency, but 
> because it doesn't know that it's a child it just throws "I don't have it", 
> which gets thrown all the way up to the initial caller, who goes "wait, 
> 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
>  
> 
> .
> 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/ade5a821-e32a-45bb-995d-18564974bbcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Exceptions

[Daniel Plainview]

If you need to know whether dependency of a service is missing and you have 
some special logic behind it... What about 
DependencyArgumentTypeMismatchException, MissingRequiredArgumentException 
and tons of others container-is-screwed exceptions? What makes them less 
important? 

(question to Larry)

On Thursday, November 3, 2016 at 12:53:13 AM UTC+3, Matthieu Napoli wrote:
>
> 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/08c7dc35-959b-43f5-abac-fddf2e3f4c31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

What do you mean? The namespace is simple "Psr\Container". It doesn't 
clarify domain.

On Wednesday, October 5, 2016 at 5:19:40 AM UTC+3, Woody Gilk wrote:
>
> Why should a class name contain information that is present in the class 
> namespace? If you don't like the class name, there is the option to apply a 
> "use ... as ..." alias.
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> On Tue, Oct 4, 2016 at 7:26 PM, Stefano Torresi  > wrote:
>
>> Il giorno mer 5 ott 2016 alle ore 01:13 Sara Golemon > > ha scritto:
>>
>>> My $0.02USD is that it should have DI in the name (i.e. DIContainer)
>>>
>>
>> 100% agree, but I guess this ship has sailed... ;-)
>>
>> It occurs to my mind that, while most of the development of 
>> container-interop happened outside this list - so FIG members and 
>> bystanders may have not been involved as much as they could - on the other 
>> hand the editors have had the care to post regular updates here, with links 
>> to github, so anybody potentially interested has been given the chance to 
>> chime in.
>>
>> -- 
>> 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/CAFojS1u6WEqGRr4i91vTSd5ohyMfuieqFySA8GsvPpaKr6NkhA%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/0beaa31c-5f64-4969-be0d-a542c342dd08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

It is not great rationale, they might say "see, C# has a prefix convention, 
C# is younger language, etc.".

Most of people don't want to step out of their comfort zone with suffix 
convention, that's it.

On Monday, September 12, 2016 at 12:30:44 PM UTC+3, Dracony wrote:
>
> > This discussion has been going on since the mid-90s when Java was 
> released, at least.  (Maybe longer, but that's when I first encountered 
> it.)  It's a tabs-vs-spaces class of issue.
>
> In that case shouldn't we try to look at how other languages do this? Java 
> Core doesn't have interface suffixes
>
> On Monday, August 15, 2016 at 9:53:26 PM UTC+2, Matthieu Napoli wrote:
>>
>> Hi all,
>>
>> This is a 2 weeks discussion before going to a vote.
>>
>> The "Interface" suffix has been questioned a few times already, I'm 
>> suggesting we put that up to a vote and avoid future debates. Here are 
>> relevant threads I could find on the topic:
>>
>> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
>> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
>> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
>> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>>
>> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be 
>> suffixed by Interface"* from 
>> http://www.php-fig.org/bylaws/psr-naming-conventions/
>>
>> I do not suggest accepted PSRs are changed.
>>
>> Please share your reasons to vote FOR or AGAINST the change, let's debate 
>> for 2 weeks or more, and then let's have a vote to settle this.
>>
>> Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).
>>
>> ---
>>
>> Here are my arguments to vote FOR the change:
>>
>> *- the Interface suffix makes simple names very long*
>>
>> For example with PSR-7, here is the signature of a Slim/Zend Expressive 
>> middleware:
>>
>> public function __invoke(ServerRequestInterface $request, ResponseInterface 
>> $response, callable $next) : ResponseInterface
>>
>> {
>>
>> }
>>
>>
>> Compare that to:
>>
>> public function __invoke(ServerRequest $request, Response $response, 
>> callable $next) : Response
>>
>> {
>>
>> }
>>
>>
>> The last one is much simpler and clearer. Typing and reading the first 
>> one is a huge pain. This point applies of course to all PSRs, not just 
>> PSR-7.
>>
>> *- the Interface suffix makes the interface a detail and the 
>> implementation the main thing, it should be the other way around*
>>
>> We should care about the interface, not the implementation. Type-hinting 
>> against LoggerInterface means that "Logger" (the implementation) is still "
>> *the* logger", and the interface is a secondary concept that we 
>> explicitly inject for decoupling.
>> If "Logger" was the interface, it would be even more obvious that the 
>> interface is the most important part. The implementation is secondary and I 
>> don't even care how it's named. I just want a logger and that's what the 
>> interface is.
>>
>> Regarding the inconsistency it would create between PSRs I think it's 
>> nothing compared to what we would gain in terms of developer experience.
>>
>> 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/88c9ec2a-2cd1-4bcf-982c-036c464c4efb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

Sometimes suffix has influence in design decisions, because it hides some 
design issues which cannot be said about tabs-vs-spaces. This comparison is 
not correct.

On Wednesday, August 24, 2016 at 4:49:42 PM UTC+3, Larry Garfield wrote:
>
> On 08/24/2016 07:58 AM, Art Hundiak wrote:
>
> I find it a bit amusing that exact same discussion is taking place here:  
>
> http://programmers.stackexchange.com/questions/329098/naming-issues-should-isomething-be-renamed-to-something
>  
>>
>>
> Different language and I prefix vs Interface suffix but the exact same 
> arguments.
>
>
> This discussion has been going on since the mid-90s when Java was 
> released, at least.  (Maybe longer, but that's when I first encountered 
> it.)  It's a tabs-vs-spaces class of issue.
>
> --Larry Garfield
>

-- 
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/fa87f012-e16f-415f-a9d4-7a851a2f2c21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Daniel Plainview]

This conversion (like some others in this group) looks like the following:

— Why do we need X? 
— Because we can do Y with it!
— Are you sure that Y is a good thing?
— *no answer*.
— OK, let's keep X.

Just for clarity, arguments for this exception are:

* "PEAR most definitely wants to keep the package-level base exception, as 
it is a convention we always expect to be available" -- Because PEAR does 
it.
* "I would also only type-hint against the PSR exceptions for catches." -- 
 Because we can do Y. 
* "having the granularity is nice, and I could potentially see writing 
plugins for systems such as Zend's Z-Ray, Blackfire, etc." -- Interesting 
point. However, I think it has high cost (boilerplate code, noise in shiny 
interfaces, etc.).
* "There are all sorts of unexpected exceptions that an underlying 
implementation might throw .. Those should be made consistent between 
implementations so that I don't have to worry about those differences." -- 
No difference with catch (\Exception)
* "Which would give us a catchable ContainerException, with a 
human-friendly message/code, and access to the underlying 
implementation-specific exception as well if appropriate for debugging." -- 
If the point is to have human-friendly message, you can rethrow it with any 
another exception class, i.e. no difference with throw new 
\RuntimeException('User-friendly message', $e).
 
I have strong feeling that all these exception madness comes from the fact 
that PHP has no concept of checked/unchecked exceptions at language like 
Java, C# and others.
It leads to misunderstandings: do we break BC if we would throw exception 
like \InvalidArgumentException? Should we declare ContainerException in the 
interface? Etc.

If we took into account checked/unchecked separation, we would find out 
that most of noisy and technical exceptions are not supposed to be part of 
public API (interface).
We wouldn't discuss a lot about "Does \InvalidArgumentException break BC?"; 
we wouldn't see many technical notes like this one 

.

Consider NullPointerException from Java.
Does it make sense to rethrow NullPointerException as ContainerException?
Does it OK for you that you'd have bigger trace because of 2 exceptions 
(ContainerException + previous)? It makes debugging harder I think, not 
easier like someone said above. 
Any method can throw NullPointerException. Code must deal with it. It makes 
no sense to convert it to ContainerException.

ContainerException doesn't allow you to understand what exactly is wrong 
with container.
If you just want to prevent program crash because of it, you'd catch just 
\Exception or even \Throwable, no point to catch ContainerException.

ContainerException is unnecessary noise in your shiny interface. Like any 
other noise it moves developer away from the domain (DI containers in this 
case), it makes him think about unnecessary technical details. It doesn't 
help, seriously. 

On Sunday, August 21, 2016 at 11:36:05 PM UTC+3, Matthieu Napoli wrote:
>
> Hi all, thanks for participating in this discussion.
>
> While David and I feel the same, it seems we are alone. We do not see real 
> usage (not implementations or "what ifs" but actual usage) of that 
> interface today (see https://github.com/php-fig/container/pull/2).
>
> However its not worth blocking PSR-11 any longer because of such a detail, 
> so let's go with the majority and move forward!
>
> 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/330b6616-55f5-46ee-b9dd-089488309ffc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

HttpRequest is not good name, because Request from PSR-7 is already 
HTTP-request.

However, when I asked community about lack of different 
implementations, Matthew Weier O'Phinney said the following (
https://groups.google.com/forum/#!topic/php-fig/RQuMBMD48zU):

> Guzzle has traditionally focused on client behavior, and has 
optimizations around memory usage and generator driven streams; streams are 
its particular strength
> Diactoros and Slim focus on server side details, with the former being a 
full, general purpose implementation

If these implementations are truly different, I don't understand why they 
can't reflect it in the name (thanks to Matthew): ClientFocusedRequest, 
ServerSideFocusedRequest, MemoryEfficientRequest, FullRfcCompatibleRequest, 
etc.
If they are not truly different, why do you need the interface at all?
You either have *different* implementation or you have the only one, as 
simple as that.

On Thursday, August 18, 2016 at 5:46:21 PM UTC+3, Woody Gilk wrote:
>
>
> On Thu, Aug 18, 2016 at 9:24 AM, Erik Landvall  > wrote:
>
>> @Woody | It depends on what type of request it is. The implementation IMO 
>> could be called `HttpRequest`. But others may have internal and external 
>> requests.. eg. InternalRequest and ExternalRequest.
>
>
> That's just replacing a suffix with a prefix. Zero sum game.
>
> --
> 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/26e9735e-e9a8-4399-aa42-a56deb10298e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

> Are you saying that every PSR-7 implementation is using poor naming 
conventions because they define:

Yes, I'm saying that. Furthermore, if you remember, I was trying to say 
that PSR-7 is flawed from my point of view: Request/Response should be 
concrete classes. There is no real place for specificity here. 
But if you really insist on it, I'd call them ZendRequest, GuzzleRequest, 
etc. Another way: MemoryEfficientRequest, HardCoreRfcRequest, etc. :)

> This is effectively back to using the Abstract prefix, except with a 
vendor name. Is that really a win for anyone?

The thing is implementation name is not significant. You program to an 
interfaces, not implementations.

On Thursday, August 18, 2016 at 5:04:33 PM UTC+3, Woody Gilk wrote:
>
>
>
> On Thursday, August 18, 2016 at 3:31:16 AM UTC-5, Daniel Plainview wrote:
>>
>> Also, you wouldn't be allowed to have poor naming like Foo implements 
>> FooInterface. It looks like naming impotence: you have implementation, why 
>> you can't describe what makes this implementation specific: MySqlFoo? 
>> MemcachedFoo? ZendFoo? 
>>
>
> Are you saying that every PSR-7 implementation is using poor naming 
> conventions because they define:
>
> class Request implements RequestInterface { ... }
>
> It sure seems like it. What should these be named? GuzzleRequest, 
> DiactorosRequest? So then we'd have:
>
> namespace Zend\Diactoros;
>
> use Psr\Http\Request;
>
> class DiactorosRequest implements Request { ... }
>  
> This is effectively back to using the Abstract prefix, except with a 
> vendor name. Is that really a win for anyone?
>

-- 
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/d3e6bbbc-c8a9-4c02-87b4-2c6e85824e64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

My bad, I thought your "makes it more comfortable" was in favour of keeping 
suffix. I mean, this should not be comfortable. ;)

On Thursday, August 18, 2016 at 5:00:17 PM UTC+3, Erik Landvall wrote:
>
> @Daniel Plainview | thanks for your feedback, but I don't know if you 
> skipped the whole message I typed after the initial sentence. What you 
> describe is my conclusion as well. Please see my TL;DR:
>
> *- Suffixes like `Interface` adds redundant noise to the code.*
> *- Using the suffix makes it more comfortable to create an implementation 
> that is not using a naming convention that declares it's implementation 
> from a semantic perspective (eg. implementing a CacheInterface into a class 
> named Cache)*
>

-- 
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/82ee3dcb-f70f-4a57-b344-d1e6db8a87c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

> I'm all in favor for noise reduction in my code, but couldn't really see 
any solution to the conflicting name conventions I faced

Please, read messages above.

> Why *specific* implementation has *non-specific* and generic name? Yet 
another point for removing suffix: it forces to think about implementation 
name more.
> ...
> Also, you wouldn't be allowed to have poor naming like Foo implements 
FooInterface. It looks like naming impotence: you have implementation, why 
you can't describe what makes this implementation specific: MySqlFoo? 
MemcachedFoo? ZendFoo? 

In short: if your implementation name is simple "Bar" and interface is 
"Bar", you're doing it wrong. So you failed to describe the 
intention/specificity/point of your implementation.

On Thursday, August 18, 2016 at 4:10:25 PM UTC+3, Erik Landvall wrote:
>
> I had this discussion with some people from room 11. The general opinion 
> to me seem to be *not* to use the interface suffix, so I started looking at 
> why. I'm all in favor for noise reduction in my code, but couldn't really 
> see any solution to the conflicting name conventions I faced. Someone 
> pointed out to me that you would place implementations in a different 
> namespace or sub space. But this generated some strange names such as:
>
> ```
> use Foo\Bar;
> use Foo\Bar\Bar as BarBar;
> ```
>
> IMO, this is worse then the suffixed interface.
> Lets put that into context:
>
>
> ```
> use Foo\Cache;
> use Foo\Cache\Cache as FooCache;
> ```
>
> And if you like to make it even worse, what if the namespace is 
> `Psr\Cache`:
>
> ```
> use Psr\Cache\Cache;
> use Psr\Cache\Cache\Cache as PsrCache;
> ```
>
> ...this makes no sense to me, what is what here? and why require an alias?
> I understand if you don't develop modular and that then the 
> implementations can go in a sub space, such as:
>
> ```
> use Psr\Cache;
> use Psr\Cache\Cache as PsrCache;
> ```
>
> But sense we like components and modules that needs to be distributed as 
> such, then better semantics IMO would be:
>
> ```
> use Cache\Cache;
> use Cache\RedisCache;
> use Cache\MemoryCache;
> use Cache\FileCache;
> ```
>
> ...implementations should define how they are implemented. When I later 
> declare a dependency, I'm declaring that my class is dependent on a Cache 
> instance, the interface suffix is redundant.
>
> On a different note, if we are discussing to remove the `Interface` 
> suffix, then included in the discussion should also be `Trait` suffixes and 
> `Abstract` prefixes as mentioned before. Maybe it can be considered best 
> discussed in different threads? In that case, please correct me, but I 
> would say that it's the same category and the same arguments.
>
> TL;DR
>
> - Suffixes like `Interface` adds redundant noise to the code.
> - Using the suffix makes it more comfortable to create an implementation 
> that is not using a naming convention that declares it's implementation 
> from a semantic perspective (eg. implementing a CacheInterface into a class 
> named Cache)
>
> > My impression is that the majority of member projects use the Interface 
> suffix.
>
> The argument that "this is the way we always have done it" is not a good 
> argument IMO, evolving implies change. It's an interesting phenomenon 
> though: https://www.youtube.com/watch?v=C9ySOuJ83Ww
>

-- 
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/8bd1130a-19b1-4561-8f14-cf302df29b30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Daniel Plainview]

> How do you propose to resolve this common problem?

It means that Diactoros has naming issue. Why *specific* implementation has 
*non-specific* and generic name? Yet another point for removing suffix: it 
forces to think about implementation name more.

Also, I suggest to read 
this: http://verraes.net/2013/09/sensible-interfaces/

On Monday, August 15, 2016 at 11:02:46 PM UTC+3, Woody Gilk wrote:
>
> How do you propose to resolve this common problem?
>
>
> namespace Zend\Diactoros;
>
> use Psr\Http\Message\ServerRequestInterface;
>
> class ServerRequest implements ServerRequestInterface { ... }
>
>
> When the class name is the same as the interface name, you have to use 
> aliases. The correct approach for the problem you put forward is:
>
>
> use Psr\Http\Message\ServerRequestInterface as ServerRequest;
> use Psr\Http\Message\ResponseInterface as Response;
>
> public function __invoke(ServerRequest $request, Response, callable $next) 
> { ... }
>
>
> To wit, alias the interface in code that uses the interface if you find it 
> annoying.
>
> I am strongly AGAINST this change as it results in churn for an a huge 
> number of projects without adding any value.
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> On Mon, Aug 15, 2016 at 2:53 PM, Matthieu Napoli  > wrote:
>
>> Hi all,
>>
>> This is a 2 weeks discussion before going to a vote.
>>
>> The "Interface" suffix has been questioned a few times already, I'm 
>> suggesting we put that up to a vote and avoid future debates. Here are 
>> relevant threads I could find on the topic:
>>
>> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
>> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
>> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
>> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>>
>> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be 
>> suffixed by Interface"* from 
>> http://www.php-fig.org/bylaws/psr-naming-conventions/
>>
>> I do not suggest accepted PSRs are changed.
>>
>> Please share your reasons to vote FOR or AGAINST the change, let's debate 
>> for 2 weeks or more, and then let's have a vote to settle this.
>>
>> Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).
>>
>> ---
>>
>> Here are my arguments to vote FOR the change:
>>
>> *- the Interface suffix makes simple names very long*
>>
>> For example with PSR-7, here is the signature of a Slim/Zend Expressive 
>> middleware:
>>
>> public function __invoke(ServerRequestInterface $request, ResponseInterface 
>> $response, callable $next) : ResponseInterface
>>
>> {
>>
>> }
>>
>>
>> Compare that to:
>>
>> public function __invoke(ServerRequest $request, Response $response, 
>> callable $next) : Response
>>
>> {
>>
>> }
>>
>>
>> The last one is much simpler and clearer. Typing and reading the first 
>> one is a huge pain. This point applies of course to all PSRs, not just 
>> PSR-7.
>>
>> *- the Interface suffix makes the interface a detail and the 
>> implementation the main thing, it should be the other way around*
>>
>> We should care about the interface, not the implementation. Type-hinting 
>> against LoggerInterface means that "Logger" (the implementation) is still "
>> *the* logger", and the interface is a secondary concept that we 
>> explicitly inject for decoupling.
>> If "Logger" was the interface, it would be even more obvious that the 
>> interface is the most important part. The implementation is secondary and I 
>> don't even care how it's named. I just want a logger and that's what the 
>> interface is.
>>
>> Regarding the inconsistency it would create between PSRs I think it's 
>> nothing compared to what we would gain in terms of developer experience.
>>
>> 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/ea157c85-77b0-4fd4-a945-087ff1970a6c%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/5caafc18-07c6-4e7e-975e-4afefe988e0f%40googlegroups.com.
For more options, visit 

Re: [Cache] Errata regarding \DateTimeInterface

[Daniel Plainview]

Is it bad if you break BC with non-sense implementations?

On Wednesday, July 27, 2016 at 2:01:17 AM UTC+3, Larry Garfield wrote:
>
> From http://www.php-fig.org/psr/psr-6/#error-handling
>
> " For that reason Implementing Libraries MUST NOT throw exceptions other 
> than those defined by the interface"
>
> The spec explicitly says not to throw exceptions except where explicitly 
> specified.  We can't recommend throwing an extra exception then without it 
> being a BC break in the specification, which would affect potentially all 
> current users of it.  (There are multiple PSR-6 implementations already in 
> the wild, and no doubt projects using them.)
>
> Whatever the arguments for an exception may be, I don't think we can 
> consider them without a BC break.
>
> --Larry Garfield
>
>
> On 07/26/2016 04:30 PM, Daniel Plainview wrote:
>
> > Throwing `\InvalidArgumentException` is
> > another widely used alternative, however, that would be a change in the
> > specification (as Calling Libraries would then need to know to catch that
> > exception as well).
>
> Let me disagree. Why Calling Libraries have to know about it? Why Calling 
> Libraries don't have to know about AssertionError exception then?
>
> PHP is annoying in this part: it doesn't distinguish between checked and 
> unchecked exceptions at language level
> like Java does.
> However, it doesn't mean that we have to treat all exceptions as checked 
> ones.
> Who said that \InvalidArgumentException or, let's say, \LogicException 
> must be documented?
>
> These exceptions are very close to runtime exceptions in Java: 
> https://docs.oracle.com/javase/7/docs/api/java/lang/RuntimeException.html
> And runtime exceptions include, for example, IllegalArgumentException.
> These exceptions notify about errors, this is not public contract of an 
> interface. 
> You usually don't need to catch them directly. They just should be fixed 
> at the code level. Or infrastructure level.
>
> (Moreover, in my opinion, \LogicException is something that close to 
> compile errors in Java, not even runtime exceptions, because it includes 
> http://php.net/manual/en/class.badmethodcallexception.php).
>
> On Tuesday, July 26, 2016 at 10:46:53 PM UTC+3, Larry Garfield wrote: 
>>
>> Hi folks.  Based an a recent discussion with someone writing a PSR-6 
>> implementation, I would like to offer the following errata for PSR-6: 
>>
>> https://github.com/php-fig/fig-standards/pull/787 
>>
>> I think the text of it is rather self-explanatory, and I link to the 
>> original GitHub discussion that spawned the question. 
>>
>> Comments/feedback/etc. welcome.  As it's a non-trivial change (although 
>> not API changing) it would probably need a vote, but likely an 
>> uncontroversial one. 
>>
>> --Larry Garfield 
>>
> -- 
> 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/8a897f5c-41b1-436e-95ed-38397cfccead%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/php-fig/8a897f5c-41b1-436e-95ed-38397cfccead%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/ea0265f3-e1ff-44a4-a734-5cc7f866fc76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Cache] Errata regarding \DateTimeInterface

[Daniel Plainview]

> Throwing `\InvalidArgumentException` is
> another widely used alternative, however, that would be a change in the
> specification (as Calling Libraries would then need to know to catch that
> exception as well).

Let me disagree. Why Calling Libraries have to know about it? Why Calling 
Libraries don't have to know about AssertionError exception then?

PHP is annoying in this part: it doesn't distinguish between checked and 
unchecked exceptions at language level
like Java does.
However, it doesn't mean that we have to treat all exceptions as checked 
ones.
Who said that \InvalidArgumentException or, let's say, \LogicException must 
be documented?

These exceptions are very close to runtime exceptions in 
Java: https://docs.oracle.com/javase/7/docs/api/java/lang/RuntimeException.html
And runtime exceptions include, for example, IllegalArgumentException.
These exceptions notify about errors, this is not public contract of an 
interface. 
You usually don't need to catch them directly. They just should be fixed at 
the code level. Or infrastructure level.

(Moreover, in my opinion, \LogicException is something that close to 
compile errors in Java, not even runtime exceptions, because it includes 
http://php.net/manual/en/class.badmethodcallexception.php).

On Tuesday, July 26, 2016 at 10:46:53 PM UTC+3, Larry Garfield wrote:
>
> Hi folks.  Based an a recent discussion with someone writing a PSR-6 
> implementation, I would like to offer the following errata for PSR-6: 
>
> https://github.com/php-fig/fig-standards/pull/787 
>
> I think the text of it is rather self-explanatory, and I link to the 
> original GitHub discussion that spawned the question. 
>
> Comments/feedback/etc. welcome.  As it's a non-trivial change (although 
> not API changing) it would probably need a vote, but likely an 
> uncontroversial one. 
>
> --Larry Garfield 
>

-- 
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/8a897f5c-41b1-436e-95ed-38397cfccead%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The CLI interface PSR brainstorm

[Daniel Plainview]

> I am very aware of the difference, in fact I was talking about different 
proposals, while starting from a baseline abstraction.

Well, still, I'm not sure how these two different concepts may have the 
same "baseline abstraction".
Even if interfaces for command message and for CLI command would 
*accidentally* look identically, they are not related.
They are very different domains and trying to find "baseline abstraction" 
for non-related domains is weird idea for me.

"*The purpose of abstraction is not to be vague, but to create a new 
semantic level in which one can be absolutely precise*".
And generic CommandInterface w/o context (CLI, Command message pattern, GoF 
Command pattern, ...) is vague interface, hence wrong abstraction.

> I never suggested conflating commands with business logic, where did you 
get that from?
Sorry for this confusion, second part of my message was directed 
to participants above.

On Saturday, July 9, 2016 at 4:23:42 PM UTC+3, Stefano Torresi wrote:
>
>
>
> Il giorno sab 9 lug 2016 alle ore 14:43 Daniel Plainview <
> daniel...@gmail.com > ha scritto:
>
>> > like a generic CommandBus rather than a CLI specific one
>> Please, don't mix up things. CommandBus has nothing to do with CLI 
>> Command. 
>>
>
> I am very aware of the difference, in fact I was talking about different 
> proposals, while starting from a baseline abstraction.
>  
>
>> CLI Command is just UI detail exactly like HTTP controllers.
>> They are not place for business logic.
>> This problem is already known as 
>> https://en.wikipedia.org/wiki/Magic_pushbutton anti-pattern.
>>
>
> This has nothing to do with my suggestion. Again, I was suggesting to 
> start with a simple interface.
> I never suggested conflating commands with business logic, where did you 
> get that from?
>  
>
>> Thus, it's better to ask sane API (decoupled from UI) from mentioned 
>> vendors (Doctrine and others) in order to make things
>> instead of asking abstract CLI commands.
>>
>
> I'm not sure I understand.
> All there is to a PSR is a specification document and a set of interfaces. 
> This *is* about abstractions.
>

-- 
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/0899872e-e718-4e37-8ed1-1922ef9e7797%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The CLI interface PSR brainstorm

[Daniel Plainview]

> like a generic CommandBus rather than a CLI specific one
Please, don't mix up things. CommandBus has nothing to do with CLI Command. 

CLI Command is just UI detail exactly like HTTP controllers.
They are not place for business logic.
This problem is already known as 
https://en.wikipedia.org/wiki/Magic_pushbutton anti-pattern.
Thus, it's better to ask sane API (decoupled from UI) from mentioned 
vendors (Doctrine and others) in order to make things
instead of asking abstract CLI commands.

On Thursday, July 7, 2016 at 3:58:40 PM UTC+3, Stefano Torresi wrote:
>
> I think starting with just a Command interface would be best, and possibly 
> leaving the executor to a different PSR (or even multiple PSRs, like a 
> generic CommandBus rather than a CLI specific one).
>
> The main use case is that there are already plenty of vendor specific 
> implementations and adapters in the wild.
>
> I don't agree with Andrew's point about limiting innovation. I reckon 
> commands are much simpler to model than HTTP messages; the API would be 
> minimal, so it shouldn't impose relevant limitations to implementors.
>
> I'm not even sure what is left to innovate in CLI applications, as they've 
> always been pretty much the same since the dawn of shells: invoke by name, 
> may accept input (arguments and/or stream), may provide output, will 
> provide an exit code.
> Am I missing anything?
>
> Furthermore, at end of the day its always a Recommendation; nothing 
> prevents anyone from doing their own thing.
>
> For example, Python has a comprehensive standard library for everything 
> Andrew mentioned (stdin, stdout, stderr, argc, argc, cwd), with multiple 
> builtin modules around the same details (e.g. getopts and argparse). Has 
> that prevented any innovation in Python CLI applications? Nope, I'm sure 
> there some exotic packages to parse CLI arguments in PyPI.
>
> And we're not even proposing implementations here.
>

-- 
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/dcebf668-78f8-45a5-a71d-859fe2a01f8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The CLI interface PSR brainstorm

[Daniel Plainview]

The problem is some things shouldn't be framework-agnostic, because they 
*are* framework.
They are what make us to choose one framework in favour of another.
Here is place for personal preferences.
I'd be careful with proposals like "because we can".

On Monday, June 27, 2016 at 10:57:46 AM UTC+3, Dracony wrote:
>
> A year or maybe two ago I proposed a PSR for "tasks", that would allow 
> easier chaining of common things like e.g. migrating a database, minimizing 
> CSS, etc. Back then it didn't really get much traction I believe because 
> PHP world isn't really requiring as much build chains as say JS world 
> (where gulp and Grunt plugins are abundant).
>
> So instead I wanted to rephrase it now as a Command PSR, which is 
> basically standardizing something akin to Symfony Command, which would be 
> really really useful, since then you wouldn't need a special service 
> provider to get Doctrine migrations in Silex, etc. A common interface would 
> be very simple to achieve, but it requires standardizing the CLI interface 
> first. So let's do that!
>
> Ok, so to describe the CLI interface we need:
>
>
>- Input/Output streams for input, output and error
>- Methods to get options and arguments
>- Method to get current working directory
>
> Getting this PSR done will open the way for the Command PSR too, and that 
> will be just as useful to the CLI world and Middleware PSRs are for HTTP 
> world.
>
> What do you think? Did I catch your attention? If so, let's get cracking =)
>

-- 
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/ca1b3a42-8c48-41fd-bcfc-20407bd946df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-7] Do different implementations truly exist?

[Daniel Plainview]

> I'd say that the variety of stream implementations is one of the reasons 
someone would opt to use Guzzle's PSR-7 library instead of another, so it 
seems to directly answer the original poster's question

No, it's not.

Please, pay attention that I talk about *value objects* Request and 
Response.

Stream is not a value object, it's more like a service.
Stream may have external dependencies, different implementations. 
Having interface for the Steam is perfectly fine.
This part of PSR (streams) is the space for different implementations of 
course.

However, value objects are different story.
They shouldn't have external dependencies.
They are not services.
You don't want to have different implementations of DateTime, DateInterval, 
DateTimeZone, etc.

On Monday, June 27, 2016 at 8:43:11 PM UTC+3, Jonathan Eskew wrote:
>
>
>
> On Sunday, June 26, 2016 at 1:32:37 PM UTC-7, Christopher Pitt wrote:
>>
>> Stream implementation is definitely out of scope for FIG, it has nothing 
>>> to do with this topic.
>>
>>  
>> It is of particular interest to the async interoperability work going on. 
>> Perhaps we'll get a specification/implementation out of there...
>>
>
> PSR-7 defines an interface for streams, and Guzzle offers a suite of 
> implementations (as detailed at 
> https://github.com/guzzle/psr7#stream-implementation). I'd say that the 
> variety of stream implementations is one of the reasons someone would opt 
> to use Guzzle's PSR-7 library instead of another, so it seems to directly 
> answer the original poster's question. Not sure how it is off topic.
>

-- 
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/1448bae5-12d7-4ce1-9eb5-a7190b78d581%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-7] Do different implementations truly exist?

[Daniel Plainview]

Sorry for typos, btw. 
These mailing lists, eh...

On Friday, June 24, 2016 at 11:39:55 PM UTC+3, Daniel Plainview wrote:
>
> Hi,
>
> I'm glad to see that you raised similar questions.
>
> It definitely makes sense to make some research on this topic and find out 
> differences in most popular implementations.
>
> Just another my 2 cents...
>
> If there are multiple implementations with different validation and all 
> these implementations strictly respect PSR-7, then PSR-7 has "white spots".
> In makes things more implicit, harder to replace one implementation with 
> another one.
>
> If there are multiple implementations, but they are not strictly respect 
> PSR-7, then they violate the Liskov substitution principle.
> There is no excuse for such violations even for "performance reasons" and 
> "memory usage".
> After all, it's not hard to make official PHP extension.
>
> On Friday, June 24, 2016 at 12:37:53 AM UTC+3, Matthieu Napoli wrote:
>>
>> Hi Daniel,
>>
>> I think this is an interesting question, for reference here is a thread 
>> last month about it: 
>> https://groups.google.com/forum/#!topic/php-fig/u2Nmovw_Rlc
>>
>> If there are specific reasons for multiple implementations then maybe it 
>> would make sense to collect them in PSR-7's meta-document? That way it will 
>> be documented. If there are no reasons, then maybe it's worth discussing 
>> standardizing an implementation?
>>
>> Matthieu
>>
>> Le mardi 21 juin 2016 10:15:59 UTC+2, Daniel Plainview a écrit :
>>>
>>> > Guzzle has traditionally focused on client behavior, and has 
>>> optimizations around memory usage and generator driven streams; streams are 
>>> its particular strength. Diactoros and Slim focus on server side details, 
>>> with the former being a full, general purpose implementation, and the 
>>> latter only implementing the server request and response (IIRC).
>>>
>>> It means that they are not fully compatible. Guzzle allows arbitrary 
>>> header name, for example.
>>> It's harder to trust another implementation if they are behaves 
>>> differently like *this*.
>>> Also it's not clear for me that Guzzle ignores validation on purpose. 
>>> Maybe it's a bug. :)
>>>
>>> > Where I'm seeing differentiation is around convenience features. As an 
>>> example, specialized response types for json, html, XML, or even callable 
>>> or iterator streams. Additionally, populating a server request typically 
>>> requires a factory, and that detail will change based on whether you're 
>>> using an SAPI or an async server.
>>>
>>> It's like saying that 
>>> final FryGotFrozenAt extends \DateTime
>>> {
>>> public function __construct() {
>>> parent::__construct('1999/12/31 18:00:00 UTC');
>>> }
>>> }
>>>
>>> is different implementation of DateTime.
>>> But I think it's not concern of Request/Response objects to work with 
>>> different formats.
>>> Sooner or later you may come to request/response-as-a-service with DI 
>>> dependencies, configuration, etc.
>>> I don't this that having XmlResponse is an advantage, I see the opposite.
>>> You can fill your request/response objects in different layers.
>>>
>>> > This is not s valid comparison. Each of these projects predates psr-7, 
>>> and adding psr-7 support cannot be done without breaking backwards 
>>> compatibility.
>>> Exactly what I tried to say. Almost all existing (pre-PSR-7) libraries 
>>> are not compatible; every new future implementation will be very similar to 
>>> other ones.
>>>
>>> > Considering we have multiple implementations that do differ, and which 
>>> are now generating errata due to differences observed, I disagree with your 
>>> assertion.
>>>
>>> Of course you will see differences, but the question is if these 
>>> differences are "true" and "valid"?
>>> They differ in terms of lack of validation (if you mean that case with 
>>> withHost()).
>>> It reveals design issue: they shouldn't differ here; they should behave 
>>> the same.
>>>
>>> On Tuesday, June 21, 2016 at 6:59:13 AM UTC+3, Matthew Weier O'Phinney 
>>> wrote:
>>>>
>>>>
>>>> On Jun 20, 2016 3:47 PM, "Daniel Plainview" <daniel...@gmail.com> 
>>>> wrote:
>>>> >
>>>> > Hello,
>&

Re: [PSR-7] Do different implementations truly exist?

[Daniel Plainview]

Hi,

I'm glad to see that you raised similar questions.

It definitely makes sense to make some research on this topic and find out 
differences in most popular implementations.

Just another my 2 cents...

If there are multiple implementations with different validation and all 
these implementations strictly respect PSR-7, then PSR-7 has "white spots".
In makes things more implicit, harder to replace one implementation with 
another one.

If there are multiple implementations, but they are not strictly respect 
PSR-7, then they violate the Liskov substitution principle.
There is no excuse for such violations even for "performance reasons" and 
"memory usage".
After all, it's not hard to make official PHP extension.

On Friday, June 24, 2016 at 12:37:53 AM UTC+3, Matthieu Napoli wrote:
>
> Hi Daniel,
>
> I think this is an interesting question, for reference here is a thread 
> last month about it: 
> https://groups.google.com/forum/#!topic/php-fig/u2Nmovw_Rlc
>
> If there are specific reasons for multiple implementations then maybe it 
> would make sense to collect them in PSR-7's meta-document? That way it will 
> be documented. If there are no reasons, then maybe it's worth discussing 
> standardizing an implementation?
>
> Matthieu
>
> Le mardi 21 juin 2016 10:15:59 UTC+2, Daniel Plainview a écrit :
>>
>> > Guzzle has traditionally focused on client behavior, and has 
>> optimizations around memory usage and generator driven streams; streams are 
>> its particular strength. Diactoros and Slim focus on server side details, 
>> with the former being a full, general purpose implementation, and the 
>> latter only implementing the server request and response (IIRC).
>>
>> It means that they are not fully compatible. Guzzle allows arbitrary 
>> header name, for example.
>> It's harder to trust another implementation if they are behaves 
>> differently like *this*.
>> Also it's not clear for me that Guzzle ignores validation on purpose. 
>> Maybe it's a bug. :)
>>
>> > Where I'm seeing differentiation is around convenience features. As an 
>> example, specialized response types for json, html, XML, or even callable 
>> or iterator streams. Additionally, populating a server request typically 
>> requires a factory, and that detail will change based on whether you're 
>> using an SAPI or an async server.
>>
>> It's like saying that 
>> final FryGotFrozenAt extends \DateTime
>> {
>> public function __construct() {
>> parent::__construct('1999/12/31 18:00:00 UTC');
>> }
>> }
>>
>> is different implementation of DateTime.
>> But I think it's not concern of Request/Response objects to work with 
>> different formats.
>> Sooner or later you may come to request/response-as-a-service with DI 
>> dependencies, configuration, etc.
>> I don't this that having XmlResponse is an advantage, I see the opposite.
>> You can fill your request/response objects in different layers.
>>
>> > This is not s valid comparison. Each of these projects predates psr-7, 
>> and adding psr-7 support cannot be done without breaking backwards 
>> compatibility.
>> Exactly what I tried to say. Almost all existing (pre-PSR-7) libraries 
>> are not compatible; every new future implementation will be very similar to 
>> other ones.
>>
>> > Considering we have multiple implementations that do differ, and which 
>> are now generating errata due to differences observed, I disagree with your 
>> assertion.
>>
>> Of course you will see differences, but the question is if these 
>> differences are "true" and "valid"?
>> They differ in terms of lack of validation (if you mean that case with 
>> withHost()).
>> It reveals design issue: they shouldn't differ here; they should behave 
>> the same.
>>
>> On Tuesday, June 21, 2016 at 6:59:13 AM UTC+3, Matthew Weier O'Phinney 
>> wrote:
>>>
>>>
>>> On Jun 20, 2016 3:47 PM, "Daniel Plainview" <daniel...@gmail.com> wrote:
>>> >
>>> > Hello,
>>> >
>>> > The one thing in PSR-7 still bothers me: do different implementations 
>>> truly exist?
>>>
>>> Of the top of my head: Diactoros, Guzzle, and Slim, and I've read of 
>>> others working on additional implementations.
>>>
>>> > Or in other words: how these implementations may differ in terms of 
>>> behaviour?
>>>
>>> Guzzle has traditionally focused on client behavior, and has 
>>> optimizations around memory usage and generator