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

2016-11-01 Thread Niklas Keller
I guess I'm too late. Is there any reason to use the abbreviated `getRels()` and `withRel()`, but the long form for attributes (`getAttributes()`)? Feels inconsistent. I'd prefer `getRelation()` as well. Regards, Niklas On Monday, August 15, 2016 at 7:22:20 PM UTC+2, Matthew Weier O'Phinney

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

2016-09-25 Thread 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

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

2016-09-23 Thread Chuck Burgess
I suppose "container" is too loaded a term... as is "sixpack" :-D I'm cool with collection, as a "collection of collections" is no more odd to me than an array of arrays. CRB On Sep 21, 2016 17:19, "Larry Garfield" wrote: > As there doesn't seem to be a clear consensus

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

2016-09-22 Thread 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 LinkCollectionInterface describes two methods which, as per docblocks, "return a collection". So we have something called collection which in turn returns collections; not ideal.

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

2016-09-21 Thread Stefano Torresi
As far as I can tell, the problem is that currently the so called LinkCollectionInterface describes two methods which, as per docblocks, "return a collection". So we have something called collection which in turn returns collections; not ideal. Calling it "Catalog" doesn't cut it, in my opinion,

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

2016-09-14 Thread Andreas Heigl
Hi All Am Montag, 12. September 2016 23:22:12 UTC+2 schrieb Larry Garfield: > > On 09/12/2016 09:40 AM, Matthew Weier O'Phinney wrote: > > On Mon, Sep 12, 2016 at 1:04 AM, Andreas Heigl > wrote: > >> I have two things I'd like to mention regarding PSR-13: > >> > >> First,

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

2016-09-14 Thread 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

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

2016-09-14 Thread Larry Garfield
On 09/13/2016 09:28 AM, Josh Di Fabio wrote: On Tue, Sep 13, 2016 at 2:50 PM Larry Garfield > 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:

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

2016-09-13 Thread Matthew Weier O'Phinney
On Tue, Sep 13, 2016 at 8:18 AM, Josh Di Fabio wrote: > 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

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

2016-09-13 Thread Larry Garfield
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: $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.

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

2016-09-13 Thread 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

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

2016-09-12 Thread Matthew Weier O'Phinney
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

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

2016-09-12 Thread Larry Garfield
On 09/12/2016 09:40 AM, Matthew Weier O'Phinney wrote: On Mon, Sep 12, 2016 at 1:04 AM, Andreas Heigl wrote: I have two things I'd like to mention regarding PSR-13: First, for me personally it makes less sense to have a LinkCollectionInterface that doesn't act like I'D

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

2016-09-12 Thread Matthew Weier O'Phinney
On Mon, Sep 12, 2016 at 1:04 AM, Andreas Heigl wrote: > I have two things I'd like to mention regarding PSR-13: > > First, for me personally it makes less sense to have a > LinkCollectionInterface that doesn't act like I'D expect a Collection to > work. For me a collection is a

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

2016-09-12 Thread Andreas Heigl
I have two things I'd like to mention regarding PSR-13: First, for me personally it makes less sense to have a LinkCollectionInterface that doesn't act like I'D expect a Collection to work. For me a collection is a set of similar items I can then iterate over. Whether that's a collection of

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

2016-09-05 Thread Lukas Smith
Top posting because I will not touch on every point but do want to make the context available if desired. I found Paul's statement about doing it as an interop project valid, though instead of "should" I would have used "could" or "might benefit". At the end of the day we indeed can do

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

2016-09-05 Thread Paul Jones
Hi all, > On Sep 4, 2016, at 10:57, Michael Cullum wrote: > > As a general secretarial note, the minimum 2 week review period is now > complete as of the 30th August and this can be put to a vote at any time from > this point onwards. As a general

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

2016-09-04 Thread Michael Cullum
As a general secretarial note, the minimum 2 week review period is now complete as of the 30th August and this can be put to a vote at any time from this point onwards. -- Michael C On 1 September 2016 at 22:47, Larry Garfield wrote: > On 09/01/2016 02:34 PM, Woody Gilk

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

2016-09-01 Thread Larry Garfield
On 09/01/2016 02:34 PM, Woody Gilk wrote: On Thu, Sep 1, 2016 at 2:14 PM, Larry Garfield > wrote: It being under the FIG name in no way prevents or discourages anyone from "trying it out" if they wish, and the Review period

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

2016-09-01 Thread Larry Garfield
On 09/01/2016 01:50 PM, Paul Jones wrote: All, On consideration, this strikes me as a perfect example of something that should be created as a *-interop project prior to being accepted. That will help "shake out" any problems revealed by real-world use, especially use by people not

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

2016-09-01 Thread Paul Jones
All, On consideration, this strikes me as a perfect example of something that should be created as a *-interop project prior to being accepted. That will help "shake out" any problems revealed by real-world use, especially use by people not participating in the creation of the PSR. -- Paul

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

2016-08-15 Thread Paul Jones
> On Aug 15, 2016, at 13:34, Matthew Weier O'Phinney > wrote: > > On Mon, Aug 15, 2016 at 12:27 PM, Paul Jones wrote: >> >>> On Aug 15, 2016, at 12:22, Matthew Weier O'Phinney >>> wrote: >>> >>> Please take some time

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

2016-08-15 Thread Matthew Weier O'Phinney
On Mon, Aug 15, 2016 at 12:27 PM, Paul Jones wrote: > >> On Aug 15, 2016, at 12:22, Matthew Weier O'Phinney >> wrote: >> >> Please take some time to review the proposed standard. > > Are any member projects currently doing anything that resembles