> By my calculations, getting people to agree about smaller, isolated
abstractions should be a lot easier than getting people to agree on a
larger, combined package of abstractions.
You state that general-purpose URI is "smaller, isolated abstraction".
However, in general case, you have to think about use cases more carefully.
Sometimes, it is just really hard work.
It is much harder to find consensus, etc.
On other hand, it's easier to work within specific domain.
You introduce only methods that make sense for this domain.
It increases *cohesion* of the package.
I understand your point, but it's not terrible to have the same concept in
different domains, especially if it behaves slightly differently.
There are a lot of possible variations of the URI I think.
Sometimes you need highly-detailed URI (like
$uri->getQuery()->getParam('foo', 'default')), sometimes you are OK with
$uri->getQuery(): string.
Sometimes you want to limit possible URIs for specific domain (I don't
think it makes sense to allow ftp:// URIs for PSR-7, for example).
Sometimes you want to reduce API of the class, because some parts of it
doesn't make much sense in some domain.
Every abstraction has a price. Sometimes you don't want to pay it and
choose clarity of intent.
On Sunday, September 25, 2016 at 8:35:44 PM UTC+3, Rasmus Schultz wrote:
>
> Why would it be more work to do, for example, a URI abstraction first,
> as a separate PSR?
>
> By my calculations, getting people to agree about smaller, isolated
> abstractions should be a lot easier than getting people to agree on a
> larger, combined package of abstractions.
>
> You had to do the same work regardless, write the same specifications,
> etc.
>
> Does the process itself really create that much overhead?
>
> I mean, I know it's a lot of work - I'm involved in the HTTP factory
> and HTTP middleware proposals right now, and it has been far more work
> than I had ever anticipated.
>
> Anyhow, the main reason I brought it up is, can we fix it? Or is it
> simply too late?
>
> Simply splitting the PSR and packages doesn't seem like an option,
> since unfortunately the package is namespaced as Psr\Http\Message, and
> URIs do not belong to the message sub-domain at all - likewise,
> Streams do not even belong to the HTTP sub-domain.
>
> One way to address this, maybe, would be to simply duplicate the
> interfaces, e.g. so that a class could implement both, say,
> Psr\Http\Message\StreamInterface and Psr\StreamInterface.
>
> The more correct solution would be a 2.0 release of PSR-7 that depends
> on two new PSRs. Client code would need to upgrade by replacing, for
> example, references to Psr\Http\Message\StreamInterface with
> Psr\StreamInterface, etc.
>
> But is there any kind of policy about PSR versioning? Is a 2.0 of an
> existing, approved PSR even a thing, or are they finite and set in
> stone forever?
>
> Or how does that work?
>
>
> On Sun, Sep 25, 2016 at 7:47 AM, Larry Garfield <la...@garfieldtech.com
> <javascript:>> wrote:
> > On 09/24/2016 11:17 PM, Daniel Hunsaker wrote:
> >
> > On Saturday, September 24, 2016 at 7:29:55 AM UTC-6, Rasmus Schultz
> wrote:
> >>
> >> Hey FIG,
> >>
> >> This week, I found myself doing some work with native PHP stream
> >> resources. This particular work had no relation to HTTP at all, but to
> SMTP
> >> as it happens. While writing this project, I thought, I should abstract
> >> streams behind an interface. Of course, then it occurred to me, PSR-7
> >> includes a stream-abstraction. However, PSR-7 is primarily for HTTP
> Messages
> >> - it seemed wrong to depend on an HTTP abstraction just for the
> >> stream-abstraction, so I ended up not doing that. In the end, I went
> with
> >> plain PHP stream resources, for two reasons - primarily because I
> didn't
> >> want to depend on an HTTP abstraction for streams, and also because the
> >> stream-abstraction of PSR-7 doesn't cover stream-filters, which I
> needed for
> >> this project.
> >>
> >> Which brings me to my question: why was the stream-abstraction rolled
> in
> >> with the HTTP abstraction? (I did not find this question/answer in the
> PSR-7
> >> meta.) It seems like a stream-abstraction is a completely general thing
> -
> >> it's not specific to HTTP concerns at all; PHP streams are used for
> plenty
> >> of other things, and this abstraction could perfectly well stand alone
> >> without the HTTP abstraction, or not? A stream-abstraction seems like
> it's
> >> more naturally a dependency of an HTTP abstraction - rather than
> belonging
> >> to it. Is there a rational reason why two seemingly unrelated
> abstractions
> >> were put into a single PSR?
> >
> >
> > My guess (I wasn't involved in the process on this one) is that the
> stream
> > abstraction was considered useful, and no other PSR was already covering
> it
> > at the time. While splitting that into its own PSR makes sense, the
> added
> > complexities of developing a second PSR, especially when the current one
> > relies on its content, would likely have been seen as an unnecessary
> > complication for the current PSR itself - that is, PSR-7 would likely
> still
> > be unapproved, waiting on the Streams PSR to be finalized, first, along
> with
> > all the unforeseen complications it would have along the way. Ultimately
> the
> > right approach? Hard to say, but looking back provides a much different
> view
> > than looking forward.
> >
> >
> > From what I recall, that is a fairly accurate summary. The same applies
> to
> > UriInterface, which is technically useful outside of HTTP messages but
> > trying to factor that out was just more work than anyone had the stomach
> > for.
> >
> >> How would you feel about having a separate PSR for streams? And
> possibly
> >> extending the scope to also include a stream-filter abstraction?
> >
> >
> > For my part, a full-blown Streams PSR makes sense. Especially if it can
> be
> > made to expand the stream interface in PSR-7, such that compatible
> > implementations could be used there as well. Not necessarily *extending*
> it,
> > per se, though I suppose that would probably also be a good idea for
> > continued compatibility between the PSRs. Especially since PSRs can't
> really
> > be revised once approved.
> >
> > Of course, I'm not a voting member, so this is just my 2ยข...
> >
> >
> > I would much rather see PHP's native stream interfaces improved to not
> suck,
> > rendering a user-space wrapper of them unnecessary. If wishes were
> > horses... :-)
> >
> > --Larry Garfield
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "PHP Framework Interoperability Group" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/php-fig/cLfsPZQVTuA/unsubscribe.
> > To unsubscribe from this group and all its topics, send an email to
> > php-fig+u...@googlegroups.com <javascript:>.
> > To post to this group, send email to php...@googlegroups.com
> <javascript:>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/php-fig/fd07b8eb-4194-fa4f-9a89-f71bf54aa520%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/18485011-b25f-450f-b667-93ad9b3599e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
