On 10/11/2016 02:21 PM, Larry Garfield wrote:
On 09/26/2016 12:57 AM, Andreas Heigl wrote:
Matthew and I discussed this a bit. LinksProviderInterface is the first
suggestion that for lack of a less emotionally-based term "clicks", and
doesn't become even more confusing. We're tempted to add that to the
poll and restart it. :-) (I saw you posted it there, too.) As you
note, though, EvolvableLinkProviderInterface would be a bit odd.
Thoughts from others?
Really, the core issue is that the object in question contains links,
and MAY allow you to add more to them, but ALSO contains other stuff
that isn't links. So it is a collection of links, but doesn't have the
exclusivity that "collection" has come to have. (Viz, it's not a fancy
OOP array of links.) That's really the problem; the name "collection"
would have likely been fine 3 years ago, but these days we expect more
of that word but have no word to replace its previous, more limited
meaning. :-/
For me the core issue is that - even though the object contains links
(is a LinkContainer so to say) - it also contains other things. And for
me a Collection implies that it contains *only* items of a certain kind.
So for me it's more that the object *contains a collection of links*.
And as such it provides access to links so a LinksProviderInterface
would work for me. I'd prefer a LinksCollectionProviderInterface but
that's getting a bit ridiculous :)
Especially when we come to the EvolvableLinksCollectionProviderInterface…
A LinksContainerInterface would be another option but hey…
My 0,02 €
Cheers
Andreas
Following up here...
The poll[1] ended with a very clear consensus against Catalog or
Collector. About 7 of the 11 respondants were fine with
LinkCollectionInterface. The other 4 all proposed still more new
nouns. :-) So Catalog and Collector are officially off the table.
As noted above, the only additional suggestion that resonated at all
was Provider, vis, [Evolvable]LinkProviderInterface. I'm still
lukewarm on it, but Matthew is increasingly of the mind that
Collection is going to cause confusion down the line.
Anyone else want to weigh in before we make a final call? If left
unanswered we'll probably end up with Provider, baring any further
feedback here.
--Larry Garfield
[1]
https://docs.google.com/forms/d/1EU_ETFgcDgFDJRbB8aoAwjYIYq8a-QwgwtxK0lWrsuE/edit#responses
Here's the set of PRs that will rename collection to provider:
https://github.com/php-fig/fig-standards/pull/822
(And linked from there for the code repos.)
If merged, that will reset the 2 week Review period, which is likely to
be the last of it and we'll then call the vote. Matthew, on you to merge.
Note: This is your last chance to bikeshed the name of this interface!
After we make a call here I will snarl in annoyance if anyone brings up
the name again. :-)
--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 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/69537d9a-c84e-8982-dcfa-410b0f2e4449%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
