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.
