As there doesn't seem to be a clear consensus amongst those who have posted so far, Matthew and I decided to just put it to a poll.

This poll is open to everyone, but we are particularly looking for voting reps to give feedback. It should take less than 60 seconds to do, so please spare a minute to give feedback:


https://goo.gl/forms/fR0VcqhOfMO2mPQ12

I'll leave it open for a week or so (probably a little more since 1 week will be during DrupalCon) and we'll see where we stand before making a final decision.

--Larry Garfield

On 09/19/2016 01:08 AM, Marc Alexander wrote:
Hi,

I do not think that calling it "collector" does serve it right. A collector is something that collects and therefore creates a collection. I don't see this applying to the LinkCollectionInterface. A collection however is a group of object which do not necessarily need to be of the same type. I would recommend to stay with calling it a collection as that describes its purpose pretty well.

-- Marc

On Wednesday, September 14, 2016 at 7:21:01 PM UTC+2, Andreas Heigl wrote:

    Hi All

    Am Montag, 12. September 2016 23:22:12 UTC+2 schrieb Larry Garfield:

        On 09/12/2016 09:40 AM, Matthew Weier O'Phinney wrote:
        > On Mon, Sep 12, 2016 at 1:04 AM, Andreas Heigl
        <and...@heigl.org> wrote:
        >> I have two things I'd like to mention regarding PSR-13:
        >>
        >> First, for me personally it makes less sense to have a
        >> LinkCollectionInterface that doesn't act like I'D expect a
        Collection to
        >> work. For me a collection is a set of similar items I can
        then iterate over.
        >> Whether that's a collection of links, headers, or teapots
        doesn't matter. So
        >> 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. I know it's only a slight
        difference in wording,
        >> but for me it would make a difference in understanding what
        happens.
        > Thanks for this feedback! Until recently, I didn't typically
        think of
        > collections as requiring iteration, but considering that the
        > terminology has definitely been moving in that direction the
        last few
        > years (google for "first-class collection", and you'll see
        fairly
        > consistent definitions!), it may make sense to change the
        name. I'll
        > discuss with Larry today.

        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:

        class Whatever implements LinkCatalogInterface {

        }

        How do people feel about that?  Is it more/less descriptive than
        Collection?  More/less pompous sounding? :-)  A few seconds of
        Googling
        didn't find any existing CS definition of "catalog" that would
        conflict
        with it, FWIW.

        We went over the name before and Collection was the best we
        came up
        with.  So I think it's Collection or Catalog at the end of the
        day.


    I'm always trying to find analogies in the real word for things I
    want to name.

    For me a catalog is a set of things I am able to get from someone
    providing that catalog. It never contains actual concrete objects
    only references to them. The only thing they need to have in
    common is that they can be obtained from the same source. And I'm
    usually not ordering everything the catalog has to offer, just a
    small subset. Trying to match that to the Links I'm stumbling very
    soon.

    A Collection on the other hand is a set of concrete objects that
    someone has gathered. And they all have something in common. They
    are either stamps or teapots or beermats or whatever that someone
    has gathered. But they are all of the same kind. And the person
    gathering these items can without problem gather different items.
    Like a person can collect postcards as well as guitars. Ask that
    person to show you the postcard-collection (besides from being a
    happier person) they won't show you a single guitar.


    So taking that analogy to the links, it's possible to have an
    object containing links as well as headers. It's a Collector of
    links *and* headers. To know whether you can get links from the
    object you'll need a way to tell whether that object collects
    them. That could be a LinkCollectorInterface that defines a method
    *getLinkCollection*. Know when I have a concrete implementation of
    an Object I can check whether it's a LinkCollector and if so I
    know that I can ask for a LinkCollection. And that LinkCollection
    can be anything from a complex iterable LinkCollectionObject
    implementing a LinkCollectionInterface to an array of
    LinkInterface-implementing objects. The main think is that I get
    something back that contains LinkInterfaces.

    So I would opt for renaming the LinkCollectionInterface to
    LinkCollectorInterface and would refrain from calling it a Cataloge.

    But that's just my 0,02€

    Cheers

    Andreas


        --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 <mailto:php-fig+unsubscr...@googlegroups.com>. To post to this group, send email to php-fig@googlegroups.com <mailto:php-fig@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/9472b271-fbe9-439f-8a38-17023bd53aa2%40googlegroups.com <https://groups.google.com/d/msgid/php-fig/9472b271-fbe9-439f-8a38-17023bd53aa2%40googlegroups.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/875a9f23-e4cd-bce4-a404-30f3c570558d%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to