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

[Andreas Heigl]

Hi All.

Am 22.09.16 um 21:00 schrieb Larry Garfield:
> On 09/21/2016 08:57 PM, Stefano Torresi wrote:
>> As far as I can tell, the problem is that currently the so called
[...]
> 
> Matthew and I discussed this a bit.  LinksProviderInterface is the first
> suggestion that for lack of a less emotionally-based term "clicks", and
> doesn't become even more confusing.  We're tempted to add that to the
> poll and restart it. :-)  (I saw you posted it there, too.)  As you
> note, though, EvolvableLinkProviderInterface would be a bit odd. 
> Thoughts from others?
> 
> Really, the core issue is that the object in question contains links,
> and MAY allow you to add more to them, but ALSO contains other stuff
> that isn't links.  So it is a collection of links, but doesn't have the
> exclusivity that "collection" has come to have. (Viz, it's not a fancy
> OOP array of links.)  That's really the problem; the name "collection"
> would have likely been fine 3 years ago, but these days we expect more
> of that word but have no word to replace its previous, more limited
> meaning. :-/


For me the core issue is that - even though the object contains links
(is a LinkContainer so to say) - it also contains other things. And for
me a Collection implies that it contains *only* items of a certain kind.
So for me it's more that the object *contains a collection of links*.
And as such it provides access to links so a LinksProviderInterface
would work for me. I'd prefer a LinksCollectionProviderInterface but
that's getting a bit ridiculous :)

Especially when we come to the EvolvableLinksCollectionProviderInterface…

A LinksContainerInterface would be another option but hey…

My 0,02 €

Cheers

Andreas
-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+

-- 
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/f51ec0b8-8481-6feb-78ea-10e8963c4cb3%40heigl.org.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: PSR-7: why do Streams belong to this PSR?

[Rasmus Schultz]

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

Re: [VOTE] "FIG 3.0" Bylaw amendments (Take 2)

[Paul Dragoonis]

PPI votes +1

On 24 Sep 2016 00:00, "Chuck Burgess"  wrote:

> +1 from PEAR
>
> On Sep 23, 2016 13:39, "Michiel Rook"  wrote:
>
>> +0 Phing
>>
>> On 17-9-2016 1:14, Larry Garfield wrote:
>>
>> I hereby open a vote for the following bylaw changes, colloquially known
>> as "FIG 3.0".  I'm fairly certain anything that needs to be said has been
>> said by now by all parties.
>>
>> https://github.com/php-fig/fig-standards/pull/752
>>
>> The vote will be open for 2 weeks, closing on 30 September 2016.
>>
>> As usual, the vote is open to voting representatives only and is a simple
>> +1/-1 vote.
>>
>> --Larry Garfield
>>
>>
>>
>>
>> --
>> [image: Avast logo] 
>>
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com 
>>
>> --
>> 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/ms
>> gid/php-fig/79b8ee73-95f6-ba4d-97d1-fd0806469d61%40gmail.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/CANsgjnu1NeCXY%2BySPtLMr3%3Dno_Txi3N43T0WT-
> ve4jWCzJfRew%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/CAKxcST_FaNcGa3Gw1VhkQH0Ma3vnnZ9vCSLkzaYMV72Z0pPzAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.