Re: PSR for HTTP clients

[Jason Judge]

This is my preference too. A 40x or 50x being returned from the remote 
endpoint is an exception *at the remote end*. Whether it is an exception in 
your application is up to your application. The response should still be 
available in full, which can be difficult or at least a little clunky to 
get hold of if the client is throwing exceptions on behalf of your 
application. So IMO the client should get the HTTP response, provide the 
result, then leave the application to decide for itself whether has now 
entered an exceptional state that it cannot get out of.

There may be exceptions raised locally, for example if the URL is invalid 
(if that is even possible, if the URL is an object that *must* be valid 
just to be instantiated), but they are local exceptions for which there is 
not even a response to see. Not sure if timeouts are in this category.

-- Jason

On Friday, 25 August 2017 09:10:06 UTC+1, Barry vd. Heuvel wrote:
>
> So given the unanimous support for the HTTP Client and the current 
> implementations, the only actual point of discussion is the throwing of 
> Exceptions on 4xx/5xx responses, right?
>
> As a library maintainer, I'd like to rely on the behavior of the Client, 
> so either ALWAYS or NEVER, not depending om some hidden config. Otherwise 
> I'd have to check both cases again every time. 
> And in that case my preference would be to NOT throw exceptions on 4xx/5xx 
> errors.
>
> Hope this will make it to a real PSR soon :) Good job!
>
> Op vrijdag 4 augustus 2017 10:25:03 UTC+2 schreef Márk Sági-Kazár:
>>
>> Hi all,
>>
>> Joining the discussion as one of the PHP-HTTP founders.
>>
>> I am not 100% aware of all major HTTP clients wanting to implement this 
>> PSR, but I can speak for Guzzle where the answer is clearly YES. As for 
>> other clients: PHP-HTTP has adapters for major HTTP clients, so there is 
>> proof that the interface can work together with those clients, but given 
>> how adoption looks like now, I have the impression that it's not going to 
>> be a problem.
>>
>> As for exceptions: we had quite a few discussions about throwing 
>> exceptions for HTTP errors. We decided that clients should never throw such 
>> exceptions, not even with a secret configuration. The reason behind is 
>> simply what's already been said above.
>>
>> There are two common exceptions to this rule:
>>
>> - In case of adapters (if the underlying client supports this feature) we 
>> do not forbid this behavior, but we require that with the default 
>> configuration the client does not throw exceptions. When a client 
>> implements this PSR, it should stop throwing exceptions.
>> - There is a PHP-HTTP plugin which converts 4xx/5xx HTTP errors to 
>> exceptions, but it has been said a thousand times (I think it's mentioned 
>> in the documentation as well) that this plugin should only be used when 
>> there is no business logic wrapped around the HTTP workflow or for testing 
>> purposes.
>>
>> Except the two points above, throwing exceptions is already forbidden I 
>> think.
>>
>> Mark
>>
>> 2017. július 13., csütörtök 14:17:23 UTC+2 időpontban Tobias Nyholm a 
>> következőt írta:
>>>
>>> Thank you for all your comments and suggestions. I will bring these to 
>>> the work group if/when it is approved. 
>>>
>>> I lean towards NEVER throw exceptions. 
>>>
>>> And about the exceptions: I agree, they could maybe need some renaming 
>>> and updates to be more clear. 
>>>
>>>
>>>
>>> On Tuesday, July 11, 2017 at 11:18:30 PM UTC+2, Matthieu Napoli wrote:

 I have to agree with Larry, having the behavior of a standard depend on 
 some configuration is risky. If the goal of the PSR is to be used by 
 libraries or frameworks (not end users) then it's fine to force a choice 
 IMO.

 I have minor comments about the proposal, maybe it's too early to get 
 into details and create a proper thread but I would suggest making the 
 exceptions clearer:

  * Exception for when a request failed. * Examples: *  - Request is 
 invalid (eg. method is missing) *  - Runtime request errors (like the 
 body stream is not seekable)interface RequestException extends Exception


 How about InvalidRequestException? (I would suggest InvalidRequest but 
 it would be a waste of time :p)
 We need to make it clear that the HTTP request did not fail, it's the 
 Request object that was invalid.

  * Thrown when the request cannot be completed because of network issues. 
 * There is no response object as this exception is thrown when no response 
 has been received. * Example: the target host name can not be resolved or 
 the connection failed.interface NetworkException extends Exception


 NetworkErrorException? OK maybe this one is too much (NetworkError 
 would be better but…)

 And as said above HttpException should probably be removed entirely?

 Matthieu

 Le mardi 11 juillet 2017 18:33:

Re: PSR6 // Major questions about TTL

[Jason Judge]

On Tuesday, 1 August 2017 20:01:15 UTC+1, Georges L. wrote:
>
>
>
> Le mardi 1 août 2017 05:49:22 UTC+2, Larry Garfield a écrit :
>>
>> On 07/30/2017 09:34 AM, Georges L. wrote:
>>
>> Hello folks,
>>
>> today during a new test implementation (I am the Lead behind 
>> PhpFastCache) I got a major question on a concept of the Psr6:
>>
>> 1) If you set a cache item with a TTL of 1sec, then your script duration 
>> take more than 2secondes: What's the expected behavior of isHit() ? 
>> Supposing that I'm using the *same instance* of my cacheItem during the 
>> whole script execution (not by calling getItem() again).
>>
>>
>> Ok ! 
>
>  
>
>> The cache lifetime applies as of the moment that the request is run, and 
>> isHit() is guaranteed.  That is, if at the millisecond that getItem() or 
>> isHit() runs (technically it could be either, I suppose, depending on the 
>> implementation) the cache item is valid, then that CacheItem object remains 
>> valid until it goes out of scope.
>>
>> 2) In the same spirit: What's the expected behavior of passing a "past" 
>> value to expireAt/ExpirerAfter ? This is not mentioned at all in the Psr6 
>> specs (Only if null is passed)
>>
>>
>> Setting an expire time that's in the past is functionally equivalent to 
>> not setting it.  Whether the implementation even bothers to try writing it 
>> is, I suppose, up to it, but since a lookup for it will always return a 
>> cache miss it doesn't much matter.
>>
>> If I understand well, passing an expired time is the same thing than 
> deleting the CacheItem (by forcing it to expire) ?
>  
>
>> 3) Should getItem() stores instances inside a private property, or should 
>> it MIUST get it from the cache storage directly ? This is not mentioned 
>> either.
>>
>>
>> I'm not sure I follow here.  Can you clarify?
>>
>
> As you can see here:
>
> https://github.com/PHPSocialNetwork/phpfastcache/blob/final/src/phpFastCache/CacheManager.php#L183
>
> I store the cache items objects to re-serve them statically later if 
> needed (until the script end or detachAllItems() is called).
>

Are you asking if the interface can be used as just a single-request cache, 
with items only lasting as long as the current page request? It would 
certainly be nice at times to be able to switch a cache library to this 
mode for development.

-- 
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/e974adfc-7af4-4c85-8a3a-60474d5c6f1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-3] [SUGGESTION] Static version of the logger interface?

[Jason Judge]

On Sunday, 25 June 2017 19:21:33 UTC+1, Joaquin wrote:
>
> Hello. I was wondering if it was at all possible to have a static logger 
> option. For my purposes I do not need an object for logging and calling 
> non-static methods statically is deprecated in PHP 7.
>

Most platforms tend to avoid static libraries, because of the difficulty of 
injecting configuration details. The way to handle it is to instantiate it 
once at the start, with all the settings you need (e.g. file name and 
location, or some other logging channel). Then you keep using that single 
instantiation throughout the remainder of the application.

You just need to be able to *get at* the instantiation from anywhere, which 
means it will ultimately be in the global scope somewhere. Older 
applications would use a global `$logger` variable. Newer applications a 
locator service of some sort. That may be wrapped with a facade to give it 
some static availability. But the idea is, there is one instantiation, and 
the point of use - where messages are logged - should be simple and easy to 
use.

The PSR interface to all this is around the instantiated class, and that 
will be hidden from your main application code under the 
locator/global/facade/other layers you put on top.

-- 
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/7ea0f259-cf23-40d3-b92c-427f96af1ca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Final underscore in class names

[Jason Judge]

On Thursday, 9 March 2017 22:40:08 UTC, Marco Perone wrote:
>
> ...
>
> More broadly, could it be the case to provice a precise definition of what 
> StudlyCaps mean? (If it's not present elsewhere and I'm missing it...)
>

 I'm wondering whether this is a term we should be even using? It seems 
that aNyThiNG can be called studycaps if it mixes upper and lower case 
letters in a word, it is such a broad definition. Wikipedia describes camel 
case as a form of studycaps where only the first letter of each joined 
words is capitalised. And then there are two forms of that: *upper camel 
case* and *lower camel case*, depending on whether the first letter of the 
first work is capitalised.

Of course we all *know* the intention in this PR was to use *upper camel 
case* for ClassNames, but a good and unambiguous definition will always 
beat *just knowing*. It can also beat the various conventions that have 
grown in different programming environments.

-- 
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/ba2e44df-5b33-47a0-aec1-b58d708fd9c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Seeking Explanations of PRS-2 Standards

[Jason Judge]

On Tuesday, 24 January 2017 03:25:36 UTC, Ahmad Samiei wrote:
>
> ...
>
> Re: Ex. Why a blank line at the end of PHP documents?
> Definition of a line in POSIX standard 
> 
> :
> 3.206 Line: A sequence of zero or more non-  characters plus a 
> terminating  character
>
> Otherwise, some programs might have problems processing the last line then.
> Many editors and tools (ex. git) show a warning message if there is no 
> newline at the end of file.
>
>  
Based on this definition, a blank line has zero non- characters 
before its terminating . So that means a PHP file must end with 
TWO sequential  characters in order to end the file with a blank 
line.

However - that was never the intention of that PSR statement. There is NO 
need to put a blank line on the end of each PHP script, in fact you MUST 
NOT have a blank line. You just need to make sure the file consists of 
*lines* according to the POSIX standard, and that the last line is NOT 
blank. It's misleading, and hopefully the replacement for this 
recommendation will make it clearer.

The confusion came from what people *think* they are looking at when 
viewing a script in their favourite editor, rather than how the file is 
really constructed.

-- Jason

-- 
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/3525aeb7-3050-4e91-8d41-581350ae8922%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Jason Judge]

The parser does not look far enough ahead. It sees the text of the heading 
that follows it, and thinks that text is a part of the list (list items 
with blank lines in are a valid syntax for lists with multi-paragraph 
contents). It does not spot the "--" that follows the heading text 
which turns it into an actual heading. The alternate heading syntax (##) 
allows the list parsing to spot that though, as it does not need to look 
any further than the heading line. I've submitted a PR for this.

-- Jason

On Friday, 13 January 2017 10:46:29 UTC, David Négrier wrote:
>
> ...
>
> Regarding your last issue:
>
> > There's a formatting issue in the metadoc, 9.3, contributors: Taylor
> > Otwell is separated from the rest of the group for some reason.  I'm
> > sure there's nothing to be read into that. :-) 
>
> Poor Taylor! :) I've looked at the markdown file and can't find anything 
> weird there. Unless someone can point me to a mistake I did not see, I 
> believe the error spurs from Github markdown parser that is adding an 
> additional  in the  of Taylor for no reason. This does not seems to 
> happen with other markdown parsers... anyone would have a workaround for 
> this?
>
> ++
> David.
>
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/abb9de0a-0e29-43e4-b0d0-3ecd5a99b12b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Jason Judge]

PR 866 https://github.com/php-fig/fig-standards/pull/866 fixes this 
formatting issue. It doesn't fix the obvious bug in github causing it, but 
it uses the alternate markdown syntax that avoids it.

-- Jason

On Thursday, 12 January 2017 23:08:10 UTC, Larry Garfield wrote:
>
> ...
> There's a formatting issue in the metadoc, 9.3, contributors: Taylor 
> Otwell is separated from the rest of the group for some reason.  I'm 
> sure there's nothing to be read into that. :-) 
>
> --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/336e5dfc-b84e-4cd0-a44b-e77497be1e23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] First Core Committee Elections

[Jason Judge]

Here are my votes:

1. Larry Garfield
2. Beau Simensen
3. Samantha Quiñones
4. Graham Daniels
5. Matthew Weier O’Phinney
6. David Négrier
7. Marc Alexander
8. Jason Coward
9. Sara Golemon
10. Cees-Jan Kiewiet
11. Michael Heap
12. Jeremy Coates
13. Lukas Kahwe Smith
14. Stefano Torresi

That's based on what I've read, what I've seen, and is very much weighted 
towards the top by the people I see and interact with the most, and who I 
feel takes the group in positive steps forward. The rest I just don't have 
enough to go on. Good luck everyone!

-- 
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/f4702b42-c7c2-40d2-98f1-c1217bb6a65c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Resigning My Position ...

[Jason Judge]

On Friday, 9 September 2016 15:53:28 UTC+1, pmjones wrote:
>
> Hi all, 
>
> I am resigning my position as sponsor of PSR-8, the "Huggable" Interface. 
> This was a fun joke way-back-when, but its time has passed. 
>
> And if I may suggest it, perhaps the editor should voluntarily withdraw 
> the PSR from consideration. 
>
> Thanks everyone! 
>
 
Is this "voluntary withdrawal" even a thing? If the authors and sponsors 
want to walk away, then surely they can. The PSR is then out of their 
hands. Other people can take it on, or it is abandoned. The idea that 
someone can say that they no longer want to be involved in developing a 
PSR, and no-one else can either, seems a little dangerous to me.

-- Jason

-- 
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/4f77046d-50a7-4f7b-815b-b31bfe06237a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.