Re: PSR-7 Alternate Proposal

[Josh Di Fabio]

Hi John,

How would you implement a middleware which catches an exception thrown by
an inner middleware and returns a response instead of allowing the
exception to bubble up?

On Wed, Feb 22, 2017 at 11:06 AM Michael Mayer 
wrote:

> John, would you mind pushing your interfaces and Stack to github? Thus,
> everybody interested can play with your code, which probably would reduce
> mails 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/a2156982-48f3-424f-b14a-4cb81a6e5335%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/CAKiSzdDtzgUZzro8sEKSq2sB71svD3RGpX_FEaey%2Bok7VEHvrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-13: Link definition interfaces

[Josh Di Fabio]

First of all, Larry, thanks for taking the time to reply. Thanks also to
Matthew for replying yesterday; I felt my response to Larry was sufficient
to cover both emails which is why I haven't quoted you directly.

> It sounds like this is another case of naming things (one of the 2 hard
problems in CS).  There's a proposal on the table to change it to "Catalog":
>
> https://groups.google.com/d/msg/php-fig/D-qAsZ5_f0s/PrKQL7RzAgAJ
>
> Thoughts there?  (As in, over in that thread.)

(On a side note, that link takes me to this current thread, which does
contain messages about renaming the LinkCollectionInterface to
LinkCatalogInterface and is the same one I've been replying to all along.
I'm not sure if Gmail is screwing around or if one of us is missing
something.)

My contention isn't with the name of the interface, I'm simply arguing that
providing an interface for *any object which has links* isn't very helpful
(although a proper LinkCollection object might be).

I think it might be helpful to take a step back and project our solution to
a problem from a different domain. I think that you, Matthew and I all
agree that a Link is a simple value object. A classic example of another
type of value object is a quantity of money. Let's imagine we are creating
a Money PSR instead of a Link PSR. Consider the following interface, which
I believe would be fairly analogous to what you are proposing with the
LinkCollectionInterface (semantically ThisObjectHasLinksOnItInterface):

interface HasMoney
{
public function getMoney(): Money;
}

What use would this interface be? When would we realistically create a
polymorphic function to consume such an object? Rather, the way an object
would expose any money objects it referenced would depend on what those
objects represented in the specific domain of the object itself. For
example:

interface SaleableProduct
{
public function getSalePrice(): Money;

public function getCostPrice(): Money;
}

Similarly, I think that the way links will be exposed by objects will
depend on the domain and context of the object. For example:

interface Author
{
public function getName(): string;

public function getPublicLinks(): LinkCollection;

public function getLinksForUser(string $userId): LinkCollection;
}

I appreciate the example of (HTTP) Resources having links. Defining an
interface to allow polymorphic functions which consume HTTP resource
objects specifically would make sense, but that isn't what is being
proposed here. Regarding your earlier example; there do not appear to be
any polymorphic functions and, therefore, nothing which justifies a
ThisObjectHasLinksOnItInterface. If you are only dealing with a specific
concretion then you have no need to know which abstract interfaces the
object implements. I suspect it would be helpful to identify a real-world
example of a polymorphic function which would make use of this interface
but not require some other domain-specific interface (such as an
HttpResourceInterface).

I feel like I've asked all the questions I can. You guys are the
stakeholders here and are also more likely than I am to make use of this
PSR, so I think I'll leave you to it. I hope my questions have been helpful
even if you do decide that the current approach is the right one!

Cheers

On Wed, Sep 14, 2016 at 4:21 PM Larry Garfield <la...@garfieldtech.com>
wrote:

> On 09/13/2016 09:28 AM, Josh Di Fabio wrote:
>
> On Tue, Sep 13, 2016 at 2:50 PM Larry Garfield <la...@garfieldtech.com>
> wrote:
>
>> The standard example we've been using is a domain object of some sort
>> that then is getting rendered to an HTTP Response.  To wit:
>>
>
>>
>
> Thanks for taking the time to reply.
>
>
>> $article = load_article(...);
>> // Article is a class in a domain model, but can generate links to other
>> articles such as next/prev, up to the index of articles, etc.
>> // ...
>> // LinkableResponse is an implementation of PSR-7 ResponseInterface and
>> LinkCollectionInterface
>> $r = new LinkableResponse(200);
>>
>> // Whatever app-sensitive rendering logic applies, not our problem.
>> $r = $r->withBody(new StringStream(render($article));
>>
>> // The links on article are generated on the fly here,
>> // based off of the underlying data of article, whatever that is.
>> foreach ($article->getLinks() as $link) {
>>   $r = $r->withLink($link);
>> }
>>
>> Forcing both Article and Response to be traversable on links is a no-go,
>> as they may have other data sets in them that would make just as much sense
>> to iterate.  But it makes total sense for Article to be able to provide
>> links (read only) and Response to both accept them and be able to return
>> them (or turn them into HTTP headers directly, or whatever else someone
>&

Re: [REVIEW] PSR-13: Link definition interfaces

[Josh Di Fabio]

Quoting the meta doc.

> Why is a LinkCollectionInterface needed?
> In many contexts, a set of links will be attached to some other object.
Those objects may be used in situations where all that is relevant is their
links, or some subset of their links. For example, various different value
objects may be defined that represent different REST formats such as HAL,
JSON-LD, or Atom.

In my opinion, "some other object" should not be defined by this spec. What
use is an interface for an object which simply "has a collection of links"?
What if that object has multiple accessors for different kinds of links? I
don't see any value in this spec attempting to define what such objects
should look like, so I'd be interested to see a concrete example of why it
is useful (apologies if I missed this in the meta doc).

I would propose either removing the collection interface or making it a
true and useful collection object instead of what we have now. Here's a
suggestion:

interface LinkCollectionInterface extends \IteratorAggregate
{
public function getIterator(): Iterator;

public function filterByRel($rel): LinkCollectionInterface;
}

It would seem better to then replace these interfaces with concrete
implementations, since they are clearly fairly simple value objects, but
from what I can remember it's in your bylaws only to define interfaces.

On Mon, Sep 12, 2016 at 11:52 PM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> On Sep 12, 2016 5:31 PM, "Daniel Hunsaker"  wrote:
> >>
> >> >> I'd expect an object implementing a CollectionInterface to be
> iterable and
> >> >> to already contain the items in question. The current implementation
> of the
> >> >> LinkCollectionInterface though looks more like a CollectorInterface.
> >> >> Something that collects linkInterfaces and can return a
> >> >> LinkCollectionInterface.
> >>
> >>
> >> Matthew and I brainstormed a bit more.  The only other word we could
> >> come up with that we didn't hate even more than "Collection" was
> >> "Catalog".  Which would then result in:
> >
> >
> > Not against Catalog, personally.  However, Andreas did mention Collector
> as an alternate; is that one of the more-hated designators that were
> considered?  That wasn't clear from the above paragraph...
>
> I was hesitant about it, as it implies that the instance is collecting
> instances for purposes of returning a collection, which brings us back to
> the original naming issue.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAJp_myUZ4XH6mG4pNnXfGKavnAhdxN6fMocVngpxmNT6TLi8yA%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/CAKiSzdCW4WjxP9RrOKD4yXsj%2B0FAbH_xQOTjdGE%2BiBDU0N0iEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Josh Di Fabio]

Uncle Bob's opinion: http://stackoverflow.com/a/5817904/4498485

On Wed, Aug 24, 2016 at 2:49 PM 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/c6aaee8c-3c2f-dd0f-253f-bec5999c92a2%40garfieldtech.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/CAKiSzdAGvXoDLzFWCwA9ogM8%2Bc5RKE0enRFC6QBAveBvxPVHjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Josh Di Fabio]

> Different CacheInterface instances MAY be backed by the same datastore, *but
MUST be logically independent.*

The second clause seems to be needlessly restrictive and appears to be
incompatible with decorators. What is the purpose of this clause?

On Wed, Nov 30, 2016 at 4:10 PM Larry Garfield 
wrote:

> On 11/29/2016 02:21 PM, Jordi Boggiano wrote:
> > Yes PSR-16 is meant to live alongside PSR-6, so it has to be
> > reasonably compatible and yes a bridge has been done
> > (
> https://github.com/php-fig/simplecache/commit/13f43ba7f6d5ce37c6c115c26a5f653c2d9c1e18
> ).
> > I agree it shouldn't sound like it depends on PSR-6 though. If you
> > have ideas how to clarify the wording PRs are welcome :)
> >
> > Cheers
>
> I've opened a PR to clarify both the PSR-6 relationship and the "cache
> is not a server" point, as they're related:
>
> https://github.com/php-fig/fig-standards/pull/851
>
> --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/0cf7897f-1334-a7fd-21fb-5bed0e926024%40garfieldtech.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/CAKiSzdDLLb3kec8QnNa-q2%3DO3iS%3DVqCesnVq_Ge_Y8H9B3a_SA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR for HTTP clients

[Josh Di Fabio]

This looks pretty good, but I don't like exceptions for 4xx and 5xx
responses, which smells of exceptions for flow control. Within the context
of HTTP there is nothing exceptional about 4xx and 5xx responses. Rather,
whether a certain response status is considered exceptional depends on the
context of the caller. For example, in many contexts a 3xx response would
be unexpected but a 404 response would not. Instead of throwing, the client
should simply return the response.

On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai 
wrote:

> Very good suggestions.
> Also, it's very pleasant to see a PSR pushed this way and backed from the
> start by a working lib and all the interestend players. Really good job!
>
>
> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha scritto:
>
>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>
>> Excellent questions. Thank you.
>>
>> The buy-in would be the same for every PSR, wouldn't it? Libraries do not
>> want to depend on an implementation or provide an implementation
>> themselves. They want the user to decide if a highly flexible client
>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source:
>> https://github.com/joelwurtz/http-client-benchmark). Also, as you
>> probably noticed, there are representatives from all PSR7 compliant HTTP
>> clients in the workgroup.
>>
>>
>> That last point was what I was getting at, thank you.  By buy-in, I mean
>> "do we have an indication that the major HTTP clients are going to adopt
>> it?"  It sounds like the answer is a loud "yes", which is great to see.
>>
>> The simplest answer of async or not is: There is not PSR for Promises
>> yet. I do not think the PSR for HTTP clients should define what the
>> industry standard for a Promise should be. I do also not think we should
>> wait with a PSR for HTTP clients until (if ever) a PSR for promises has
>> been released.
>>
>> We, php-http team, have followed discussions in
>> https://github.com/async-interop that sadly has been put on hold.
>>
>>
>> A fair reason, thanks.  It may be worth mentioning in the metadoc,
>> including what a future Async version MIGHT look like if/when a Promises PS
>> happens.  (You don't need to implement it, just show that it could still be
>> implemented.)
>>
>> --Larry Garfield
>>
>> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>>>
>>> The key for me is if the various HTTP clients have buy-in to implement
>>> the spec once completed.  Is that the case?
>>>
>>> I would also ask why this is just for sync HTTP clients, not async.
>>> There's plenty of use cases for the latter.  That may be scope creep, but I
>>> feel it's worth asking.
>>>
>>> --Larry Garfield
>>>
>>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>>
>>> Hi,
>>>
>>> +1 for first creating working stuff and later doing effort to make it a
>>> good standard. Way better approach than the other way round :)
>>>
>>> Great work.
>>>
>>> Cheers and great weekends!
>>> --
>>> Tuomas
>>>
>>>
>>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet 
>>> wrote:
>>>
 Hey,

 This looks interesting, would have to study this in detail but I do
 like the simplicity from a quick read through.

 Cees-Jan


 On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm 
 wrote:

> Hey.
>
> Im a co-creator of HTTPlug and a maintainer of a number of API
> clients. I would really like to see a PSR for synchronous HTTP clients. 
> The
> HTTPlug has created a "meta-standard" which has been stable for 18 months
> now. We believe it is a really good interface and would like it (or
> something similar) to be an official PSR.
>
> I would ask the Fig for an entrance vote.
>
> *Here is a first idea: *
> PSR:
> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
> Meta:
> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>
> *Workgroup*:
> These people has been contacted and said they are interested in
> participating in a workgroup.
>
>- Tobias Nyholm
>- Sara Golemon (cc)
>- Matthew O'Phinney (cc) (Maybe)
>- Mark Sagi-Kazar
>- Jermey Lindstrom
>- David Buchmann
>- Joel Wurtz
>- Simon Asika
>- Christian Lück
>- David De Boer
>
>
> --
> 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/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com
>