Re: Resigning My Position ...

[Korvin Szanto]

Hi All,
First of all, I want to apologize to everyone for the content of this 
email. My hope is that it won't seemtoo  critical and instead will read how 
I intended.

Here's a list of my positions:

1. This thread is depressing
2. People on every side need to take a step back and chill
3. PSR-8 is great, I'm -1 on removing it and +1 on voting it in officially 
4. We as representatives should have the right to call a vote for anything 
what-so-ever as long as there is no bylaw prohibiting it regardless of 
discussion period.

A lot of people look to us for answers and depend on the things we produce, 
so our discussions are certainly very serious, but I think we should all 
take a second to examine who we are and what we are doing and perhaps 
realize:

1. Sometimes we're all wrong and sometimes we are all a little overzealous
2. A joke is a joke, we can have a joke it's not a big deal
3. We don't need the secretaries to hold our hands. They do not need to 
remind anyone of anything, I'd rather they focus on better things if that's 
an issue. (Super happy that they do remind us though)
4. We are all just people trying to do the best we can, lets all jump on 
the "benefit of the doubt" train instead of the demoralizing back and forth 
we continually have.

To all parties in all of these dramatic encounters, it takes two to tango. 
If someone is drumming up drama, reply in a reasonable way affording some 
benefit of the doubt and set the issue to rest. No need to get upset, no 
need for hostility, we're all people fighting our own battles trying to 
make this organization into the best organization it can be. I wouldn't say 
I know everyone here but I feel like over the past couple years I've come 
to know a lot of you personally, and I know that each and every one of you 
is better than throwing in anecdotal attacks and bringing up drama from the 
past to argue something as simple as "Should we have this april fools joke 
still".

Thanks for reading Love you all,
Korvin



On Monday, September 12, 2016 at 6:35:59 AM UTC-7, Jordi Boggiano wrote:
>
> As a person that has spent the last couple weeks looking at this thread 
> and others, feeling I should call Paul's BS many times, and not doing it 
> because frankly I don't have the energy and rather spend it on other 
> stuff, I can indeed confirm all this shit is driving people away. 
>
> Paul seems bent on destruction at this point, since as he put it "treat 
> me bad, I'll treat you worse" [1]. Yes people were fed up with you Paul 
> and tried to send you a sign. If all you take out of that is escalate it 
> to the next level then we might as well all pack our bags and go home, 
> save ourselves some trouble. Or maybe you pack yours and leave the rest 
> of us to do work here, and come back when you feel you can contribute 
> without pooping all over the playground. 
>
> Regardless, thanks Larry. *hug* 
>
> Best, 
> Jordi 
>
> P.S: I don't have Larry's patience, and I am sure this is more 
> inflammatory than necessary, but frankly I don't feel like I have to put 
> on silky gloves to respond to such behavior. 
>
> [1] https://twitter.com/pmjones/status/762097547334684672 
>
> On 12/09/2016 14:56, Larry Garfield wrote: 
> > Fellow FIG list members, we have been trolled. 
> > 
> > PSR-8 is a non-issue, non-entity, with no activity.  It was an April 
> > Fools joke cum running gag, in which Paul was an active participant as 
> > Sponsor.  Why did Paul bring it up right now? Of all times? And with an 
> > obviously baiting subject line?  It's not at all possible that it has 
> > something to with the Editor of PSR-8 being me, and Paul and I being the 
> > strongest voices on each side on FIG 3?  Even though Paul was until a 
> > few days ago the Sponsor for PSR-8, meaning he was "in on the joke" from 
> > the beginning? 
> > 
> > No, that couldn't possibly be the reason.  Not in the least. 
> > 
> > That there is no way to withdraw/abandon a PSR right now isn't even a 
> > question.  A simple look at the bylaws will tell you that, and Paul was 
> > at the meeting at ZendCon last year where we discussed that.  We even 
> > wrote up a proposed abandonment process in the same writeup that 
> > included the initial secretaries proposal.  You can find that here, 
> > towards the end: 
> > 
> > https://groups.google.com/forum/#!msg/php-fig/pxezV88Uk1I/eW3GvtPRCgAJ 
> > 
> > That never turned into a bylaw, so no, there's no current PSR 
> > abandonment process.  The Secretaries apparently looked at each other at 
> > some point and went "yep, there isn't."  This hardly requires a public 
> > vote; it's acknowledging what was already public knowledge, written up 
> > on the list, and discussed at the ZendCon meeting. 
> > 
> > FIG 3 included an abandonment process based on that discussion.  (I 
> > believe the time-frames are a bit different, but it's the same spirit.) 
> > While working on FIG 3, Michael and I noticed that the odds of PSR-8 
> > being able to field 

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

[Gary Hockin]

Paul,

I hope I speak for many when I say that your constant nitpicking is
becoming increasingly tiresome. I understand that you feel that the
secretaries are working outside of the boundaries of the tasks and duties
that they were voting in to fulfil. Other voting members on this list
disagree with you -- this is fine, discussion and disagreement is important
and is the cornerstone of how this group achieved the many standards that
are now in wide use in the industry. It's becoming frustrating to me to
continuously read in various mediums your questioning of the secretaries
roles, so might I suggest you propose an amendment to the bylaws that
clarifies the role of a secretary in a manner you think is correct, and
then open a discussion and then a vote on those amendments? This will allow
this matter to be finally put to rest and let the group move on to pastures
new.

Gary

On Tue, 13 Sep 2016 at 15:59 Chris Tankersley  wrote:

> On Tue, Sep 13, 2016 at 10:38 AM, Paul Jones  wrote:
>
>>
>> > On Sep 12, 2016, at 11:32, Pedro Cordeiro 
>> wrote:
>> >
>> > Paul, the role of a secretary is well described here, as I'm sure you
>> are aware: http://www.php-fig.org/bylaws/membership/#fig-secretary.
>>
>> Yes, it's *described* there, but nobody seems to be able to say what
>> *kind* of secretary is described. Based on the ZendCon meeting summary (the
>> meeting at which the idea for the role was first raised), it was originally
>> more "assistive" and "record-keeper" in nature:
>>
>> https://groups.google.com/d/msg/php-fig/pxezV88Uk1I/eW3GvtPRCgAJ
>>
>>
>> > ### New FIG Role: Secretary
>> >
>> > The secretary role would serve several functions:
>> >
>> > - Keeping the website up-to-date, including merging pull requests.
>> > - GitHub organization administration (assigning people to teams,
>> removing people
>> >   from teams, etc.). Specifically, this would involve providing editors
>> and
>> >   coordinators of proposals commit access prior to a proposal being
>> accepted or
>> >   rejected, and removing commit access once a proposal is complete
>> (unless a
>> >   member is also involved in other active proposals).
>> > - Tallying votes.
>> > - Tracking member project activity, and marking projects as inactive.
>> >
>> > The role will be filled by 3 people, to ensure that at least one person
>> is
>> > always available in a timely manner. Additionaly, to remove partiality,
>> the role
>> > would be restricted to:
>> >
>> > - non-voting members of FIG;
>> > - members not actively involved in a current proposal (i.e., you cannot
>> be an
>> >   editor of a proposal AND fulfill the role of secretary).
>> >
>> > Not discussed:
>> >
>> > - duration of service. (i.e., does service terminate after a fixed
>> duration?)
>> > - eligility (are secretaries proposed? or do they volunteer?)
>> > - election (is an entrance vote required?)
>> >
>> > Joe Ferguson, who was present, volunteered for the role of Secretary.
>>
>
> And that was used as a basis for the current form of the Secretary:
>
> http://www.php-fig.org/bylaws/membership/#fig-secretary
>
> The duties of the secretary are clearly laid out, regardless of "what
> type" of secretary they are. This was a vote that you participated in by a
> +0 vote.
>
>
>>
>> But referring to it now as "assistive" and or "record-keeping" role seems
>> to meet with resistance and defensiveness.
>>
>> Since the word "secretary" has multiple meanings, that makes the title
>> rather ambiguous. In the interest of reducing ambiguity, and making sure
>> the powers of the role fit an unambiguous title, I would love some
>> clarification on exactly what *kind* of secretary we have. Is it really the
>> "assistive/record-keeping" secretary, or is it more like something else? If
>> so, exactly what "something else" is it like?
>>
>> When asking this question to Michael Cullum over the weekend, in an
>> on-the-record conversation, he replied as follows (in his typical lengthy
>> fashion):
>>
>> > Secretary does not just mean assistant.
>> >
>> > The Secretary-General of the UN, or a Secretary of State are leadership
>> positions; a Parliamentary Secretary is a civil service position which runs
>> the day-to-day of a government department and is responsible to government,
>> but is politically impartial; a Parliamentary Private Secretary is an MP
>> (Member of Parliament, our congressmen) who works with a minister as a
>> liaison between the minister and backbenchers (MPs who are not part of the
>> government but are in the majority/government party); a Parliamentary Under
>> Secretary of State is subordinate to the Secretary of State but is an MP
>> with a smaller brief that they can focus on, reporting to their SoS; a
>> Secretary of a club or society is a mix of a leadership position (they are
>> a club officer and normally considered a very senior one, and the person
>> legally responsible for the actions of the club or 

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

[Chris Tankersley]

On Tue, Sep 13, 2016 at 10:38 AM, Paul Jones  wrote:

>
> > On Sep 12, 2016, at 11:32, Pedro Cordeiro  wrote:
> >
> > Paul, the role of a secretary is well described here, as I'm sure you
> are aware: http://www.php-fig.org/bylaws/membership/#fig-secretary.
>
> Yes, it's *described* there, but nobody seems to be able to say what
> *kind* of secretary is described. Based on the ZendCon meeting summary (the
> meeting at which the idea for the role was first raised), it was originally
> more "assistive" and "record-keeper" in nature:
>
> https://groups.google.com/d/msg/php-fig/pxezV88Uk1I/eW3GvtPRCgAJ
>
>
> > ### New FIG Role: Secretary
> >
> > The secretary role would serve several functions:
> >
> > - Keeping the website up-to-date, including merging pull requests.
> > - GitHub organization administration (assigning people to teams,
> removing people
> >   from teams, etc.). Specifically, this would involve providing editors
> and
> >   coordinators of proposals commit access prior to a proposal being
> accepted or
> >   rejected, and removing commit access once a proposal is complete
> (unless a
> >   member is also involved in other active proposals).
> > - Tallying votes.
> > - Tracking member project activity, and marking projects as inactive.
> >
> > The role will be filled by 3 people, to ensure that at least one person
> is
> > always available in a timely manner. Additionaly, to remove partiality,
> the role
> > would be restricted to:
> >
> > - non-voting members of FIG;
> > - members not actively involved in a current proposal (i.e., you cannot
> be an
> >   editor of a proposal AND fulfill the role of secretary).
> >
> > Not discussed:
> >
> > - duration of service. (i.e., does service terminate after a fixed
> duration?)
> > - eligility (are secretaries proposed? or do they volunteer?)
> > - election (is an entrance vote required?)
> >
> > Joe Ferguson, who was present, volunteered for the role of Secretary.
>

And that was used as a basis for the current form of the Secretary:

http://www.php-fig.org/bylaws/membership/#fig-secretary

The duties of the secretary are clearly laid out, regardless of "what type"
of secretary they are. This was a vote that you participated in by a +0
vote.


>
> But referring to it now as "assistive" and or "record-keeping" role seems
> to meet with resistance and defensiveness.
>
> Since the word "secretary" has multiple meanings, that makes the title
> rather ambiguous. In the interest of reducing ambiguity, and making sure
> the powers of the role fit an unambiguous title, I would love some
> clarification on exactly what *kind* of secretary we have. Is it really the
> "assistive/record-keeping" secretary, or is it more like something else? If
> so, exactly what "something else" is it like?
>
> When asking this question to Michael Cullum over the weekend, in an
> on-the-record conversation, he replied as follows (in his typical lengthy
> fashion):
>
> > Secretary does not just mean assistant.
> >
> > The Secretary-General of the UN, or a Secretary of State are leadership
> positions; a Parliamentary Secretary is a civil service position which runs
> the day-to-day of a government department and is responsible to government,
> but is politically impartial; a Parliamentary Private Secretary is an MP
> (Member of Parliament, our congressmen) who works with a minister as a
> liaison between the minister and backbenchers (MPs who are not part of the
> government but are in the majority/government party); a Parliamentary Under
> Secretary of State is subordinate to the Secretary of State but is an MP
> with a smaller brief that they can focus on, reporting to their SoS; a
> Secretary of a club or society is a mix of a leadership position (they are
> a club officer and normally considered a very senior one, and the person
> legally responsible for the actions of the club or society) but also
> administrative duties as you describe; and of course, the way you describe
> it, as a PA type role.
> >
> > The point I'm trying to make is that is is a simple fact that the title
> Secretary can mean a huge variety of things, some considerably more
> authoritative than that which the role of FIG Secretaries is, some are more
> solely administrative (I'd note the term 'Administrator' has very similar
> variance in meaning also). You seem to put a lot of value in the naming of
> the role; in fact, your last email indicates this is the *most important*
> thing to you. Might I ask why?
> >
> > So I do name the role, and I name it Secretary. If you wish to add other
> titles onto this such as Developer Advocate, PR *, Administrative *,
> Moderator, Administrator, Social Media *, with * indicating that manager or
> assistant could be used interchangeably, then you may if that makes you
> feel like you better understand the role. Just like the startup industry,
> where titles mean relatively little because they are a small number of
> people 

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

[Tom Etzel]

Paul keeps asking the same question over and over again. Why are you all so 
reluctant to just answer his question? Seriously... Just explicitly answer 
his question. The secretary is an "assistive/record-keeping" or the 
secretary is fill_in_the_blank. You want the guy to stop asking, but nobody 
will just flat out answer him. Instead you all post links to crap, or ask 
him to remember discussions from past events. It shouldn't matter if you 
think he is trolling or not. Just answer the question. Then he can choose 
to accept the answer or not. If he doesn't accept your CLEAR answer to the 
question, then that is on him. At least you can then point him to where you 
clearly answered his question instead of continually dodging the question 
and complaining about his continued asking.

I really don't understand the resistance to actually answering the 
question. It seems like there is something to hide, or something certain 
people don't want getting out on the list. 

"A secretary is what a secretary has always been." Is not a sufficient 
answer to the question IMO. That's like saying "An apple is an apple." When 
someone asks you what an apple is.

Not picking on you Gary, I just hit reply to the last post on the thread. I 
respect your suggestion that Paul should propose an amendment to the 
current bylaws, and I think he should totally do that IF he receives a 
clear answer to his question that does not jive with his thoughts on what 
type of secretary the FIG should have. 

On Tuesday, September 13, 2016 at 10:08:58 AM UTC-5, GeeH wrote:
>
> Paul,
>
> I hope I speak for many when I say that your constant nitpicking is 
> becoming increasingly tiresome. I understand that you feel that the 
> secretaries are working outside of the boundaries of the tasks and duties 
> that they were voting in to fulfil. Other voting members on this list 
> disagree with you -- this is fine, discussion and disagreement is important 
> and is the cornerstone of how this group achieved the many standards that 
> are now in wide use in the industry. It's becoming frustrating to me to 
> continuously read in various mediums your questioning of the secretaries 
> roles, so might I suggest you propose an amendment to the bylaws that 
> clarifies the role of a secretary in a manner you think is correct, and 
> then open a discussion and then a vote on those amendments? This will allow 
> this matter to be finally put to rest and let the group move on to pastures 
> new.
>
> Gary
>
> On Tue, 13 Sep 2016 at 15:59 Chris Tankersley  > wrote:
>
>> On Tue, Sep 13, 2016 at 10:38 AM, Paul Jones > > wrote:
>>
>>>
>>> > On Sep 12, 2016, at 11:32, Pedro Cordeiro >> > wrote:
>>> >
>>> > Paul, the role of a secretary is well described here, as I'm sure you 
>>> are aware: http://www.php-fig.org/bylaws/membership/#fig-secretary.
>>>
>>> Yes, it's *described* there, but nobody seems to be able to say what 
>>> *kind* of secretary is described. Based on the ZendCon meeting summary (the 
>>> meeting at which the idea for the role was first raised), it was originally 
>>> more "assistive" and "record-keeper" in nature:
>>>
>>> https://groups.google.com/d/msg/php-fig/pxezV88Uk1I/eW3GvtPRCgAJ
>>>
>>>
>>> > ### New FIG Role: Secretary
>>> >
>>> > The secretary role would serve several functions:
>>> >
>>> > - Keeping the website up-to-date, including merging pull requests.
>>> > - GitHub organization administration (assigning people to teams, 
>>> removing people
>>> >   from teams, etc.). Specifically, this would involve providing 
>>> editors and
>>> >   coordinators of proposals commit access prior to a proposal being 
>>> accepted or
>>> >   rejected, and removing commit access once a proposal is complete 
>>> (unless a
>>> >   member is also involved in other active proposals).
>>> > - Tallying votes.
>>> > - Tracking member project activity, and marking projects as inactive.
>>> >
>>> > The role will be filled by 3 people, to ensure that at least one 
>>> person is
>>> > always available in a timely manner. Additionaly, to remove 
>>> partiality, the role
>>> > would be restricted to:
>>> >
>>> > - non-voting members of FIG;
>>> > - members not actively involved in a current proposal (i.e., you 
>>> cannot be an
>>> >   editor of a proposal AND fulfill the role of secretary).
>>> >
>>> > Not discussed:
>>> >
>>> > - duration of service. (i.e., does service terminate after a fixed 
>>> duration?)
>>> > - eligility (are secretaries proposed? or do they volunteer?)
>>> > - election (is an entrance vote required?)
>>> >
>>> > Joe Ferguson, who was present, volunteered for the role of Secretary.
>>>
>>
>> And that was used as a basis for the current form of the Secretary:
>>
>> http://www.php-fig.org/bylaws/membership/#fig-secretary
>>
>> The duties of the secretary are clearly laid out, regardless of "what 
>> type" of secretary they are. This was a vote that you participated in 

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

[Peter Huynh]

A secretary is ... what defined in: 
http://www.php-fig.org/bylaws/membership/#fig-secretary.

Asking again and again and again will not solve anything. Each person's 
point of view of the bylaw is subjective. It's not a matter of beating 
around the bush, it's a matter of giving a "correct subjective answer" to 
the question to Paul.

If Paul feels the bylaw are not up to scratch and there are areas that he 
can improve/contribute to, then why not doing the thing FIG has been doing 
since its inception, putting in a PR and request a vote?

All the answers has already been laid bare. Nothing more will be gained 
from asking the same question again.

My 2c.

-- 
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/c3940a5a-d648-48cb-9d72-768b8902fb10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

[Paul Jones]

> On Sep 12, 2016, at 11:32, Pedro Cordeiro  wrote:
> 
> Paul, the role of a secretary is well described here, as I'm sure you are 
> aware: http://www.php-fig.org/bylaws/membership/#fig-secretary.

Yes, it's *described* there, but nobody seems to be able to say what *kind* of 
secretary is described. Based on the ZendCon meeting summary (the meeting at 
which the idea for the role was first raised), it was originally more 
"assistive" and "record-keeper" in nature:

https://groups.google.com/d/msg/php-fig/pxezV88Uk1I/eW3GvtPRCgAJ


> ### New FIG Role: Secretary
> 
> The secretary role would serve several functions:
> 
> - Keeping the website up-to-date, including merging pull requests.
> - GitHub organization administration (assigning people to teams, removing 
> people
>   from teams, etc.). Specifically, this would involve providing editors and
>   coordinators of proposals commit access prior to a proposal being accepted 
> or
>   rejected, and removing commit access once a proposal is complete (unless a
>   member is also involved in other active proposals).
> - Tallying votes.
> - Tracking member project activity, and marking projects as inactive.
> 
> The role will be filled by 3 people, to ensure that at least one person is
> always available in a timely manner. Additionaly, to remove partiality, the 
> role
> would be restricted to:
> 
> - non-voting members of FIG;
> - members not actively involved in a current proposal (i.e., you cannot be an
>   editor of a proposal AND fulfill the role of secretary).
> 
> Not discussed:
> 
> - duration of service. (i.e., does service terminate after a fixed duration?)
> - eligility (are secretaries proposed? or do they volunteer?)
> - election (is an entrance vote required?)
> 
> Joe Ferguson, who was present, volunteered for the role of Secretary.

But referring to it now as "assistive" and or "record-keeping" role seems to 
meet with resistance and defensiveness.

Since the word "secretary" has multiple meanings, that makes the title rather 
ambiguous. In the interest of reducing ambiguity, and making sure the powers of 
the role fit an unambiguous title, I would love some clarification on exactly 
what *kind* of secretary we have. Is it really the "assistive/record-keeping" 
secretary, or is it more like something else? If so, exactly what "something 
else" is it like?

When asking this question to Michael Cullum over the weekend, in an 
on-the-record conversation, he replied as follows (in his typical lengthy 
fashion):

> Secretary does not just mean assistant.
> 
> The Secretary-General of the UN, or a Secretary of State are leadership 
> positions; a Parliamentary Secretary is a civil service position which runs 
> the day-to-day of a government department and is responsible to government, 
> but is politically impartial; a Parliamentary Private Secretary is an MP 
> (Member of Parliament, our congressmen) who works with a minister as a 
> liaison between the minister and backbenchers (MPs who are not part of the 
> government but are in the majority/government party); a Parliamentary Under 
> Secretary of State is subordinate to the Secretary of State but is an MP with 
> a smaller brief that they can focus on, reporting to their SoS; a Secretary 
> of a club or society is a mix of a leadership position (they are a club 
> officer and normally considered a very senior one, and the person legally 
> responsible for the actions of the club or society) but also administrative 
> duties as you describe; and of course, the way you describe it, as a PA type 
> role.
> 
> The point I'm trying to make is that is is a simple fact that the title 
> Secretary can mean a huge variety of things, some considerably more 
> authoritative than that which the role of FIG Secretaries is, some are more 
> solely administrative (I'd note the term 'Administrator' has very similar 
> variance in meaning also). You seem to put a lot of value in the naming of 
> the role; in fact, your last email indicates this is the *most important* 
> thing to you. Might I ask why?
> 
> So I do name the role, and I name it Secretary. If you wish to add other 
> titles onto this such as Developer Advocate, PR *, Administrative *, 
> Moderator, Administrator, Social Media *, with * indicating that manager or 
> assistant could be used interchangeably, then you may if that makes you feel 
> like you better understand the role. Just like the startup industry, where 
> titles mean relatively little because they are a small number of people 
> filling a large number of roles, so everyone in the company calls themselves 
> a 'Director of XYZ', the same is applicable here. It is not the title that is 
> necessarily important, but the actions, role and responsibilities.
> 
> https://en.wikipedia.org/wiki/United_States_Secretary_of_State
> https://en.wikipedia.org/wiki/Secretary_of_State_(United_Kingdom)
> https://en.wikipedia.org/wiki/Permanent_Secretary
> 

Re: [REVIEW] PSR-13: Link definition interfaces

[Larry Garfield]

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:


$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.


--Larry Garfield

On 09/13/2016 08:18 AM, Josh Di Fabio wrote:

Quoting the meta doc.

> Why is a LinkCollectionInterface needed?
> In many contexts, a set of links will be attached to some other object. Those objects may be 
used in situations where all that is relevant is their links, or some 
subset of their links. For example, various different value objects 
may be defined that represent different REST formats such as HAL, 
JSON-LD, or Atom.


In my opinion, "some other object" should not be defined by this spec. 
What use is an interface for an object which simply "has a collection 
of links"? What if that object has multiple accessors for different 
kinds of links? I don't see any value in this spec attempting to 
define what such objects should look like, so I'd be interested to see 
a concrete example of why it is useful (apologies if I missed this in 
the meta doc).


I would propose either removing the collection interface or making it 
a true and useful collection object instead of what we have now. 
Here's a suggestion:


interface LinkCollectionInterface extends \IteratorAggregate
{
public function getIterator(): Iterator;

public function filterByRel($rel): LinkCollectionInterface;
}

It would seem better to then replace these interfaces with concrete 
implementations, since they are clearly fairly simple value objects, 
but from what I can remember it's in your bylaws only to define 
interfaces.


On Mon, Sep 12, 2016 at 11:52 PM Matthew Weier O'Phinney 
> wrote:


On Sep 12, 2016 5:31 PM, "Daniel Hunsaker" > wrote:
>>
>> >> 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.
>>
>>
>> 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:
>
>
> Not against Catalog, personally.  However, Andreas did mention
Collector as an alternate; is that one of the more-hated
designators that were considered?  That wasn't clear from the
above paragraph...

I was hesitant about it, as it implies that the instance is
collecting instances for purposes of returning a collection, which
brings us back to the original naming issue.



--
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/1f87a36c-35e2-5129-88a7-a5193dc2c27b%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-13: Link definition interfaces

[Matthew Weier O'Phinney]

On Tue, Sep 13, 2016 at 8:18 AM, Josh Di Fabio  wrote:
> Quoting the meta doc.
>
>> Why is a LinkCollectionInterface needed?
>> In many contexts, a set of links will be attached to some other object.
>> Those objects may be used in situations where all that is relevant is their
>> links, or some subset of their links. For example, various different value
>> objects may be defined that represent different REST formats such as HAL,
>> JSON-LD, or Atom.
>
> In my opinion, "some other object" should not be defined by this spec. What
> use is an interface for an object which simply "has a collection of links"?
> What if that object has multiple accessors for different kinds of links? I
> don't see any value in this spec attempting to define what such objects
> should look like, so I'd be interested to see a concrete example of why it
> is useful (apologies if I missed this in the meta doc).

When creating API payloads that conform to HAL, JSON-LD, Atom, and
other formats, you will typically have one of two situations:

- A value object representing the resource, with a set of relational
links to represent.
- A set of relational links to represent *only*.

This latter is often useful for dashboards or meta-endpoints, as they
allow the consumer then to decide what relations are useful, and then
to follow those links to fetch more data.

We're not defining what these value objects look like; we are only
defining what a collection of links, and what those individual links
look like.

With regards to the "collection" interface, it is essentially only
present to aggregate the link relations *relevant to the resource they
relate to*.

> I would propose either removing the collection interface or making it a true
> and useful collection object instead of what we have now. Here's a
> suggestion:
>
> interface LinkCollectionInterface extends \IteratorAggregate
> {
> public function getIterator(): Iterator;
>
> public function filterByRel($rel): LinkCollectionInterface;
> }
>
> It would seem better to then replace these interfaces with concrete
> implementations, since they are clearly fairly simple value objects, but
> from what I can remember it's in your bylaws only to define interfaces.

Indeed.

Thanks for the feedback; your suggestion for changes to the
LinkCollectionInterface may also address the concerns from Andreas;
I'll discuss with Larry later today.


> On Mon, Sep 12, 2016 at 11:52 PM Matthew Weier O'Phinney
>  wrote:
>>
>> On Sep 12, 2016 5:31 PM, "Daniel Hunsaker"  wrote:
>> >>
>> >> >> 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.
>> >>
>> >>
>> >> 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:
>> >
>> >
>> > Not against Catalog, personally.  However, Andreas did mention Collector
>> > as an alternate; is that one of the more-hated designators that were
>> > considered?  That wasn't clear from the above paragraph...
>>
>> I was hesitant about it, as it implies that the instance is collecting
>> instances for purposes of returning a collection, which brings us back to
>> the original naming issue.
>>
>>
>> --
>> 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/CAJp_myUZ4XH6mG4pNnXfGKavnAhdxN6fMocVngpxmNT6TLi8yA%40mail.gmail.com.
>> 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/CAKiSzdCW4WjxP9RrOKD4yXsj%2B0FAbH_xQOTjdGE%2BiBDU0N0iEQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/

-- 
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 

Re: [REVIEW] PSR-13: Link definition interfaces

[Josh Di Fabio]

Quoting the meta doc.

> Why is a LinkCollectionInterface needed?
> In many contexts, a set of links will be attached to some other object.
Those objects may be used in situations where all that is relevant is their
links, or some subset of their links. For example, various different value
objects may be defined that represent different REST formats such as HAL,
JSON-LD, or Atom.

In my opinion, "some other object" should not be defined by this spec. What
use is an interface for an object which simply "has a collection of links"?
What if that object has multiple accessors for different kinds of links? I
don't see any value in this spec attempting to define what such objects
should look like, so I'd be interested to see a concrete example of why it
is useful (apologies if I missed this in the meta doc).

I would propose either removing the collection interface or making it a
true and useful collection object instead of what we have now. Here's a
suggestion:

interface LinkCollectionInterface extends \IteratorAggregate
{
public function getIterator(): Iterator;

public function filterByRel($rel): LinkCollectionInterface;
}

It would seem better to then replace these interfaces with concrete
implementations, since they are clearly fairly simple value objects, but
from what I can remember it's in your bylaws only to define interfaces.

On Mon, Sep 12, 2016 at 11:52 PM Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> On Sep 12, 2016 5:31 PM, "Daniel Hunsaker"  wrote:
> >>
> >> >> 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.
> >>
> >>
> >> 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:
> >
> >
> > Not against Catalog, personally.  However, Andreas did mention Collector
> as an alternate; is that one of the more-hated designators that were
> considered?  That wasn't clear from the above paragraph...
>
> I was hesitant about it, as it implies that the instance is collecting
> instances for purposes of returning a collection, which brings us back to
> the original naming issue.
>
>
> --
> 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/CAJp_myUZ4XH6mG4pNnXfGKavnAhdxN6fMocVngpxmNT6TLi8yA%40mail.gmail.com
> 
> .
> 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/CAKiSzdCW4WjxP9RrOKD4yXsj%2B0FAbH_xQOTjdGE%2BiBDU0N0iEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.