On 09/13/2016 09:28 AM, Josh Di Fabio wrote:
On Tue, Sep 13, 2016 at 2:50 PM Larry Garfield <[email protected]
<mailto:[email protected]>> 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.
It sounds like this is another case of naming things (one of the 2 hard
problems in CS). There's a proposal on the table to change it to "Catalog":
https://groups.google.com/d/msg/php-fig/D-qAsZ5_f0s/PrKQL7RzAgAJ
Thoughts there? (As in, over in that thread.)
The problem with excluding the the ThisObjectHasLinksOnItInterface
(whatever it's named) is that it's then impossible to reliably do the
transfer I mentioned earlier. In a multi-stage DDD system (Drupal, or
some ADR-esque systems) there could be multiple levels of object
transformation in which you want to carry the links along. Eg, in the
example above, you'd wrap the foreach ($article->links ...) in an
interface check; that way you can pass any object to a function
containing that code and it will transfer links if possible. That's
only doable if you have a ThisObjectHasLinksOnItInterface, which is why
we included it.
getLinks() returns an iterable (array|Traversable, technically), so you
could filter that however you want; you could even build it with a
generator if you were so inclined.
--Larry Garfield
--
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/0e9c9b93-880b-a705-69d4-bd7746eddf94%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
