On Tue, Sep 13, 2016 at 2:50 PM Larry Garfield <la...@garfieldtech.com>
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:
>
>
Thanks for taking the time to reply.
> $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.
> // ...
> // LinkableResponse is an implementation of PSR-7 ResponseInterface and
> LinkCollectionInterface
> $r = new LinkableResponse(200);
>
> // Whatever app-sensitive rendering logic applies, not our problem.
> $r = $r->withBody(new StringStream(render($article));
>
> // The links on article are generated on the fly here,
> // based off of the underlying data of article, whatever that is.
> foreach ($article->getLinks() as $link) {
> $r = $r->withLink($link);
> }
>
> Forcing both Article and Response to be traversable on links is a no-go,
> as they may have other data sets in them that would make just as much sense
> to iterate. But it makes total sense for Article to be able to provide
> links (read only) and Response to both accept them and be able to return
> them (or turn them into HTTP headers directly, or whatever else someone
> feels like doing). Neither Response nor Article are PSR-13-specific
> concretions.
>
I don't think I've made myself clear. My contention is that
LinkableResponse is not *a collection of links*, rather, it *has* a
collection of links. It should not implement LinkCollectionInterface at
all. Does this make sense? I fully appreciate that you and Matthew are
smart guys who understand that interfaces are analogous to *is a* and not
*has a* semantics, but I feel that this spec is currently overcomplicating
things a bit.
My suggestion would be that LinkableResponse does not itself implement any
interface from this spec, since this spec doesn't attempt to define
response objects. Nor does it attempt to define (HTTP) resource objects or
objects from any other domain. Consider, for example, a domain object with
different types of links; this object might provide methods such as
*getPublicLinks*, *getPrivateLinks*, *getJsonHalLinks* , etc. Or consider a
case where links are loaded from a repository or some other kind of service
object, where there is no domain object which those links are attached to.
You can't create an interface which fits all of these different use cases.
Instead, LinkableResponse, and other objects which are outside the scope of
this spec, can *provide* a collection of links using whatever accessor or
property makes sense to them.
For example:
class LinkableResponse
{
public function getLinks(): LinkCollectionInterface { }
}
interface LinkCollectionInterface implements \IteratorAggregate
{
public function getIterator(): Iterator
public function filterByRel($rel): LinkCollectionInterface;
public function merge(LinkCollectionInterface
$collection): LinkCollectionInterface;
public function withLink(LinkInterface $link): LinkCollectionInterface
}
--Larry Garfield
>
>
> On 09/13/2016 08: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 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 <
> mweierophin...@gmail.com> wrote:
>
>> On Sep 12, 2016 5:31 PM, "Daniel Hunsaker" <danhunsa...@gmail.com> 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 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/1f87a36c-35e2-5129-88a7-a5193dc2c27b%40garfieldtech.com
> <https://groups.google.com/d/msgid/php-fig/1f87a36c-35e2-5129-88a7-a5193dc2c27b%40garfieldtech.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 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/CAKiSzdBnG%2BvUWRT-DSiq3MED_HkcpDt%2B0qkCzQcoS%2BbL6Navkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
