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 <
[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
> <https://groups.google.com/d/msgid/php-fig/CAJp_myUZ4XH6mG4pNnXfGKavnAhdxN6fMocVngpxmNT6TLi8yA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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.
