On 10/13/2016 07:09 PM, Larry Garfield wrote:
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

The MRs in question have been merged, and the spec updated.

This change necessitates resetting the review period, so technically it's pushed back to me as editor, I merged the changes above, and now hand it back to MWOP. Baring no other issues the vote for PSR-13 may start as early as 31 October. (Which would be the absolute perfect time to start the vote for PSR-13!)

--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/1a53f50e-d410-4c00-e195-cccc51c0f14c%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to