Re: Separate repository on GitHub for discussions, voting, politics?

[Stefano Torresi]

Daniel,

Il giorno mer 12 ago 2020 alle ore 08:22 daniel...@gmail.com <
daniel.pla...@gmail.com> ha scritto:

> Some of PHP-FIG members are always silent, they just sit here for status.
> "Hey, I'm doing right things at least every day, look, I'm in PHP-FIG
> group".
>

This is exactly how NOT to treat people, which you should care about a
little more than the tools they use.

The FIG activity is very low volume nowadays and doesn't need much more
than a mailing list.
MLs, by the way, are still very much in use for open-source projects, like,
exempli gratia, PHP itself, or, just to mention one, the Linux kernel.
Discussions about specific FIG projects or things that need direct
references to code happen on GitHub already.

Regards,
Stefano

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAFojS1ujT4gtLR_AfjreOWTt%3DEp-NVsuqprqsZnvMDGtbTOsJQ%40mail.gmail.com.

Re: [VOTE][CC][BYLAW] PSR evolution

[Stefano Torresi]

+1

Great work!

Il giorno lunedì 11 novembre 2019 10:48:24 UTC+1, Alessandro Lai ha scritto:
>
> Hello everyone,
> after a long review phase of my PR and multiple fixes and amendments, I 
> think it's now ready: 
>
> https://github.com/php-fig/fig-standards/pull/1195
>
> The PR adds a new document that addresses the issue of upgrading the code 
> of a PSR to leverage new language features. I started working on this draft 
> after a long discussion here on the ML (
> https://groups.google.com/d/topic/php-fig/OyC3plRYhqg/discussion), after 
> that the issue surfaced many times on our communication channels. 
>
> The PR has been reviewed by multiple parties, and I consider it now ready 
> to be put to a vote. So I hereby call a bylaw vote, following our Voting 
> Protocol: 
>
> https://www.php-fig.org/bylaws/voting-protocol/
>
> THIS THREAD IS FOR VOTES OF THE CORE COMMITTEE ONLY; there will be another 
> thread for Project Representative; any other message or "vote" will be 
> ignored. As always, you can vote with a +1, +0 or -1, you will have a 
> period of two weeks to cast your vote, so this will be closed after 
> 23:59:59 UTC of Monday 25th.
>
> There is a 50% quorum for this vote, and a 2/3 majority is required for it 
> to pass.
>
> Thank you.
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b5edc529-33f6-4d96-b6c7-6172c716e33f%40googlegroups.com.

Re: [BYLAW] Proposal: let PSRs evolve with the language

[Stefano Torresi]

Hey Ale,

Can we push this forward somehow?
>

My proposal didn't receive much feedback tbh, but nobody proposed
alternatives.


I have one doubt: using this namespace strategy, it seems to me that a
>> consumer of the spec can only require one revision at a time, is that
>> correct (and desired)?
>>
>
Nope, that's quite the opposite: having the revision in the namespace *and*
in the package name means multiple revisions can be imported in the same
codebase, which solves the main problem of being able to provide migration
paths to BC breaks.
This is actually the main point that should justify the clunkiness of the
proposal.

I would invite all the people in the group to provide feedback, expecially
negative, so that we can asses if there is ground to start editing a new
bylaw and finally get things moving.

Cheers!
Stefano

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAFojS1ui6M7EZH5hnTh64enmRhX-HxPd7bw5-DELTxa_7R2xaQ%40mail.gmail.com.

Re: [BYLAW] Proposal: let PSRs evolve with the language

[Stefano Torresi]

Hey list,

First of all, thanks Alessandro for bringing this up.
I have given a lot of thought on this topic, which, as most of you will
know, has been recurring pretty much since PHP7 was released.
I never actually sat down and write these thoughts of mine, though, so I
better do it now, finally.

While I agree that something *must* be done to ease the process of keeping
PSRs up to date, I think the suggested approach is too simplistic and would
introduce more problems than it solves.

There are multiple facets to this issue, here are some we need to solve to
fully address it:
- The common Git workflow of opening a PR doesn't really fit a project that
is meant be immutable once released, bar minor erratas that can't
effectively harm users.
- The specification documents are separate from the actual code, if any; I
think this is exactly why simply opening a PR, voting it, and merging may
seem easy, but it's actually not. If we update the interfaces and release a
new version of the Composer package, we also need to update the specs, and
vice-versa. While updating the package is a simple as bumping a tag,
updating the specification documents has no actual release process instead,
because a new PSR is supposed to be created instead. We can't simply make
the old specification documents disappear by merging a PR. Also, superseded
major versions should still be accessible for future reference.
- All specs are all in the same repository, so their lifecycle cannot be
managed independently.
- The namespace of the code we produce (Psr\Foo\Bar and Fig\Bar\Baz) is
fragmented, ambiguous and wouldn't accommodate multiple major version of
the same PSR living in the same codebase. This makes effectively impossible
to provide soft migration paths from one version to another, which would
probably end up in a Python 3 scenario, where not enough people will
migrate to the new ones to simply declare the old one DEAD, thus incurring
in the risk of very long and painful transition timeframes where multiple
incompatible standards are used in the wild.

Now, at the cost of sounding preposterous, I will propose the following:
*I think we need to completely overhaul **our naming conventions, **the PSR
release process (just the release, not the production workflow!), and how
we use VCS to manage the documents and sources we produce. This involves a
lot of changes and the willingness to turn page quite drastically.*

Here comes some craziness, but bear with me.

We could overhaul the naming scheme by introducing the concept of Revisions:

Standard name: PSR-$n - $topic [ - Revision $major.$minor.$patch]
Package name: fig/psr-$n-$topic[-rev-$major]:$major.$minor.$path
Namespace: Fig\Psr$n[\Rev$major]\
URI: php-fig.org/psr/psr-$n-$topic[-rev-$major]

Example 1:
PSR-7 - HTTP Messages - Revision 1.0.0
Package name: fig/psr-7-http-messages:1.0.0
Namespace: Fig\Psr7\
URI: php-fig.org/psr/psr-7-http-messages

Example 2:
PSR-7 -  HTTP Messages - Revision 2.0.0
Package name: fig/psr-7-http-messages-rev-2:2.0.0
Namespace: Fig\Psr7\Rev2\
URI: php-fig.org/psr/psr-7-http-messages-rev-2

Example 3:
PSR-7 -  HTTP Messages - Revision 2.0.1
Package name: fig/psr-7-http-messages-rev-2:2.0.1
Namespace: Fig\Psr7\Rev2\
URI: php-fig.org/psr/psr-7-http-messages-rev-2

Note that:
- The Revision number matches the Semver package version, but it's doesn't
map exactly to the same concept. The most relevant part is obviously the
major number because minor and patch should not break compatibility, thus
releasing a new Revision will not be required.
- If the Revision is omitted, it means it's 1.x, thus referring just to
"PSR-7" implies version 1.x.
- The $n is still determined at PSR entrance, but it is *never* changed
unless the PSR purpose changes substantially, enough to grant a scenario
where two standards may coexist and both be current (e.g. "PSR-6 - Caching
Interface" and "PSR-16 - Simple Cache").
- Deprecated minor and patch versions are not accessible other than via
Composer.
- The Composer package should contain both the specification documents AND
the sources, if any.
- For simplicity, $topic refers to both a text representation and a
slugified one.

In hindsight, I think the IETF naming convention has *heavy* negative
trade-offs. Some will argue that it's a good naming scheme, but I think we
can agree that trying to remember what RFC is about what is a waste of
neurons. We have had it easy because we only had to deprecate one standard,
PSR-2, but, believe it or not, I have seen people still getting confused
about this, because someone would refer to a spec as "the autoloader PSR",
to only later mention the actual version, leading to undesirable "gotchas".
Considering that if we had to keep the pace with the engine development
cycle, in the worst case we would need to release a new version every two
years, simply using natural numbers to identify standards would quickly
become a mess. Also, we can't make it match with Semver major versions, and
this 

Re: [VOTE] Core Committee Election

[Stefano Torresi]

1. Matteo Beccati
2. Matthew Weier O'Phinney
3. Larry Garfield
4. Woody Gilk
5. Benni Mack
6. Adam Englander
7. Beau Simensen

Ciau!

-- 
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/CAFojS1uAPEBOkQ2wVO_5%3DjH9aMEh-BOsVcHXkWHX1cs%3DEzK03g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

PHPDay FIG Meeting recap

[Stefano Torresi]

Hello list,

As usual, we've had a very productive meeting at PHPDay in Verona, which
this year has been bumped from the unconf to an actual pre-scheduled slot,
since we would have done it anyway.

These are the points of discussion:

- Open up the Slack channel to increase community involvement.
- Move the CoC proposal forward.
- Write a PSR on PSRs documents structure and format.
- Establish an opened, monthly, video meeting, to report and coordinate
group activities, instead of just using the conferences occasionally as we
did so far.
- Evaluate the possibility to define a different workflow for living
projects like coding standard and security PSRs.

I will try to follow up on each point shortly and possibly initiate
separate discussions here in the ML, where applicable.

Cheers!

Stefano

-- 
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/CAFojS1umR7vLx9x1W3Y94Tm9q%2B8f4qtaV9qOu_DHQHV9nQy%2Biw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ACCEPTANCE VOTE][CC] PSR-14 Event Dispatcher

[Stefano Torresi]

+0

On Sun, Mar 10, 2019 at 7:31 PM Cees-Jan Kiewiet  wrote:
> >
> > The REVIEW period for the proposed PSR-14, Event Dispatcher, hit its
> minimum required length on 27 February 2019. We continued the period since
> then to make sure nothing came up and some minor concerns where raised as
> PR, which have all since been merged.
> >
> > At this time, I am opening an ACCEPTANCE VOTE. Per the by-laws, the
> acceptance vote is limited to Core Committee members. The vote will close
> either at 23:59:59 UTC on 24 March 2019, or when all CC members have cast
> their vote, whichever comes first.
> >
> > The relevant materials are as follows:
> >
> > - Specification:
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md
> > - Metadocument:
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md
> >
> > PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
> > Current CC Members are as follows:
> >
> > Beau Simensen
> > Larry Garfield
> > Matthew Weier O’Phinney
> > Sara Golemon
> > Cees-Jan Kiewiet
> > Lukas Kahwe Smith
> > Samantha Quiñones
> > Chris Tankersley
> > Korvin Szanto
> > Stefano Torresi
> > Michael Cullum
> > Chuck Burgess
> >
> >
> > Cees-Jan Kiewiet, your friendly neighbourhood PSR-14 Sponsor
>

-- 
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/CAFojS1tF4vsqnKHPb3%3DZu_2XfJfu969HshkLnrY3941oxGYrxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Adopt Code Manifesto

[Stefano Torresi]

This is great, Margaret, thanks! Spot on!

Il giorno lun 4 feb 2019 alle ore 19:30 Matthew Weier O'Phinney <
mweierophin...@gmail.com> ha scritto:

> Margaret —
>
> Thank you, thank you, thank you for sharing your findings and your
> proposed changes. I think these look wonderful: everything is clearly
> spelled out in terms of what is not allowed, how and who to report to, and
> what will happen.
>
> On Sun, Feb 3, 2019 at 5:28 PM Margaret Staples <
> margaret.stap...@gmail.com> wrote:
>
>> I've done a lot of research in the last few years on serving
>> underrepresented developers in tech community spaces, which has
>> unsurprisingly included a ton of info on what's important in a CoC.
>>
>> Here are the things I have turned up as important to an effective Code of
>> Conduct
>> (removing the bits that are only relevant to events)
>>
>> Code of Conduct provides...
>>
>>- a clear reporting process*
>>- multiple ways to report
>>- an anonymous reporting option**
>>- options for reporting to humans of different gender presentations
>>
>> Code of Conduct is...
>>
>>- prominent on the website
>>- discussed openly and supportively by leadership
>>
>> Code of Conduct contains...
>>
>>- clear language on expected behavior including zero tolerance for
>>derogatory language about or harassment of people of color, women, LGBTQ,
>>those with disabilities
>>- clear language on potential consequences for bad behavior
>>- clear language emphasizing intervention and safety
>>
>> * this means making it clear what people can expect when/if they report.
>> ** anonymous reporting means that the people empowered to manage Code of
>> Conduct violations investigate concerns reported anonymously and are
>> vigilant in observing anyone reported as having concerning behaviors so as
>> to be able to intervene; this does not mean assuming every report is 100%
>> accurate and doling out judgements and punishments in response. It is to
>> enable protection of the most vulnerable - not an avenue to anonymously
>> terrorize others.
>>
>> Additionally, a word of warning on the perfectly understandable desire to
>> emphasize positive behavior over discouraging misbehavior: this type of
>> language is routinely used by those who wish to maintain the status quo of
>> their empowerment to silence marginalized humans attempting to defend
>> themselves.
>>
>> Here's an article that looks at this issue:
>> https://thebias.com/2017/09/26/how-good-intent-undermines-diversity-and-inclusion/amp/
>> It focuses on the idea of "assume good intent", but it works similarly for
>> all language which emphasizes nice behavior rather than emphasizing
>> avoiding or correcting harmful behavior.
>>
>> I have taken the proposed CoCs and modified them to be inline with the
>> content standards. I hope you find this feedback helpful.
>>
>> Conduct
>>
>> All individuals involved with FIG either in an official capacity
>> (Secretary, Core Committee, Project Representative, Editor, or Working
>> Group member) or informally (such as participating in discussions) are
>> expected to conduct themselves in a professional manner at all times. All
>> individuals are expected to behave in a manner consistent with the slightly
>> modified Code Manifesto included below.
>>
>> In the case of an individual holding a formal position, bad behavior may
>> result in a Recall or Expulsion Vote may be called to remove the individual
>> in question. In the case of any individual, any two Secretaries may issue a
>> formal warning to the individual in question or issue a temporary or
>> permanent ban from all FIG-related communication channels, as appropriate
>> to the situation.
>>
>> The Editor and Sponsor of a Working Group may jointly remove any member
>> of the Working Group for failure to abide by the behavior guidelines at any
>> time.
>>
>> Concerning behavior may be reported publicly in any thread, privately to
>> any Secretary, to the relevant Working Group Editor or Sponsor, or
>> anonymously by emailing secretar...@php-fig.org
>>
>> Modified Code Manifesto
>>
>> We want to work in an ecosystem that empowers developers to reach their
>> potential--one that encourages growth and effective collaboration. A space
>> that is safe for all.
>>
>> A space such as this benefits everyone that participates in good faith.
>> It encourages new developers to enter our field. It is through discussion
>> and collaboration that we grow, and through growth that we improve.
>>
>> In the effort to create such a place, we hold to these values:
>>
>>1. *Discrimination harms us*. This includes discrimination,
>>derogatory language, or harassment on the basis of race, gender, sexual
>>orientation, disability, age, nationality, technology and any other
>>arbitrary designation of a group of people.
>>2. *Boundaries honor us*. Your comfort levels are not everyone’s
>>comfort levels. Remember that, and if brought to your attention, 

Re: [PSR-17] ResponseFactoryInterface

[Stefano Torresi]

>
> Like, why doesn't it have a withHeaders() method that lets you
> apply/replace all the headers?
>

I guess because what that would do in every implementation is calling
`withHeader` in a loop. :-P

Is this really that big of a problem? OTOH the message interface is already
quite crowded.

Also, a very lengthy discussion could be made on how the `$headers` input
array should or shouldn't be structured.

-- 
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/CAFojS1skBKzRX-%3D-8FGT-hmOJc4gTWp41vQ68d7bNuM9gOsOnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-18 HTTP-Client

[Stefano Torresi]

Hello Steven,

I am curious why the RequestExceptionInterface does not also include a
> getResponse method. Unless I am missing something (or likely some
> conversation elsewhere) it seems that if the request failed after
> connecting with a server that there would be a response.
>

Nope, that's not what it means. Here is an abstract from
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-18-http-client.md#error-handling
:

A Client MUST throw an instance of Psr\Http\Client\ClientExceptionInterface if
and only if it is unable to send the HTTP request at all or if the HTTP
response could not be parsed into a PSR-7 response object.

If a request cannot be sent because the request message is not a
well-formed HTTP request or is missing some critical piece of information
(such as a Host or Method), the Client MUST throw an instance of
Psr\Http\Client\RequestExceptionInterface.

So, in a nutshell, the exception means exactly that there is no response.

Cheers,
Stefano

-- 
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/CAFojS1u6Ckv38-Gg--qhXkiB10xwS1fgSV_WedoktNcDbz7Vaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSSION] PSR-18 HTTP Client Acceptance Vote

[Stefano Torresi]

>
> My understanding is that HTTPlug was always the reference and it looked
> like from this post that it wasn't enough.
>

Well, that's correct, as in: it wasn't enough by itself because we needed
at least another reference implementation. ;-)
Anyway, I think everything has been sorted out now, so no worries.

Kudos to the PSR-18 WG!

-- 
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/CAFojS1t_EJpjz1ZEWE7LcTjFZw2XQVHKwWPmuxVYYStAjc%2BeZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSSION] PSR-18 HTTP Client Acceptance Vote

[Stefano Torresi]

>
> In my opinion asking existing software to implement a standard which has
> not yet been accepted and integrate it into the master branch would be
> horrific from a professional software development point of view, so I
> really hope that you do accept PRs and branches as an example of
> implementation.
>

That's not what we're asking for at all, we're just asking to provide 2
reference implementations, they don't necessarily have to be presented as a
GA release of a super-popular library, they could even be PoC made ad-hoc
by the WG.
There is nothing peculiar about this PSR, if the WG wants to provide
HTTPlug as a reference, by all means, a dedicated branch will do; we just
need to browse the code and play with it, and yes, these implementations
should be listed in the metadoc, and they must be fit as good examples for
anyone who may need pointers while trying to implement the spec by
themselves.

>

-- 
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/CAFojS1tG95A0o9dLxj-rT-XC3kAPYucc%2BmKKbWdnOgyqNJ2d%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-5] Variadic Parameters

[Stefano Torresi]

Thanks Chuck,
That's what I thought, i.e. the presence of `...` already implies that the
parameter is an array, so adding [] should not mean the same thing.

Il giorno mar 16 ott 2018 alle ore 15:03 Chuck Burgess 
ha scritto:

> On Monday, October 15, 2018 at 4:23:46 PM UTC-5, Stefano Torresi wrote:
>>
>> Hey list,
>> what if one wanted to hint to a varable number of arrays of DateInterval?
>>
>> e.g. `func(array ...$intervals) {}`
>>
>> Isn't this what `@param DateInterval[] ...$intervals` should actually be
>> used for?
>>
>> Cheers
>>
>
>
> I had thought of this possibility soon after my original email... but was
> self-throttling until today to bring it up :-D
>
> I agree with Stefano, that this use case is feasible, and thus the syntax
> needs to account for it.
>
> So, the datatype part of the syntax represents a series of DateInterval
> objects being passed individually, then `@param DateInterval ...$intervals`.
>
> If it's actually a series of *arrays* that each contain DateInterval
> object members, then `@param DateInterval[] ...$intervals` would signify
> that.
>
> CRB
>

-- 
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/CAFojS1ubVC4XgFKEqwhFZEogx%3DTDXdUv676X1bvwON8sCZMXww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-5] Variadic Parameters

[Stefano Torresi]

Hey list,
what if one wanted to hint to a varable number of arrays of DateInterval?

e.g. `func(array ...$intervals) {}`

Isn't this what `@param DateInterval[] ...$intervals` should actually be
used for?

Cheers

Il Lun 15 Ott 2018, 23:12 Woody Gilk  ha scritto:

> I agree with Chuck's analysis, as it follows closely with how the code
> is written.
> --
> Woody Gilk
> https://shadowhand.me
>
> On Mon, Oct 15, 2018 at 3:55 PM Robbie Averill 
> wrote:
> >
> > Hi Chuck,
> >
> > Seeing as $intervals is an array when accessed directly from within the
> method (via $intervals), it seems to me that @param DateInterval[]
> ...$intervals would make sense.
> >
> > Cheers,
> > Robbie
> >
> > On Mon, 15 Oct 2018 at 22:46, Chuck Burgess 
> wrote:
> >>
> >> The current draft does not contain references to or examples of
> variadic parameters, since they entered the PHP language after the early
> PSR-5 drafts were done.  Assuming that folks agree that they should be
> represented in the spec, this email thread opens the discussion on the
> syntax to use.
> >>
> >> Previous discussion exists here (
> https://github.com/phpDocumentor/fig-standards/issues/121), for
> background reading.
> >>
> >> The key question on syntax is not whether to include "..." in the spec,
> but with whether or not "[]" should also be shown:
> >>
> >> * @param DateInterval[] ...$intervals
> >>
> >> vs
> >>
> >> * @param DateInterval ...$intervals
> >>
> >> Both are meant to imply that the variable number of parameters passed
> can be expected to be found inside an $intervals array of DateInterval
> objects.
> >>
> >> Please reply to this thread with thoughts on this...
> >> CRB
> >>
> >> --
> >> 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/7176991b-5b4e-4d88-adeb-9ccd3189f7a6%40googlegroups.com
> .
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > Robbie Averill | Senior Developer
> > 04 978 7330
> > http://silverstripe.com/
> >
> > --
> > 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/CANv6TC1XyHBVnj1siXkQcHH3SNahVrsRBLSf7XTy1v2Bmh6T5g%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/CAGOJM6%2BG9_Pwf-NWE6JTBh1cJ%3Dqx3_3vLYU0NrBFTgAh%2BXSGqA%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/CAFojS1tMJGeXmzeo5_jVrSpt2UZu93iBpN195hbYKzoNHtHQxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ACCEPTANCE VOTE][CC] PSR-18 HTTP Client

[Stefano Torresi]

+1

-- 
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/CAFojS1vy%3DFC%2BEs9io9nZtY4xqkZJt7ESZ99Ea9jzKz8hHAHLLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [DISCUSSION] PSR-18 HTTP Client Acceptance Vote

[Stefano Torresi]

Hey folks,
I know it was a very minor nitpick, but my issue with explaining the naming
rationale behind `sendRequest(Request $request)` in the metadoc doesn't
seem to have been addressed.
Here is a PR for you, I hope you find it appropriate:
https://github.com/php-fig/fig-standards/pull/1096

Cheers

-- 
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/CAFojS1tGsZWptzyb8y_1sF-zxnMhZJOAetTNWNwzKd%3DivoSXUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Post deleted not 5 seconds efter posting?

[Stefano Torresi]

>
> seriously, Google Groups is a showcase of everything you can do wrong in a
> web app.
>
> I don't ever want to post here again :-(
>

Is there a reason why you don't just use it as a mailing list? I never use
google groups, fwiw, so I have had 0 problems with it.

-- 
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/CAFojS1tzH-VWU_52CoMV-9RrsWDM9TO8RZ9qt-gg%3D4P2cD7L5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-5: conflicting @api and @internal tags

[Stefano Torresi]

I agree with dropping @api entirely, as it looks like it was introduced for
a very specific requirement of a phpDocumentor presentation use case.

-- 
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/CAFojS1vT10dHOo7WEy%3D82TYdrEkPFDie358nxUs4y1OOMS15%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ENTRANCE] [VOTE] [CC] PHPDoc & PHPDoc Tags PSRs

[Stefano Torresi]

Vote 1 (PHPDoc PSR-5): Yes
Vote 2 (PHPDoc Tags PSR-19): Yes

-- 
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/CAFojS1s%3D_v2XMmdprEayuzsPJdv7Sy9EQTOmJ09QLEwbsdUWPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-17] createStreamFromResource MUST create a readable Stream out of a non-readable resource?

[Stefano Torresi]

Hey Woody,

I think the docblock was intended to read:
>
> > The resource MUST be readable and may be writable.
>

Yep; it appears to be so by reading the original docblock, before splitting
the polymorphic method:
https://github.com/http-interop/http-factory/pull/16


> However, even if that was the case, how would it be enforced? I don't

know of a way to check if a resource is readable.
>

I guess with stream_get_meta_data ? That's an implementation detail, though.


> This may require an errata to PSR-17.
>

Yup.

-- 
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/CAFojS1tZaex-ArhUGKPhOJGfYJOF_8xGj0ReuHYCG-etgB3G9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-18 HTTP-Client

[Stefano Torresi]

Hello PSR-18 WG,

According to our Naming Conventions bylaw, section 1
: Interfaces MUST
be suffixed by "Interface".
I know that this style has been contested before, but we have an
established convention in place, so we should stick to it.
Anyone who doesn't like this can circumvent it via import aliases (which I
do all the time, by the way).

On a different, opinionated, note, I don't particularly like the main
method signature: public function sendRequest(RequestInterface $request):
ResponseInterface;

The resulting consumer code would look like:

$client->sendRequest($request);

which IMHO is redundant and harder to read; I would much more prefer just:

$client->send($request);

The parameter is explicitly typed already, so I don't think that the
additional hint to "Request" is needed in the name of the method.

This is obviously a small detail, and it can probably be argued either way;
IIRC it has even been discussed already within the WG, but there are no
references in the metadoc, so I'd like the WG to either rename the method
or add some sound reasoning to the metadoc about the current, more verbose,
name.

That's my 2c!

Thanks for your time,
Stefano

Il giorno mer 22 ago 2018 alle ore 21:05 Oscar Otero 
ha scritto:

> Ah, got it!
> And, according with the php docs: PHP classes cannot implement the
> *Throwable* interface directly, and must instead extend Exception
> .
> Thanks for clarification.
>
>
> El 22 ago 2018, a las 21:00, Woody Gilk  escribió:
>
> On Wed, Aug 22, 2018 at 1:59 PM Oscar Otero  wrote:
>
>
> Hello.
> I just saw the proposed specification and would like to congratulate to
> the working group for the great job. I only have a doubt related with the
> ClientException. Why does it extends to Throwable? In my mind it makes more
> sense to extend to Exception, because it represents an exception, not an
> error or other throwable class. This could also cause confusion in a
> try/catch that only catches Exception. I’m sure this was discussed and
> there’s a good reason for that, just I’m curious about it.
>
>
> The ClientException is an interface, and Throwable is an interface.
> Exception is a class and an interface cannot extend a class.
>
> I have to assume this is the reason.
> --
> Woody Gilk
> https://shadowhand.me
>
>
> Thanks!
> Oscar Otero
>
> El 22 ago 2018, a las 20:43, Sara Golemon  escribió:
>
> As of today, with a unanimous vote from the working group, we formally
> begin the REVIEW phase of the proposed PSR-18 (HTTP Client) specification.
> The proposed specification is in the fig-standards repository at the
> following locations:
>
> - Specification:
> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client.md
> - Metadocument:
> https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>
> During the Review phase, acceptable changes to the specification include
> wording, typographical fixes, and clarifications. If you feel major changes
> are necessary, please bring your arguments to the list under this thread.
> If any major changes are considered, we will return to the Draft phase.
>
> The Review period will end no sooner than 19 Sep 2018 at 11:59pm.  At that
> time, if the working group can demonstrate two viable trial
> implementations, and no need for major changes, I will call for an
> Acceptance Vote.
>
> -Sara Golemon
> PSR-18 Sponsor
>
> --
> 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/3e454eb9-5088-40fb-b280-1d82725b512c%40googlegroups.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/C5077FA0-7DF9-4763-816D-1BB6ACAF4684%40gmail.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
> 

Re: [VOTE] Secretary Elections - Voting is Now!

[Stefano Torresi]

- Alessandro Lai
- Ian Littman

-- 
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/CAFojS1vbHQDcLv4RuyRYFm%3D86Yy0O4R-hk9ZLc5OQTA8a-QBsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Courtesy notice of intent to repackage

[Stefano Torresi]

Hey Alice,
You may want to take a look at https://github.com/roots/bedrock for
interesting ideas on this particular topic.
TBH I don't think trying to do vendoring via a duplicate git repo is going
to solve more problems than the ones it introduces, but I see where you're
coming from.

Cheers.


Il Sab 26 Mag 2018, 03:54 Larry Garfield  ha
scritto:

> Thanks for the heads up, Alice.  As long as the LICENSE.md files are
> retained
> (which you're doing) I don't see any issue.
>
> Good luck with pushing/pulling/nudging/cajoling/tricking WordPress into
> the
> modern era.  It's no small task. :-)
>
> --Larry Garfield
>
> On Thursday, May 24, 2018 6:03:29 PM CDT Alice Wonder wrote:
> > Hi,
> >
> > I'm working on a project for management of namespaced classes used within
> > WordPress via a PSR-4 autoloader.
> >
> > I am not a WordPress developer, just someone sick of waiting for
> WordPress
> > to modernize.
> >
> > What I'll be distribution is just a collection of un-modified interfaces
> > from the PSR github so that they are available to classes that want to
> > implement the interfaces.
> >
> > https://github.com/AliceWonderMiscreations/php-fig-iface
> >
> > Yes there's composer, but I don't believe composer belongs on production
> > systems - especially those often managed by a gui in the web application
> > admin panel.
> >
> > This project will probably go nowhere but of course if it did become
> > popular with WordPress admins I would let PHP-FIG manage updates to it if
> > they wanted to.
> >
> > Just wanted to give a headups in case anyone saw it and was confused. I
> > tried to make the README very clear that I am not PHP-FIG but just
> > packaging the interfaces w/o modification.
> >
> > I only put interfaces in it marked as approved, and will periodically
> check
> > for updates. I just want to encourage the use of PSR interfaces for
> others
> > writing classes that can be used in a WordPress environment without
> needing
> > dozens of copies of the same interface individually installed with each
> > plugin that uses it.
> >
> > Thank you for your time. And effort. And interfaces that make life
> easier.
>
> --
> 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/58744228.Po1IOD0pm3%40vulcan.
> 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/CAFojS1vi0n8R_d9OCQ8kP6tq%2BrWQASzdWNz0T-vS%3D3PaJ-sJTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [WG][VOTE] PSR-17 Review

[Stefano Torresi]

We had an interesting discussion on the WG Slack channel and, as far as I'm
concerned, I got to share the design concerns raised by Tobias and shared
by Woody.

As such, I'd like to change my vote to a -1, because I think the current
draft can be made better by segregating the interfaces and avoiding the
inheritance as suggested.

The main argument for shipping extended interfaces for
[Request|Response]FactoryInterface is easier end-user consumption, i.e.
fewer collaborators to depend on.
I ultimately think that, if such a purpose has to be attained, it should be
done not at the expense of the simplicity of the overall design.

Possible alternatives would be including a couple of facade interfaces in
the standard, *in addition to simple ones*, or a full fledged composite
implementation in a *-utils package.

Il giorno sab 19 mag 2018 alle ore 09:01 Tobias Nyholm <
tobias.nyh...@gmail.com> ha scritto:

> I really like the work you've put in and I'm sorry I'm late replying here.
> As you may or may not know, I'm maintaining Buzz, HTTPlug (and sometimes
> Guzzle). I've also written a PSR7 implementation with factories from
> HTTPlug and php-interop. (https://github.com/nyholm/psr7)
>
> I've just read and tested(!!) the specification we are voting on. I'm not
> sure it works to be honest. Here are a few things I found:
>
> *Namespace* (minor): Should we really share the namespace with PSR7? Just
> use 'Psr\Http\MessageFactory'
>
> *Interfaces extending* (critical): I've read the arguments on the meta
> document. The four bullets (
> https://github.com/php-fig/fig-standards/blob/master/proposed/http-factory/http-factory-meta.md#53-why-do-some-interfaces-extend-others)
> are all very true but none is an argument for the interface to extend each
> other.
>
> The first bullet about this in the meta document says:
> > The RequestFactoryInterface and ServerRequestFactoryInterface may each
> need to build a UriInterface from a string URI.
>
> Inheritance is not the answer here. Please use a constructor to inject the
> dependencies (or if you are lazy, do like me
> https://github.com/Nyholm/psr7/blob/0.3.0/src/Request.php#L58).
> Consider a MailFactoryInterface. The mail factory implementation may need
> an EmailValidator. Should the MailFactoryInterface really extend
> EmailValidatorInterface?...
>
> I found it very hard to write factory implementation with these
> interfaces. Most of my classes have to extend each other and I have to put
> the stream factory implementation in a Trait.
>
> *Existing libraries* (major): HTTPlug has been an "de-facto" standard for
> almost 3 years now. The php-http/message-factory has been downloaded over
> 4M times. We (HTTPlug) like PSR-17 and we think it is about time PHP-Fig
> delivers a "real" standard for this. However, the current state of PSR-17
> will not allow HTTPlug to extend PSR-17. It will also not allow
> implementing libraries (like guzzle/psr7 and nyholm/psr7) to have one
> RequestFactory for both PSR-17 and HTTPlug.
>
> There is no mentioning about HTTPlug in the meta docs so I'm not sure it
> has been discussed. This is important for the adoption of the PSR-17.
>
>
> -
>
> These are 3 of my concerns. I really hope that everybody in the working
> group have considered these 3 things before you voted. Or else there I
> believe there is a change to change your vote until the voting period is
> over or until everybody has voted.
>
> I will give my vote on the 29th of May.
>
>
>
> Den torsdag 17 maj 2018 kl. 16:52:17 UTC+2 skrev Glenn Eggleton:
>>
>> +1
>>
>> On Tuesday, May 15, 2018 at 12:06:02 PM UTC-4, Matthew Weier O'Phinney
>> wrote:
>>>
>>> Woody has delegated to me to open a vote to enter the REVIEW period for
>>> PSR-17. This vote is open only to PSR-17 Working Group members; at this
>>> time, that means:
>>>
>>> - Woody Gilk (Editor)
>>> - myself (Sponsor)
>>> - Stefano Torresi
>>> - Matthieu Napoli
>>> - Korvin Szanto
>>> - Glenn Eggleton
>>> - Oscar Otero
>>> - Tobias Nyholm
>>>
>>> The by-laws do not stipulate a time-frame for how long the vote must
>>> run, though 2 weeks is the standard period. As such, the vote will run
>>> until 23:59:59 on 29 May 2018, or until all members have responded. Once
>>> the vote is closed, I
>>> will post the results, and indicate next steps for the proposal.
>>>
>>> PLEASE DO NOT RESPOND TO THIS POST UNLESS YOU ARE ONE OF THE MEMBERS
>>> LISTED ABOVE.
>>>
>>> --
>>> Matthew Weier O'Phinney
>>> mweiero...@gmail.com
>>> https://mwop.net/
>&

Re: [PSR-12] Closure guidelines for anon classes

[Stefano Torresi]

TBH making readers to jump to another section that contains different
informations is kinda lazy.
Can we just copy paste the relevant indications and do without the
reference to the closures?


Il giorno mer 16 mag 2018 alle ore 17:44 'Alexander Makarov' via PHP
Framework Interoperability Group  ha scritto:

> 1. The opening brace MUST go on the same line, and the closing brace MUST
> go on the next line following the body.
>
>
> On Tuesday, April 24, 2018 at 1:53:06 AM UTC+3, Greg Sherwood wrote:
>>
>> Hi,
>>
>> I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question
>> about this section:
>>
>> 8. Anonymous Classes
>>> Anonymous Classes MUST follow the same guidelines and principles as
>>> closures in the above section.
>>
>>
>> Almost the entire closure section of PSR-12 is dedicated to argument
>> lists (not a bad thing). The only section of it that isn't contains the
>> following text:
>>
>> Closures MUST be declared with a space after the function keyword, and a
>>> space before and after the use keyword.
>>> The opening brace MUST go on the same line, and the closing brace MUST
>>> go on the next line following the body.
>>
>>
>> The first rule doesn't have anything to do with anon classes and the
>> second is superseded by a more specific rule in the anon classes section.
>>
>> So my question is: What guidelines and principals should I take from the
>> closure section when writing rules for anon classes?
>>
>> Thanks
>>
> --
> 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/befdbd91-0c62-4dc6-98cd-caca817a8d5f%40googlegroups.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/CAFojS1tPo797ObOJ%3Dg5o3fV3FCkddte055xu8OSm_EvTFDp%2BKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [WG][VOTE] PSR-17 Review

[Stefano Torresi]

+1

Il giorno mar 15 mag 2018 alle ore 19:05 Oscar Otero <oscarot...@gmail.com>
ha scritto:

> +1
>
>
> El 15 may 2018, a las 18:31, Woody Gilk <woody.g...@gmail.com> escribió:
>
> Thank you, Matthew
>
> +1
>
>
>
> On Tuesday, May 15, 2018 at 11:06:02 AM UTC-5, Matthew Weier O'Phinney
> wrote:
>>
>> Woody has delegated to me to open a vote to enter the REVIEW period for
>> PSR-17. This vote is open only to PSR-17 Working Group members; at this
>> time, that means:
>>
>> - Woody Gilk (Editor)
>> - myself (Sponsor)
>> - Stefano Torresi
>> - Matthieu Napoli
>> - Korvin Szanto
>> - Glenn Eggleton
>> - Oscar Otero
>> - Tobias Nyholm
>>
>> The by-laws do not stipulate a time-frame for how long the vote must
>> run, though 2 weeks is the standard period. As such, the vote will run
>> until 23:59:59 on 29 May 2018, or until all members have responded. Once
>> the vote is closed, I
>> will post the results, and indicate next steps for the proposal.
>>
>> PLEASE DO NOT RESPOND TO THIS POST UNLESS YOU ARE ONE OF THE MEMBERS
>> LISTED ABOVE.
>>
>> --
>> Matthew Weier O'Phinney
>> mweiero...@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 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/fe2c196f-31d4-4bc8-bd0b-f44410c48fad%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/fe2c196f-31d4-4bc8-bd0b-f44410c48fad%40googlegroups.com?utm_medium=email_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/95995C15-0F20-4C42-A8EC-E19106CAB429%40gmail.com
> <https://groups.google.com/d/msgid/php-fig/95995C15-0F20-4C42-A8EC-E19106CAB429%40gmail.com?utm_medium=email_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/CAFojS1vB_qD_fRAv_TQ6xB-t0H3AN9O5nP4_UVzfT5NiBG_msQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-14][Entrance][VOTE]

[Stefano Torresi]

+1

-- 
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/CAFojS1voJYH%3D0%3D57iD99AhdHEG-y%3D8EZh6E4Qg424-D1CM-fKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-6][Errata][Vote]

[Stefano Torresi]

+1

Il giorno gio 15 mar 2018 alle ore 12:53 Matthew Weier O'Phinney <
mweierophin...@gmail.com> ha scritto:

> +1
>
> On Mon, Mar 12, 2018, 4:22 PM Larry Garfield 
> wrote:
>
>> Take 3, or 4, or something...
>>
>> This is a Core Committee vote to merge the following Errata PR for PSR-6:
>>
>> https://github.com/php-fig/fig-standards/pull/915
>>
>> I believe all discussion that needs to be had has been had.
>>
>> Vote is open now for 2 weeks, and will close on 3/26.
>>
>> Core Committee, an up or down vote please.
>>
>> --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/2209261.54JSFkv1d7%40vulcan.
>> 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/CAJp_myU70F4s6uTOMGf-%3DkukjHvgRKG1gnhSeAgN_fHvwQKfzQ%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/CAFojS1sW3Yto1yWQiwwtpjzoB2B5AL%3Dgfh31w6Z%2B-wfevFN1Ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: The progress of HTTP client

[Stefano Torresi]

As far as I know, PSR-18 has never been marked as abandoned, I don't even
think the requirements to do so have ever been satisfied. Could the
secretaries confirm, please?

Il giorno gio 15 feb 2018 alle ore 08:47 Tobias Nyholm <
tobias.nyh...@gmail.com> ha scritto:

> Yeah, it has stalled for a few weeks. but we are working on it again. The
> specification looks good, we are currently deciding on an upgrade path from
> HTTPlug. We have a proposal that we think will work. I've invited a few to
> have a look on it (Sara included). If this small group think it is fine I
> will publish it so every one could give their comments.
>
> If no major issues are found I will move the PSR to review.
>
> Den onsdag 14 februari 2018 kl. 13:11:46 UTC+1 skrev Barry vd. Heuvel:
>>
>> Apologies, I now see that PSR-18 is referenced in the Sunshine meetings (
>> https://groups.google.com/forum/#!topic/php-fig/sjASl6ltjHI )
>>>
>>>
>>> PSR - 18 HTTP Client (*Abandoned*)
>>>
>>>- Tobias identified an issue and will be notifying the group to
>>>source needed changes.
>>>   - Tobias is waiting on *Sara to offer feedback*.
>>>- This PSR needs 2 implementations to move forward.
>>>
>>> Status abandoned, is that supposed to be Draft? As you are discussing
>> the issue with the group. Or are you in search of a new Editor?
>>
>>

-- 
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/CAFojS1vm9bfw3MxtVK94g-8NE%2BuFv2aKH4AciAwHYj5YzmFT8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC][VOTE] PSR-17 Working Group

[Stefano Torresi]

+1

Il giorno lun 5 feb 2018 alle ore 19:23 Matthew Weier O'Phinney <
mweierophin...@gmail.com> ha scritto:

> Clearly, a +1 from me.
>
> On Mon, Feb 5, 2018 at 12:22 PM, Matthew Weier O'Phinney
> <mweierophin...@gmail.com> wrote:
> > Last year, in May, I opened a discussion period regarding the PSR-17
> > working group, as the proposal pre-dated the latest by-laws... and
> > then evidently forgot to open a vote for it.
> >
> > So, I'm opening a vote as of today, 2018-02-05. Per the by-laws, this
> > vote is for Core Committee members only, and will run until all
> > members have voted, or 23:59:59 on 2018-02-19, whichever occurs
> > soonest.
> >
> > The proposed working group is as follows:
> >
> > - Editor: Woody Gilk
> > - Sponsor: myself
> > - Members: Stefano Torresi, Matthieu Napoli, Korvin Szanto, Glenn
> > Eggleton, Oscar Otero, and Tobias Nyholm.
> >
> > --
> > Matthew Weier O'Phinney
> > mweierophin...@gmail.com
> > https://mwop.net/
>
>
>
> --
> 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 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_myX4vuGBK9odg31BdtGw-8Kq119bhNnAv5mZ%3DR%3DYPLhqPg%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/CAFojS1uRW1PXrzYSgjSOmJyJ-%3D_Wc1i98tvwzGsSmDUC_ERaqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC nomination] Stefano Torresi

[Stefano Torresi]

Thanks Matthew! Needless to say I gladly accept the nomination!

Il Mer 10 Gen 2018, 15:32 Matthew Weier O'Phinney <mweierophin...@gmail.com>
ha scritto:

> I hereby nominate Stefano Torresi for another term on the Core Committee.
>
> Stefano has proven to be a hands-on committee member, working to
> re-launch the FIG website, participating heavily in working groups,
> and providing collegial feedback and discussion. I would heartily
> welcome having him around for another term.
>
> --
> 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 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_myV9h4QWu_P9R%3DrU%2Bswtrx22LtQtbAgwdr_Y4nYQL1YHWg%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/CAFojS1scjXrNqJjJssu4%3DuzEbbzLD9A3pzB3bS2vRJM7jo8_4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internals] Secretary & 4 Core Committee Nominations Open

[Stefano Torresi]

Hello list,

As I feel I can still give valuable contributions to the processes that
will produce current and future proposals, I'd like to stand for
re-election as a member of the Core Committee.
I hope the group will accept my re-candidacy.

Cheers, and happy 2018!

Il giorno mar 2 gen 2018 alle ore 00:14 Alessandro Lai <
alessandro.la...@gmail.com> ha scritto:

> Last but not least, spread the word! Please retweet this:
> https://twitter.com/phpfig/status/947969054043762689 and actively search
> people that could be nominated!
>
> Il giorno martedì 2 gennaio 2018 00:11:02 UTC+1, Alessandro Lai ha scritto:
>>
>> Hi all,
>>
>> The nominations for 4 Core Committee seats and one Secretary position are
>> open; sorry for the delay of this announcement, but I was away from a
>> keyboard for the holidays, and I'm excited to perform my first official
>> duty as a Secretary! I would also like to take the time to thank Michael
>> (whose term as a Secretary is now ending) for such a speedy onboarding for
>> us two newly elected Secretaries, and for the enormous work that he has
>> accomplished in the last two years in our transition to the FIG 3.0. Thanks
>> also to the four CC members whose terms are ending also.
>>
>> Below are some practical details and FAQs.
>>
>> Anyone can be nominated, including the five persons with expiring terms,
>> any Secretaries or project representatives, or any person which would like
>> to be more involved with the FIG.
>> ONLY Member projects and Secretaries may nominate, without any limit, to
>> be CC or Secretary candidates.
>>
>> If you would like to nominate someone, please get in touch with them and
>> speak with them about it first. But please do actively seek out people you
>> think should be on the Core Committee to nominate them, don't wait for them
>> to ask you to nominate them.
>>
>> If you would like to stand/accept a nomination, please contact the
>> seating secretaries (me, Michael or Margaret) to find out a bit about what
>> the relative role entails. You may seek a nomination any way you wish
>> (requesting on the mailing list, asking individuals in private, etc.).
>>
>> A list of nominees will be maintained here
>> 
>> . Remember that the nomination must be accepted to be valid, so please
>> ensure that you confirm your nomination if you wish to and someone
>> nominates you.
>>
>> Nominations close on the 11th January at 23:59 UTC.
>>
>> FAQs:
>>
>> What does the role of a CC member entail?
>> To quote the Bylaws:
>>
>> “The Core Committee is a twelve (12) member board of individuals
>> recognized for their technical skill and expertise. The Core Committee is
>> responsible for final decisions regarding what specifications FIG will
>> consider and those that are approved. The Core Committee is responsible for
>> ensuring a high level of quality and consistency amongst all published
>> specifications, and that all relevant perspectives and use cases are given
>> due consideration.”
>>
>>
>> The core committee acts as a steering group and handles all entrance
>> votes and, after being completed by working groups, has the final
>> acceptance vote on new PSRs and is responsible for making sure
>> specifications meet the technical direction of the FIG, are of good
>> quality, and have taken relevant stakeholders into account. The core
>> committee is expected to be able to keep an eye on what is going on in the
>> FIG. While this doesn't mean reading every mailing list post or every
>> GitHub issue, this does mean having a general awareness of what is going on
>> and regular activity is expected (e.g. they should be voting on every core
>> committee two-week vote unless there are particular circumstances
>> preventing them from doing so).
>>
>> What does the role of a Secretary entail?
>> The full role can be read from the bylaws here:
>> http://www.php-fig.org/bylaws/mission-and-structure/#secretaries
>>
>> Between the three secretaries they handle all the administration that
>> goes on with the FIG such as votes, the website, GitHub as well as also
>> being responsible for moderation of FIG mediums and representing the PHP
>> FIG to the wider PHP community. Feel free to reach out to any of the
>> seating Secretaries if you would like to know more about the role.
>>
>> What does a Core Committee member look like?
>> The idea of the core committee is that it should reflect a cross section
>> of the PHP ecosystem and community.
>>
>> This means it's important to have a range of people including (but not
>> requiring or limited to) those with experience relating to things such as:
>> - Large & small framework maintenance
>> - Library maintenance
>> - Consumer package maintenance (by consumer package I mean CMS, blogs,
>> forums, etc.)
>> - HTTP and non-HTTP based PHP
>> - Legacy and modern projects
>> - PHP internals
>> - Specific topics such as Async and Security
>>

Re: [WG][VOTE] PSR-15 Review

[Stefano Torresi]

+1

Il giorno gio 30 nov 2017 alle ore 19:32 Woody Gilk <woody.g...@gmail.com>
ha scritto:

> +1
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> On Thu, Nov 30, 2017 at 11:09 AM, Oscar Otero <oscarot...@gmail.com>
> wrote:
>
>> +1
>>
>> On Nov 30, 2017 17:39, "Matthew Weier O'Phinney" <
>> mweierophin...@gmail.com> wrote:
>>
>>> At this time, I'm opening a vote to enter the REVIEW period for
>>> PSR-15. This vote is open only to PSR-15 Working Group members, which
>>> include:
>>>
>>> - Woody Gilk (Editor)
>>> - Matthew Weier O'Phinney (Sponsor)
>>> - Stefano Torresi
>>> - Matthieu Napoli
>>> - Korvin Szanto
>>> - Glenn Eggleton
>>> - Oscar Otero
>>>
>>> The by-laws do not stipulate a time-frame for how long the vote must
>>> run. As such, I will set a maximum time-frame of 1 week, and close it
>>> sooner if all voters respond before then. Once the vote is closed, I
>>> will post the results, and indicate next steps for the proposal.
>>>
>>> PLEASE DO NOT RESPOND TO THIS POST UNLESS YOU ARE ONE OF THE MEMBERS
>>> LISTED ABOVE.
>>>
>>> --
>>> 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 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_myWOyDHYBvB8pGwTHSfRe6Rp0MmxmGYWFoq7nY%2B9YR6xNw%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/CALrFU9WSmGgTnQW_tWw_k6sSf3fEOFGt3o8WqnTVjoXyRsVopA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/php-fig/CALrFU9WSmGgTnQW_tWw_k6sSf3fEOFGt3o8WqnTVjoXyRsVopA%40mail.gmail.com?utm_medium=email_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/CAGOJM6%2BT9OkK_jPfnGA7HANpj90junTLFai1U3YcGLVqzAiNSg%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BT9OkK_jPfnGA7HANpj90junTLFai1U3YcGLVqzAiNSg%40mail.gmail.com?utm_medium=email_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/CAFojS1uGn_Vw0-cebhQv8RjBbwcyLvqDhDskL4kVPZW%3DazvAyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for RDF interfaces

[Stefano Torresi]

Hey Konrad,

You can temporarily find the list here:
https://github.com/stefanotorresi/fig-standards/blob/5804f440faf78cde4b0c21b6bcd2cee64cf04778/personnel.md

This will be published in the website and the main fig repo soon.

Il giorno lun 20 nov 2017 alle ore 14:58 Alessandro Lai <
alessandro.la...@gmail.com> ha scritto:

> Michael (one of the current secretaries, besides me) already replied in
> the PR:
> https://github.com/php-fig/fig-standards/pull/958#issuecomment-345666199
>
> Reach to him and ask any question you want.
>
>
> Il giorno lunedì 20 novembre 2017 11:19:06 UTC+1, Konrad A. ha scritto:
>>
>> Hello Alessandro,
>>
>> thanks for the reply. I have a hard time finding a list of all Core
>> Committee members (only found http://www.php-fig.org/members/ at the
>> moment). And what would you suggest to reach them/ask them directly?
>>
>> Regards
>> Konrad
>>
>> On Monday, November 20, 2017 at 10:42:35 AM UTC+1, Alessandro Lai wrote:
>>>
>>> Hello!
>>> As I've already stated on the PR (
>>> https://github.com/php-fig/fig-standards/pull/958#pullrequestreview-77724961)
>>> you should follow the PSR workflow and form a working group with a CC
>>> member as a sponsor. Feel free to use this thread as a starting point!
>>>
>>> Il giorno mercoledì 8 novembre 2017 11:11:17 UTC+1, Pieter Colpaert ha
>>> scritto:

 As the author of hardf I +1 the need for such a specification and if
 this would become a PHP-FIG standard, I will comply to it.

 Kind regards,

 Pieter

 Op dinsdag 7 november 2017 15:11:40 UTC+1 schreef Konrad A.:
>
> Hello,
>
> i would like to propose new interfaces representing RDF terms (
> https://www.w3.org/RDF/) to have a basement for framework/library
> interoperability.
>
> # Motivation
>
> There are currently 5 RDF-libraries for PHP available (EasyRdf,
> Erfurt, hardf, ARC2 and Saft). Each implements different areas with 
> various
> quality
> and feature-coverage. Combined, they provide a rich feature-set from
> RDF data handling, serialization and parsing to database access.
> Therefore it is important, that each library uses the same data model
> for RDF data to allow data interchange.
>
> # Background
>
> The proposed interfaces and example implementations are based on a PHP
> RDF framework i maintain (https://github.com/SaftIng/Saft).
> This means, that they are battle tested and i already created (basic)
> converter to work with all major frameworks.
>
> # Further information
>
> This is my first proposal and i am new to this PHP-FIG/PSR stuff, so
> if forgot something, please let me know. :)
>
> *Quick link for the specification:*
> https://github.com/SaftIng/fig-standards/blob/psr-rdf/proposed/rdf/rdf.md
> *Link for interfaces and example implementation:*
> https://github.com/SaftIng/PsrRdf
>
> Kinda regards
> Konrad Abicht
>
>
> --
> 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/dc6dfa3a-3a5c-4f4d-9f70-bce05816473f%40googlegroups.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/CAFojS1to81-A4b4y5ZSb-6PEBM8fMz4z2TVJ6%2BmrHnQHvBrsNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][CC] Entrance vote for PSR-12: Extended Coding Style Guide

[Stefano Torresi]

+1

Il Gio 19 Ott 2017, 21:51 Cees-Jan Kiewiet  ha scritto:

> +1 Cees-Jan Kiewiet
>
> --
> 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/CAPY1sU--6p%2BQNL_JeQ-K14BF%2B3OOM-OjDVC9DqdbfOkmQDV1bw%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/CAFojS1tMehK4mMTkUqQMdXG8v7XysBCgWr4DBBv2FUKggL82UQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] Secretary Election

[Stefano Torresi]

1. Alessandro Lai

Il Gio 19 Ott 2017, 23:17 Michael Cullum  ha scritto:

> Hi all,
>
> We've been attempting to get more nominations so this has been delayed a
> few times but we now have three candidates so we're rolling with it.
>
> Full information about the Secretary vote and role is visible in the
> bylaws here:
> http://www.php-fig.org/bylaws/mission-and-structure/#secretaries
>
> You can check out their nomination topics and ask questions there.
>
> *Votes may be cast by project reps or CC members.* If an individual is
> both a rep and a CC member, they may one vote once.
>
> *Nominations List*
>
>- Margret Staples - Topic
>
>- Alessandro Lai - Topic
>
>- Mark Railton - Topic
>
>
> *How to vote*
> The voting system used is STV[1][2], so basically, *there is no tactical
> voting possible* (like with FPTP); *vote for who you want*, even if they
> are a less popular candidates as your vote will move down to a different
> candidate if you back an unpopular candidate who doesn't have enough votes;
> if a candidate is elected, their surplus votes are also re-allocated so you
> are not punished for backing popular candidates either. There is no quorum,
> you are of course entitled to not vote and it will not count as a missed
> vote on the voting sheet. *Rank the candidates in order of preference *for
> example*:*
>
> 1. Luke
> 2. Leia
> 3. Anakin
> 4. Rey
> 5. Padmé
> 6. Finn
>
> *You may, if you wish, not rank all three candidates* (however this is
> relatively pointless in STV, only do this if your bottom candidates are of
> equal preference to you). For example:
>
> 1. Luke
> 2. Anakin
> 3. Padmé
> 4. Leia
>
> *The vote ends at 23:59 UTC on the 2nd November,* and I will close the
> vote and *announce the result at some point on the 3rd*. At any time, any
> candidate or voting member may privately ask me to do a count and tell them
> who would be elected to which term if the vote ended at that point.
> Please be wary of 'STV calculators' on the internet as there are many
> different ways of calculating the vote reallocation for STV and many are
> inaccurate, our methods are dictated in the bylaws.
>
> Good luck to all the candidates!
>
> --
> Many thanks,
> Michael Cullum
> FIG Secretary
>
> [1]: STV User-friendly Explanation
> https://www.youtube.com/watch?v=l8XOZJkozfI
> [2]: https://en.wikipedia.org/wiki/Single_transferable_vote
>
> --
> 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/c38e9460-fe49-4687-b783-710932557e3f%40googlegroups.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/CAFojS1sT5b1FvibFOc0nK1JWpSiRMO2gyYM0FKQGH1NKOSFhrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-15 version target [was: Re: PSR-15 Generators]

[Stefano Torresi]

Il giorno ven 4 ago 2017 alle ore 14:16 Niklas Keller <
nicks.post.kes...@gmail.com> ha scritto:

> Something like that is pretty stupid. It prevents having an implementation
> that's compatible with both, 5.6 and 7. And two versions of a package can't
> be installed side-by-side with Composer. New major versions of PSRs should
> definitely use new package names for that reason.
>
> Regards, Niklas
>

This has been brought up a number of times already, and disregarding it as
"stupid" will not drive to a definitive solution.

At PHPDay unconference, participants in the discussion deemed this as
generally not much of an issue, mostly because you already have to comply
to this constraint anyway: you can't install packages having incompatible
dependency graphs, so why bother trying to circumvent this limitation for
PSRs only?

While I understand and agree with the principle, in practice the chance of
having dependency issues due to migrations between major versions is very
high anyway.

That said, if we want to release entirely different PSRs for updated
versions (which would be arguably a cleaner solution), I think we need to
streamline the process and make it easier, because at the moment it's so
much of a PITA that nobody wants to do it.

-- 
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/CAFojS1vYdrBsrqN_WZ8rMs3fJsWUzCRjZ58ru%2BGUSRN6a8a2ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-15 version target [was: Re: PSR-15 Generators]

[Stefano Torresi]

I think the real problem behind this discussion is PSR versioning. We
should address that first, because the process of releasing a new PSR to
bump requirements is time consuming and inefficient, as Woody maybe wrote
between the lines.

Il Gio 3 Ago 2017, 18:26 Woody Gilk  ha scritto:

> On Thu, Aug 3, 2017 at 10:37 AM, Larry Garfield 
> wrote:
>
>> Let's go ahead and target PHP 7.0 for PSR-15 outright.
>>
>
> I'm going to say no to this. There is already a significant ecosystem of
> middleware that supports PHP 5.6 and I want those early adopters to be able
> to use PSR-15 right away. It will hurt adoption of PSR-15 to force the jump
> to PHP 7+.
>
> That said, I *do* think that PSR-15 should immediately ship a version
> 2.0.0 of `psr/http-server-middleware` that enforces strong typing. (No need
> for PHP 7.1 or 7.2, because there is no "void" return in PSR-15).
>
> Now someone will come along and tell me that such a change requires a
> whole new PSR... 
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> --
> 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/CAGOJM6LeMXaMEhcqm6Ue-EsxeMXXeHHJHzJX%3DSyoL568eD2g_g%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/CAFojS1sRWHRfpuBqp5GtS-Xcgxzy0zDS0ibHH98rY2z878sj2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][CC] Entrance vote for HTTP Client

[Stefano Torresi]

+1

Il giorno gio 3 ago 2017 alle ore 17:03 Sara Golemon  ha
scritto:

> On Thursday, August 3, 2017 at 11:03:13 AM UTC-4, Sara Golemon wrote:
>>
>> Per http://www.php-fig.org/bylaws/psr-workflow/ This is the entrance
>> vote for the HTTP Client PSR Discussion
>>
>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>>
>>
> And this is my +1 vote.
>
> --
> 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/381b6f4a-cac0-4b24-a717-25188c000f49%40googlegroups.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/CAFojS1ucpJp%2B5XjOQv5HjoJ96SYeCiYcRnkqHse4Q1DL4UTkew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Psr naming and namespaces

[Stefano Torresi]

As we discussed on slack, I have of the exact same views as Matthew on the
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/CAFojS1sBnjiVJPq34yaoWbrJ4N%2BYXAenS3ZKqAOVwKWUQej3zw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A period of quiet, but now, rejuvenation

[Stefano Torresi]

Keep up the good work, Michael, it's great to have you back!

LETS MAKE FIG GREAT AGA... uhm, wait, no. Let's just... get back to work at
full capacity. ;)

Il giorno dom 16 lug 2017 alle ore 22:56 Michael Cullum 
ha scritto:

> Hi all,
>
> I think there is little denying that the FIG has been quieter than last
> year in this year to date. A variety of factors have contributed to this
> based primarily around the fact a number of the most active drivers within
> the FIG have had other life events occur which has taken time away from the
> FIG including Amanda and myself both having medical problems. This followed
> a year of intense technical and political activity, both of which have
> potentially burned out some contributors. However, the FIG must be be able
> to continue without just a small group of active people, and must continue
> for its mission is too important. Recently there has been a small revival
> in activity that we should ensure continues. I’m back around and now in
> good health, and a number of other contributors and core committee members
> have been pushing to gets balls rolling again.
>
> Secretary Election
>
> As some of you may have realised, Amanda’s term as secretary has actually
> ended, and we also need to elect a replacement for Samantha with her having
> moved to the Core Committee. Getting this election underway to bring us
> back up to a strong number of three secretaries to help push forward these
> efforts is a big priority and so there will be a secretary election next
> month for these two positions. I will post a formal email this week with
> regards to a timetable and what that entails, and immediately we’ll start
> seeking out people who might be interested in being nominated.
>
> Website
>
> The website has been outdated since the FIG 3.0 election due to a number
> of issues with Jekyll, the static site generator we use. There has for a
> long time been a plan to convert the website to Sculpin so that it makes it
> easier for us (PHP developers) to be able to contribute and keep it
> updated. Amanda was initially intending to lead on this effort but personal
> circumstances prevented her from doing so. Larry has kindly offered free
> hosting from Platform.sh and he, with Stefano, are also willing to help the
> secretaries in putting in time to building the base for this Sculpin site.
> If anyone else is willing to contribute and help, we’d love to hear from
> you.
>
> The Jekyll website now (thanks to Stefano) has been updated with FIG 3.0
> guidelines but there are a string of further changes we intend to make and
> I will again publish some kind of roadmap for those changes in the coming
> weeks, which will include the new voting system which is currently in a
> half-done state but needs a final push to get it completed. In the
> meantime, it’s great to have our bylaws now updated and our current website
> back in maintainable position.
>
> Status of PSRs and Working Groups
>
> Over the next week or so, I’ll be contacting and reaching out to the
> various people who were working on PSRs so we can get a good summary of
> where PSRs are currently sitting. They will then either all go into an
> ‘Abandoned’ state, or we can hopefully kickstart some with forming working
> groups and resuming activity. There are also a number of people wanting to
> start new PSRs and I’ll be reaching out to those individuals that I know of
> so we can hopefully bring those to further discussion on this here mailing
> list and to entrance votes.
>
>
> Please do reach out to me or the mailing list if you wish to be involved
> in any existing or new PSRs and I can either put you in touch with the
> right people or help you get started in kickstarting any efforts.
>
> Other initiatives
>
> Formal Summit: There was talk of a formal summit in the Autumn of this
> year and I regret to say this is unlikely to happen this year, however,
> once we have a full complement of secretaries, a suitable amount of time to
> plan and submit those proposals to member projects and the Core Committee,
> likely next year, then this is certainly something that can be looked into
> once again. We’ll likely open up some discussions about the feasibility of
> this next year. It’s still very possible to organise some more informal FIG
> get-togethers at conferences later this year however, and these would be
> very much encouraged.
>
> Fora: One of the aims of the FIG is not just to build standards but also
> to act as a forum for projects and people from all over the PHP community
> to come together and collaborate towards shared aims. There have been
> numerous discussions of therefore setting up informal sub-groups of people
> to ease collaboration on matters such as security across the community. I
> would love to foster some discussion of setting up these groups later this
> year.
>
> 
>
> There is a lot to do to get the FIG activity moving again, but the FIG was
> founded with the 

Re: Standard for CQRS and Event sourcing

[Stefano Torresi]

Hey folks,

While I find this an interesting discussion, may I remind you that we try
to keep a soft limit of maximum two messages per thread per day, to avoid
flooding list subscribers with too many emails.

If you need a quicker pace of discussion, consider changing medium to IRC
 or Slack .

Thanks

Il giorno ven 19 mag 2017 alle ore 18:39 xprt64  ha
scritto:

> So, there is hope to standardize this :)
>
> This would be good for the PHP community as the efforts would be split in
> implementing the main components of the architecture like the EventStore
> and the CommandDispatcher.
>
> The EventStore that I use is done in MongoDB but some greater minds than
> me (and there are many, that is the power of the community) could implement
> something that is faster, more scalable, more robust, more tested, more
> whatever.
>
> The CommandDispatcher could be implemented as a RabbitMQ queue and many
> decorators implemented (like validators, pipe middlewares etc).
>
> 2017-05-19 19:31 GMT+03:00 Rivera, John :
>
>> Regarding an AggregateCommand extending Command, that is ironically
>> enough exactly how I did it (albeit with a slightly different name) :)
>>
>> John
>>
>> On May 19, 2017, at 12:26 PM, xprt64  wrote:
>>
>> DDD has many patterns, some are at the strategic level and some are the
>> tactical level. Aggregates are at the tactical level are are the building
>> blocks of DDD. Aggregates ensure that the application is in consistent
>> state at all times.
>>
>> Regarding your example, DDD could come into play by defining a FileImport
>> aggregate that yields (raises, returns, whatever; I use the super-nice
>> yield feature of PHP) FileUploaded event or throws an FileIsInvalid
>> exception. You could raise two events if the failed validation is an
>> important aspect of the business that you want to capture, otherwise I
>> would choose to just throw an exception.
>>
>> Anyway, I think I get your point in the first reply: there is a need to
>> send commands to something other than an Aggregate/Entity, like a
>> application service, and I agree with you. So, my Command propose should in
>> fact be a AggregateCommand that inherits from (the now simpler) Command
>> and adds the getAggregateId method.
>>
>>
>>
>> 2017-05-19 18:07 GMT+03:00 Rivera, John :
>>
>>> Hello —
>>>
>>> Let me give you an example.
>>>
>>> We have a requirement: an user uploads a file. This file is to be ETL’d
>>> into the database. But before being uploaded, the file needs to be
>>> validated. And this validation needs to be user-friendly, so the user can
>>> fix the file (we use a custom file format for file uploads). If all goes
>>> well, the file is to be ETL’d into the staging database.
>>>
>>> So I have a command that validates, and uploads, the file. It raises
>>> (actually, returns) two possible events: files uploaded, or validation
>>> failed. The validation failed event triggers the compilation of the errors
>>> into a user-friendly to be returned as a response. The file uploaded event
>>> triggers the ETL process which grabs the file, performs ETL, and loads it
>>> directly into the staging database.
>>>
>>> Where did DDD come into play here?
>>>
>>> John
>>>
>>> On May 19, 2017, at 10:43 AM, xprt64  wrote:
>>>
>>> Hi, thanks for the feedback, it's nice to see that other are thinking
>>> about CQRS in PHP :)
>>>
>>> > ... you’re assuming that we would use DDD as the domain ..
>>>
>>> I assumed DDD as the approach, not the "domain". The domain is the
>>> business domain and probably any (complex enough) domain would work (we are
>>> not talking about CRUD implementations, we are assuming that the problem
>>> CQRS is trying to solve is not solvable by CRUD). I assumed DDD because it
>>> is one of the nicest approaches used to solve complex domains and CQRS is
>>> one of the DDD implementations.
>>>
>>> 2017-05-19 16:38 GMT+03:00 Rivera, John :
>>>
 Hello!

 Thanks for bringing this topic up — I’m a big fan of CQRS/ES!

 But I’ll begin with a caveat — I do not believe it’s suitable to a PSR.
 That is my opinion, and I am definitely open to debate.

 Continuing with the assumption that I was convinced that it’s a worthy
 PSR… I think your interfaces are definitely excessive. Here’s my minimum
 requirements for a working CQRS application:

 Interface Command {}

 interface Query {}

 interface Event {}

 interface Mediator
 {
 public function send(Command $command): void;
 public function request(Query $query): mixed;
 public function raise(Event $event): void;
 }

 That’s it.

 You’re probably asking ‘wait a minute, what about the CommandHandler
 and EventHandler?” — we could have interfaces for each, as follows:

 interface 

Re: Website updates (PSR-11)

[Stefano Torresi]

Nope, indeed that is not the case.

A rewrite of the website in Sculpin is due, but we didn't manage to commit
to that so far, and the current Jekyll setup doesn't help either.

Il giorno gio 18 mag 2017 alle ore 07:23 Ciaran McNulty <
m...@ciaranmcnulty.com> ha scritto:

> http://www.php-fig.org/psr/ indicates that PSR-11 is under review, is
> this the case?
>
> --
> 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/8d22689f-0794-475b-981b-b820628bd0ef%40googlegroups.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/CAFojS1va%3D4ZP5UDL0tvHWYDY%2BZvbt8krUEPe08deCVVAaJZMmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minimal HTTP middleware

[Stefano Torresi]

Hey folks,

To be honest, I don't like any of the alternative approaches proposed so
far; I somewhat recognise the concerns raised here, but I think the strive
to a "purer" design poses a very high risk of being counterproductive. We
have already pivoted from one design to another and, as far as I can tell,
it was worth it.
Pivoting once again, though? That could be too far reaching, leaving alone
the fact I personally don't find the alternatives appealing at all: they
may be simpler in theory, but they completely fail on communicating intent,
having to point at convoluted implementation details to outline where the
dispatching mechanism is, while the dispatching mechanism was outside the
scope of the proposal in the first place.

To be more concise, I think the current proposal is "good enough"(tm).
It is definitely *easier*. It may be not *simpler*, but frankly I don't
think *simpler* is worth the effort, here.

The mission is to move the ecosystem forward, so: would PSR-15 accomplish
that as it is?
Considering the sheer amount of framework-agnostic middlewares already out
in the wild, and the enthusiastic comments I hear around and about on what
people are accomplishing with them, I am pretty sure the current proposal
would result in a great success, both in terms of adoption and objective
improvement over the current status quo (which, may I remember to you all,
is mostly fragmented in a lot of
framework-specific-half-custom-backed-unportable-mess-of-over-engineered-mvc-doom).

Having said that, I like the idea of generalising the "Delegate" interface
into a separate "Handler" one.

This alone would cause a considerable set-back for PSR-15, though, as it
would need to be put on hold while formalising a separate PSR with the due
process. OTOH, as Rasmus noted, this would leave a door open for a
different specification in the future, both for something with not too much
departure from what will eventually be delivered with PSR-15, and something
not even related to middleware at all.

I think allowing for this change, but leaving the overall design as it is
(i.e. the delegate being a runtime dependency), could be a good compromise
between the parts.

I understand where you're coming from, Rasmus, but the current design is
far from being inadequate, and lots of people are already enjoying the
results of implementing it. This probably amounts to something.

Il giorno lun 15 mag 2017 alle ore 12:24 Rasmus Schultz 
ha scritto:

> > I would be glad if we can find a way to improve this, but I also
> understand Beau whan he says he does not want this to be at the expense of
> simplicity
>
> Please don't mix up "simplicity" with "ease of use".
>
> If we proceed with PSR-15 as-is, it's for ease of use, in spite of added
> complexity.
>
> That's the only reason I'm even pursuing this alternative - it's simpler.
>
> Either way, if we can all agree that a general handler-interface should be
> defined first, I'd be happy, because it leaves all doors open, and allows
> PSR-15 to move ahead as-is, without creating any road-blocks for possible
> alternatives in the future.
>
> That is, PSR-15 should not define it's own DelegateInterface - we should
> have a general HandlerInterface instead, which will have a lot more uses,
> not least in the context of the current PSR-15 proposal as-is, where at
> least Dispatchers will be able to implement them, which provides an extra
> degree of high-level abstraction, which is currently missing from that
> proposal.
>
> As said, my first priority at this time is not to block PSR-15, but merely
> to make sure it doesn't create roadblocks down the line.
>
> If PSR-15 went ahead with an identical interface for delegates that is
> incompatible with a general handler-interface, that would be very bad, as
> this will be non-interoperable with other types of handlers.
>
> If we can agree to do something about that, I'd be happy with PSR-15
> proceeding essentially as-is, only with the middleware-interface
> type-hinting the delegate with a general handler-interface, rather than a
> middleware-specific one.
>
> And perhaps with an additional clause that suggests dispatcher
> implementations also implement that interface.
>
> My main priority at this time is to make sure we don't unnecessarily cut
> ourselves off from architectural options in the future.
>
>
> On Mon, May 15, 2017 at 10:06 AM, David Négrier 
> wrote:
>
>> Hey Beau,
>>
>> Thanks a lot for your detailed posts.
>>
>> You understood my idea completely and you are expressing (in better
>> words) exactly what I wanted to suggest. I take my hat of to you.
>>
>> Also, you are 100% right in the critics you make. Indeed, middleware
>> authors would have to write 2 classes (one middleware and one factory). You
>> are also right to state that the factory class is mostly a boilerplate
>> class with a constructor that takes the same arguments as the middleware,
>> except the "next" middleware 

Meeting at PHPDay

[Stefano Torresi]

Hey folks, just a quick reminder that we're gonna hold a little FIG meeting
at the PHPDay in Verona, unconference track, at 14:30 CET.

See you there!

-- 
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/CAFojS1vzVHAedpBg5Ea59QEZ7eO3s3qMNdUCJ4O8U8%2BqSvN%2Bjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

[Stefano Torresi]

>
> @Stefano
> > This is a non issue...
> This is important for a standard, others are adopting to what you do here
> - that's the definition of a standard. Coders sees and copies what you do
> and even use it as an argument when discussing the issue, it's natural for
> this discussion to show up in this forum. Solve the issue by it's root, so
> yes it is an issue...
>

To clarify, what I meant by "non issue" is that this comes down to personal
preference, and the fact that we won't be able to come to a large consensus
on way or the other, makes it un-worthy of more discussion.

CS standards are doomed to be considered "bad" by at least some people,
because they will never make *everyone* happy.

-- 
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/CAFojS1snK-%3D9rzdUxDOgtogkbsYFUEp-90XcyRJk0U0P5VJ9Hw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

[Stefano Torresi]

This is a non issue, please, leave this discussion alone, it has been
settled a long time ago!

Plus, FWIW I recently decided to switch from one convention to another in
every new project I happen to work on, and I comfortably obtained the
suffix-less style by aliasing third party interfaces with a bunch of
`use` statements. Why can't you all do the same?

We have to accept that people will always have different opinions on the
matter, and consensus is *impossible* to achieve.

Consistency with the status-quo is a more valuable thing on the table.

Can we just leave it at that?

Il giorno mar 28 feb 2017 alle ore 19:16 Rivera, John 
ha scritto:

> Hello all,
>
> I’m a new face here, and has been lurking the mailing list with interest.
>
> I decided to de-lurk because this issue has always bothered me, and I’m
> very happy to see that I’m not alone, and that it’s under discussion —
> albeit possibly long over, looking at the dates :(
>
> In my opinion (and many others that I’ve worked with), an interface having
> ‘I’ or ‘Interface in its name is an anti-pattern. This begun, I think, with
> the whole “interface all the things!” design ‘pattern' that was all the
> rage around 2010 — you know, where every single class has an interface,
> even if there would ever be one implementation of said interface. The ‘I’
> prefix (or the ‘Interface’ suffix as we have here) arose because, as Phil
> Karlton famously said, naming things is hard.
>
> But in this situation, it shouldn’t be. If you are hard pressed to think
> up of a name for an interface that does not include ‘I’ or ‘Interface’,
> you’re most likely doing it wrong.
>
> Let’s take the Logger example from below. Let’s imagine that we’re
> implementing a Logger for the first time ever. The first thing that’d come
> to mind when one thinks of logging is probably a file-based log on the
> local filesystem. So we go forth and write up that Logger class, which
> writes to said log file. It all works, we use it all over the code (with a
> composite root and dependency injection, of course) and the stakeholders
> are happy.
>
> But then suddenly, a developer pipes up and says, “files are annoying,
> let’s log to the database!”. Brilliant! So now we want a SQL logger. Being
> good developers, we refactor the Logger class into an interface, and write
> up the FileLogger and SQLLogger implementations.
>
> And what about the rest of the code? That’s right. We only need to update
> the composite root to instantiate a SQLLogger (or a FileLogger) and pass
> that in. The rest of the object graph does not have to be updated — as far
> as it is concerned, the Logger is still the same Logger it’s always been.
> It doesn’t know, nor cares, whether it is an interface or not.
>
> As you can see, naming things should be easy here. The interface should
> tell you what it is, and the implementation should tell you what it does.
> Simple.
>
> Matthieu argued that the name should make the interface the most important
> part — I think it should strive to be the opposite — the name should make
> the interface attribute irrelevant to the object graph.
>
> John
>
> On Feb 28, 2017, at 12:32 PM, Han Hui Teoh  wrote:
>
> It'll be ironic if this passes. Because look at PSR-2 (and the proposed
> PSR-12), they're supposed to standardize coding style and prevent further
> endless arguments.
>
> But then FIG itself cannot / will not stick to that same philosophy? I
> hope not.
>
> On Tuesday, August 16, 2016 at 3:53:26 AM UTC+8, Matthieu Napoli wrote:
>
> Hi all,
>
> This is a 2 weeks discussion before going to a vote.
>
> The "Interface" suffix has been questioned a few times already, I'm
> suggesting we put that up to a vote and avoid future debates. Here are
> relevant threads I could find on the topic:
>
> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>
> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be
> suffixed by Interface"* from
> http://www.php-fig.org/bylaws/psr-naming-conventions/
>
> I do not suggest accepted PSRs are changed.
>
> Please share your reasons to vote FOR or AGAINST the change, let's debate
> for 2 weeks or more, and then let's have a vote to settle this.
>
> Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).
>
> ---
>
> Here are my arguments to vote FOR the change:
>
> *- the Interface suffix makes simple names very long*
>
> For example with PSR-7, here is the signature of a Slim/Zend Expressive
> middleware:
>
> public function __invoke(ServerRequestInterface $request, ResponseInterface 
> $response, callable $next) : ResponseInterface
>
> {
>
> }
>
>
> Compare that to:
>
> public function __invoke(ServerRequest $request, Response $response, callable 
> 

Re: PSR-7 Alternate Proposal

[Stefano Torresi]

John, while I appreciate your passion, I should remind you that this is a
mailing list, not a chat room, so could you please throttle yourself? We
usually try to keep a soft limit of 2 posts per thread per day.

Thanks.

-- 
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/CAFojS1vmx16efx2Ta34_nQy3PxBxUmq-%2BenxDspbsV1DiRvD7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-11 Container Interface

[Stefano Torresi]

Hey folks,

To avoid the usual insurgence of concerns and critiques that only happen
when an acceptance vote starts, and which to be really addressed would
require to first cancel the vote, then push back the spec to draft, then
start reviewing again, I would urge anybody who thinks that the this spec
is not up to par to speak their mind before Friday the 13th! To accomplish
this, I would also suggest to spam this thread all around your favourite
mediums.

That said, I personally think the spec is sound. I'm sure this PSR will be
a huge success, and will set an important precedent regarding
prior-to-acceptance adoption of PSR drafts, paving the road for future WGs.

See you around.

Il giorno lun 9 gen 2017 alle ore 16:46 Chuck Burgess 
ha scritto:

> LGTM from PEAR...
>
> On Dec 31, 2016 14:57, "Matthew Weier O'Phinney" 
> wrote:
>
> Greetings, on this last day of 2016! (For some of you, it's already 2017!)
>
> I'm rebooting the REVIEW period for PSR-11 as of now; review will end
> at 11:59 on 13 January 2017, with the possibility of starting a vote
> under the existing FIG 2.0 by-laws possible immediately thereafter.
>
> The changes since the previous review period started include:
>
> - All exceptions were moved into the `Psr\Container` namespace
> (instead of the `Psr\Container\Exception` namespace as was done
> previously).
>
> - Clarifications were added around inclusion of OPTIONAL parameters to
> the `get()` method by _implementing libraries_, noting that doing so
> is allowed by PHP, but discouraged, due to ambiguity in behavior
> between implementations.
>
> - Added a formal definition of an entry identifier for use with
> `get()` and `has()`, noting that these may be any valid non-empty
> string.
>
> - Removed all verbiage around the delegate lookup feature. Consensus
> was that this is an interesting feature, but something that may be
> implemented by libraries while still following the specification. If
> anybody feels the need to formalize this detail, it can be done in a
> later specification without breaking compatibility with the current
> proposal.
>
> We have also rejected the proposed
> `MisconfiguredServiceExceptionInterface`.  David has previously noted
> reasons not to include it
> (https://groups.google.com/d/msg/php-fig/2pnhudRUpQg/ewoGoNtFCgAJ),
> which received no rebuttal. We feel it does not add value to consumers
> currently, would likely be problematic in terms of performance, and
> dictates too many details around implementation.
>
> Please review the specification again at this time, and let us know as
> soon as possible if you see any potential problems that remain to be
> addressed.
>
> --
> 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 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_myU%2BwCPNbmhdMGztNvzmgrjpO-giGBE8fuuJT4Lj%3DDVVGg%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/CANsgjnuVHjWScCCkuuf5LkT7OHXZAa%3DmvyvRVMB4sC%3DXLOhcVA%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/CAFojS1sZg%2Bvmsj7cB87T%2BBq0n8DtwM91Hs1_U%2BAJhd6PntMykA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: StreamInterface::detach() in PSR-7: what is it for?

[Stefano Torresi]

Hey Rasmus,

The detach() method was introduced to allow a fine grained control over the
underlying resource of the Stream object, and it provides a standardized
way to do that.
You can find more insights in the original discussion here:
https://groups.google.com/d/msg/php-fig/CTPRa2XP8po/kYZnFxl4JjMJ

Admittedly, the metadoc is a bit lacking in this regard.

I think we could amend it with a clarifying errata, couldn't we?

Il giorno gio 29 dic 2016 alle ore 13:25 Rasmus Schultz 
ha scritto:

> The detach() method of StreamInterface in PSR-7 isn't mentioned anywhere
> in the documentation or meta.
>
> The only documentation for it, is the inline documentation, which doesn't
> explain what it's for:
>
> > Separates any underlying resources from the stream.
>
> So basically, this sets the internal resource handle (an implementation
> detail!) to null, right?
>
> > After the stream has been detached, the stream is in an unusable state.
>
> So if I want my stream object in an invalid, unusable state, this is the
> method to call.
>
> Huh?
>
> When would I want that?
>
> Since streams are (primarily) intended as wrappers around PHP
> stream-resource handles, I would have expected that the way to "detach" a
> StreamInterface instance from the native stream-resource handle, is to
> destroy the object - since a StreamInterface-wrapper around a PHP
> stream-resource handle really represents only one thing: the
> resource-handle.
>
> When would "detaching" and leaving the object in an invalid state make
> more sense than simply destroying the object, and thereby the reference to
> the stream-resource handle?
>
> --
> 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/99fd9037-331d-4645-ad0f-c911ae370356%40googlegroups.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/CAFojS1t_Jnm4u__2oQkoj%2B0j6S%2BeAemb14t1Jmm3Dz1Zs2LraQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: First Core Committee Members!

[Stefano Torresi]

Hey list,

I'd like to say I'm very honoured to see my name among a whole lot of
people I've always held in the highest regard since I got involved with the
PHP community.
I honestly didn't expect to gather enough votes, not even close to that, so
I'm quite surprised, but at the same time very excited! I look forward to
work with you folks and I promise I'll give you the very best I can!
I've always strongly believed in this group, even more so now that the FIG
mission has a greater scope than ever. Awesome things have been done so
far, are being done in this very moment, and many more will be done in the
future, I'm sure.

I'd also like to thank everyone who named me in their votes, for giving me
the opportunity, the motivation and the responsibility to be part of this
all. Thank you so much!

I shall now leave you with my best regards, and I wish you all the best
festivities you could possibly want.

Big hug!

Stefano

-- 
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/CAFojS1upKUD-%3Dd2hO1JJsoxSJzLieuBM84bLMeoFSnwnm2P1qA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] First Core Committee Elections

[Stefano Torresi]

   1. Stefano Torresi
   2. Matthew Weier O'Phinney
   3. Sara Golemon
   4. Korvin Szanto
   5. Larry Garfield
   6. Beau Simensen
   7. Gary Hockin
   8. David Négrier
   9. Lukas Kahwe Smith
   10. Cees-Jan Kiewiet
   11. Chris Tankersley
   12. Graham Daniels

-- 
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/CAFojS1t0UvKRhJxz4kuMmbJZ7MfuXjTizD7Xf3_5xoEKLk6f6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12]

[Stefano Torresi]

Il giorno mar 6 dic 2016 alle ore 23:21 Rudolph Gottesheim <
rgotteshei...@gmail.com> ha scritto:

> [...] And when the day comes that we get another widely-used declare(), we
> can still revisit the topic. For the moment, a simple "the strict_types
> declaration goes in the first line, we don't specify what to do with the
> others"
>

I beg to disagree, and I strongly object to this line of thought; PSRs are
meant to last as much as possible, deliberately saying "meh, we'll fix this
later" is not exactly promising.
Regarding Coding Styles in particular, we've been shortsighted already:
PSR-2 has been due to revision for a long time, for ambiguities and
inconsistencies that popped up not long after its acceptance, and redacting
a new standards is taking a long time, as everybody can see.

As Larry stated above, we can already abstract a generic rule regarding all
"declare" statements, keeping things simple and tidy. Introducing a special
case and possible future inconsistencies just for the sake of personal
taste is far from ideal, and hardly worth the hassle of revisiting things
later down the line.

May I also reiterate on the fact that CS recommendations are not about what
people likes, but rather about consistency and cohesion.
If I were to implement a linter and had a rule that enforces to split the
same kind of statement among different places, I'd have "WTF" written all
over my face.

Regards.

-- 
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/CAFojS1vhp2jHSfWe%3DK633aUL%3D77wREy07wPTYDDH%2BF3q3YaFvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Stefano Torresi]

Il giorno mer 16 nov 2016 alle ore 17:19 Jordi Boggiano 
ha scritto:

> This was also carried over from PSR-6 where Pool::save() returns bool.
>
> I am not really sure what's best here, I expect most implementation will
> throw anyway if they can't connect to the cache, and in other instances
> there is no reason a write should fail AFAIK.
>
> Any other opinions on this?
>

I don't see any compelling advantage in the boolean return value and I'd
prefer leaving it out, but there were a few people who argued in favor of
it during PSR-6 review.

As a side note, out of the most downloaded non-PSR-6 libraries listed in
the first pages of Packagist, Zend\Cache and Doctrine\Cache do follow this
convention, while almost every other don't.

-- 
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/CAFojS1sV1YTy5A-rjqq5syGPMbVAcBn1WA-D62BDsgV0yVp3wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC][Nomination] Stefano Torresi

[Stefano Torresi]

Thank you Matteo,

I accept the nomination!

-- 
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/CAFojS1uasYnsWM26fF9C_S85k0%2BEmKbd4AXevRUXnXYO7daOnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Question about PSR-11

[Stefano Torresi]

Il giorno mer 5 ott 2016 alle ore 01:13 Sara Golemon  ha
scritto:

> My $0.02USD is that it should have DI in the name (i.e. DIContainer)
>

100% agree, but I guess this ship has sailed... ;-)

It occurs to my mind that, while most of the development of
container-interop happened outside this list - so FIG members and
bystanders may have not been involved as much as they could - on the other
hand the editors have had the care to post regular updates here, with links
to github, so anybody potentially interested has been given the chance to
chime in.

-- 
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/CAFojS1u6WEqGRr4i91vTSd5ohyMfuieqFySA8GsvPpaKr6NkhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Question about PSR-11

[Stefano Torresi]

Check the meta doc:
https://github.com/php-fig/fig-standards/blob/master/proposed/container-meta.md#3-scope

Il giorno lun 3 ott 2016 alle ore 19:34 Pedro Cordeiro <
pedronar...@gmail.com> ha scritto:

> I tried searching but couldn't find the reason PSR-11 doesn't have a
> `register`, `add` or similar method to register a new service in the
> container.
>
> I'm not sure if I misunderstood something, but it looks like I'll still
> have to create a new contract wrapper around PSR-11 to define how to
> register new services to the container, and then I'll have to make a bridge
> for each provider, since they won't agree on how to add new services.
> Wouldn't it defeat the purpose of this PSR, which is interoperability?
>
> --
> 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/1877a319-8b9e-4150-8048-97e6b43750ce%40googlegroups.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/CAFojS1t%2B%2BFgzpnfsXQLTJw7SJ70PpjJK_2OGsRAR5GSu9wjP%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remove Developer Advocacy Requirement From Secretaries Role

[Stefano Torresi]

Il giorno lun 3 ott 2016 alle ore 18:44 Mark Baker 
ha scritto:

> Not that I'm a voting member, but my $0.02
> Presenting on FIG at conferences/etc has too much potential for being
> asked awkward questions about FIGDrama, putting the secretaries on the
> spot, and which they cannot answer because it's too loaded and political.
> Advocating for the group has benefits, but is also a two-edged sword; and I
> don't believe that it should be a defined part of the role, although I also
> see no reason when Secretaries shouldn't submit to conferences if they are
> prepared to accept the possibility of being asked inappropriate questions
> where they have to "no comment".
>

I beg to differ.

At PHPDay, which happened right in the middle of the "PHPixieGate", the
drama was initially hinted with joking intent, discussed maturely and
briefly, and then quickly and completely dismissed in favor of more
important topics.

We are adults, we can and should be able to talk openly about any issue the
group may have or have had in the past.

Sweeping dust under the carpet is ultimately inconclusive, I would
rather expect
quite the opposite approach.

Advocating for what is being done here, on the contrary, shows that after
all there are passionate people committed to the mission, which is a very
good answer to most of the criticisms the group receives.

-- 
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/CAFojS1tTYLffmAXVfc5td0jg57DBZzOez3JfN9%2BsRGV5ctv4Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remove Developer Advocacy Requirement From Secretaries Role

[Stefano Torresi]

IIRC Samantha also did some related activity not long ago.

I agree that making this a hard requirement doesn't make much sense, as it
cannot be measured exactly whether a given secretary is satisfying it or
not (what kind of advocacy? blog posts? conference talks? in what
frequency? how deep?).

It should be no more than a soft task, encouraged but not strictly
required. If it's done, all the better.

>From a bystander view point, it's a very welcomed activity: PSR consumers
and implementors can relay to the resources resulting from such activities
to further raise awareness, without having to invest time for doing this
themselves over and over again.

Il giorno lun 3 ott 2016 alle ore 17:42 GeeH  ha scritto:

> Hi All,
>
> I created a pull request (
> https://github.com/php-fig/fig-standards/pull/820) to remove the
> requirement for secretaries to be developer advocates for the group. I
> don't see any of the secretaries aside from Michael submitting talks and
> generally advocating for the group, and I don't think it means those
> secretaries are doing a bad job. I personally don't think it should be a
> requirement for the secretary role.
>
> This is a formally discussion thread to gauge opinion and see if it's
> worth moving on to a vote.
>
> Gary
>
> --
> 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/94cc8e8b-8560-47c5-bccb-33aca12c5170%40googlegroups.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/CAFojS1tg99gi8x_J_xss20SfCo8S5-hfzKKBs5urZBQuhmwkRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Stefano Torresi]

As far as I can tell, the problem is that currently the so called
LinkCollectionInterface describes two methods which, as per docblocks,
"return a collection".
So we have something called collection which in turn returns collections;
not ideal.

Calling it "Catalog" doesn't cut it, in my opinion, because the ambiguity
remains: "catalog" can easily be interpreted as a synonym of "collection".
"Collector" doesn't cut it either, because I would expect it to provide
some kind of command (i.e. "collect()"), not queries.

Now I'm not big on naming, but something like LinksProvider or
LinkCollectionProvider would probably communicate the intent more
accurately.

Then again, the presence of EvolevableLinkCollectionInterface makes it even
more unclear whether or not we're talking about something that is-a
collection or has-a collection.
I understand the need for this interfaces, but the current naming is
confusing.
I don't know better, I'll let you folks brainstorm on this.

Cheers.

-- 
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/CAFojS1uzKeaVta0fzLL0fXacmpL1%2Brh5DHjtRVDTpYVfi%3DyBjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: The CLI interface PSR brainstorm

[Stefano Torresi]

Il giorno sab 9 lug 2016 alle ore 14:43 Daniel Plainview <
daniel.pla...@gmail.com> ha scritto:

> > like a generic CommandBus rather than a CLI specific one
> Please, don't mix up things. CommandBus has nothing to do with CLI
> Command.
>

I am very aware of the difference, in fact I was talking about different
proposals, while starting from a baseline abstraction.


> CLI Command is just UI detail exactly like HTTP controllers.
> They are not place for business logic.
> This problem is already known as
> https://en.wikipedia.org/wiki/Magic_pushbutton anti-pattern.
>

This has nothing to do with my suggestion. Again, I was suggesting to start
with a simple interface.
I never suggested conflating commands with business logic, where did you
get that from?


> Thus, it's better to ask sane API (decoupled from UI) from mentioned
> vendors (Doctrine and others) in order to make things
> instead of asking abstract CLI commands.
>

I'm not sure I understand.
All there is to a PSR is a specification document and a set of interfaces.
This *is* about abstractions.

-- 
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/CAFojS1uSzYOdZMdu_OW%3DOKWjqrYLP_kPeK0WCTKNFu%2BthT-qDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.