On Tue, Sep 13, 2016 at 8:18 AM, Josh Di Fabio <[email protected]> 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 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).
When creating API payloads that conform to HAL, JSON-LD, Atom, and
other formats, you will typically have one of two situations:
- A value object representing the resource, with a set of relational
links to represent.
- A set of relational links to represent *only*.
This latter is often useful for dashboards or meta-endpoints, as they
allow the consumer then to decide what relations are useful, and then
to follow those links to fetch more data.
We're not defining what these value objects look like; we are only
defining what a collection of links, and what those individual links
look like.
With regards to the "collection" interface, it is essentially only
present to aggregate the link relations *relevant to the resource they
relate to*.
> 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.
Indeed.
Thanks for the feedback; your suggestion for changes to the
LinkCollectionInterface may also address the concerns from Andreas;
I'll discuss with Larry later today.
> On Mon, Sep 12, 2016 at 11:52 PM Matthew Weier O'Phinney
> <[email protected]> wrote:
>>
>> On Sep 12, 2016 5:31 PM, "Daniel Hunsaker" <[email protected]> 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 [email protected].
>> To post to this group, send email to [email protected].
>> 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 [email protected].
> To post to this group, send email to [email protected].
> 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.
--
Matthew Weier O'Phinney
[email protected]
https://mwop.net/
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAJp_myWCmL3EuHtgpO4hgc49Vs0W%2BavkgMo58fnuLOodmR7E1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
