Re: PSR-17 Explicit Nullable

[Chuck Burgess]

+1
CRB

On Mon, Apr 15, 2024, 07:12 Woody Gilk  wrote:

> As editor of PSR-17, I hereby call a vote to:
>
>1. Change the minimum required version of PHP to 7.1 for PSR-17.
>2. Add explicit nullable types to PSR-17 interfaces.
>3. Tag a new release v1.1.0 of psr/http-factory with changes (1) and
>(2).
>
> The relevant PRs are:
>
> https://github.com/php-fig/fig-standards/pull/1321
> https://github.com/php-fig/http-factory/pull/17
>
> Thank you,
>
> --
> Woody Gilk (he/him)
> https://www.shadowhand.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAGOJM6JNuwYA9Twh-0FJZ7sgQ_kaLCdBUSHMTRLXgb95TSox4Q%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnv9K2dAK_qSgdagU6abL2uG%2BYtQKYOjYy0uN77S6xgqVw%40mail.gmail.com.

Re: Service Provider PSR: rebooting the proposal

[Chuck Burgess]

On Sun, Mar 24, 2024 at 10:31 AM Larry Garfield 
wrote:

> On Sun, Mar 24, 2024, at 1:47 AM, Rasmus Schultz wrote:
> > There's nothing wrong with anything Larry posted.
> >
> > But I already knew all of that would work.
> >
> > The issue is extensions - if you want to change an argument to a
> > service definition, that requires the original service definition, so
> > your extension can change it and return a new one.
> >
> > If you're in Pimple, and you registered the original service using a
> > callback, there is no service definition.
> >
> > How do you get from a function literal to a service definition model
> > instance? You can't.
> >
> > No runtime configured container would be able to provide service
> > definitions as objects, unless the original service definition also
> > came from a standard service provider.
> >
> > Service definitions as data/models are fundamentally incompatible with
> > containers that use native functions.
> >
> > I don't think you can fix that.
> >
> > You could have a service providers PSR without extensions, I suppose.
> > It's a pretty important feature to just omit though. Every container I
> > know of supports extensions.
>
> So... I'm not sure what your point is here?  You are correct, if a service
> is registered with a closure, it limits what an extension could do to it.
> But that's not something a PSR *can* solve.  That's just how the language
> works.
>
> The answer, whether we're talking compiled or runtime container, is for
> the PSR to define services as AST definitions (the structs like we were
> talking about before), and make the extensions manipulate those AST
> definitions.  If a particular container *also* wants to support
> closure-based registration, the PSR wouldn't prevent that, but those would
> then be incompatible with extensions and the container just wouldn't pass
> those to extensions.  That's it's choice to support additional
> functionality beyond what the PSR specifies, and if the language itself
> limits what that functionality can do, um, OK?  Not to sound flippant, but
> that's not our problem.  Is there something I'm missing here?
>
> Another option, of course, is to break up the interface.  Have a
> ServiceProvider interface with one method, an ExtensionProvider interface
> with one method, hell we could even consider a ClosureServiceProvider
> interface if we really really wanted.  Let that be opt-in, but with the
> understanding that it won't be used with extensions.  Individual
> implementations could opt-in to whichever functionality they wanted, and a
> provider that offers only services or only extensions wouldn't need a dummy
> function for the other part.  Even without talking about closures, that
> would probably be a good idea.
>
> --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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/01e63eae-fef3-490a-961a-c95be1ff0fa0%40app.fastmail.com
> .
>


This proposal to build a PSR around this does seem reasonable and widely
usable to me, so it would get a favorable entrance vote from me.  Like
Larry said, if a working group can be convened, the continued technical
aspects of the discussion can continue there.
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuqLGEE5WVfPYHfDoKQR9nBS7iKQmw%2BZyiG21PNtNEJuw%40mail.gmail.com.

[PSR-5] Reviving Working Group

[Chuck Burgess]

This is a request to recharter a Working Group for PSR-5 / PSR - 19.

I specifically need a new Sponsor from the Core Committee.

This is also a call for interested members for the new Working Group.
These individuals have already expressed interest:
* Alexander Makarov
* Ken Guest
* Jaap van Otterdijk

CRB
*about.me/ashnazg *

-- 
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/CANsgjnv06VhC4bZrWHSo2o4LjnDD593TgaU7VP-C0mEAJMmFug%40mail.gmail.com.

Re: [Internals][ELECTIONS] Request for Nominations

[Chuck Burgess]

Ken, do you accept?
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Fri, Feb 9, 2024 at 8:34 AM Chuck Burgess  wrote:

> I'll renominate Ken.
> CRB
>
> On Fri, Feb 9, 2024, 07:57 Ken Guest  wrote:
>
>> I would like to serve another term as a member of the Core Committee, so
>> I am seeking a renomination.
>>
>> Thanks
>>
>> Ken
>>
>> On Fri, 9 Feb 2024 at 13:05, Mark Niebergall 
>> wrote:
>>
>>> My apologies all, I have a typo in the date for elections ending.
>>>
>>> On Thursday, February 8, 2024 at 5:19:21 PM UTC-7 Mark Niebergall wrote:
>>>
>>> Hello Everyone,
>>>
>>> It is a little late, but it is election time again. To make up for some
>>> time, we are immediately opening the nominations.
>>>
>>> The following 4 Core Committee seats are up for election: Chris
>>> Tankersley, Korvin Szanto, Enrico Zimuel, and Ken Guest.
>>>
>>> There is also 1 Secretary position up for election: Steve Winter.
>>>
>>> Those with seats expiring may express their intention to run again for
>>> election. Anyone else is also welcome to seek a nomination to be included
>>> in the election.
>>>
>>> Nominations will be open until 2024-02-16 00:00 UTC, at which time the
>>> election will start. Elections will run for two weeks, ending 2024-01-01
>>> 00:00 UTC.
>>>
>>>
>>>  Elections will run for two weeks, ending 2024-03-01 00:00 UTC (not
>>> 2024-01-01, which has already passed).
>>>
>>>
>>>
>>> Feel free to reach out to the other two secretaries (Alessandro and
>>> Mark), or any other sitting PHP-FIG member, to ask for a nomination or for
>>> further information.
>>>
>>> *FAQ:*
>>>
>>> Q: Who can be nominated?
>>> A: Anyone! The secretaries of the PHP-FIG are basically administrative
>>> clerks and community handlers. For more details, see
>>> https://www.php-fig.org/bylaws/mission-and-structure/#secretaries
>>> The CC members of the PHP-FIG are basically the technical steering
>>> committee; citing the bylaw:
>>> https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee
>>>
>>> Q: Who can nominate?
>>> A: Citing the bylaw: "Candidates for Secretary or the Core Committee
>>> must be nominated/proposed by an existing Project Representative or FIG
>>> Secretary to be considered, and must publicly accept their nomination in
>>> order to be valid. Prospective candidates may seek nominations in any way
>>> they see fit."
>>>
>>> For full election bylaws, please see the PHP-FIG bylaws:
>>> https://www.php-fig.org/bylaws/elections-and-vacancies/
>>>
>>>
>>> Thanks,
>>>
>>> Mark Niebergall
>>> PHP-FIG Secretary
>>>
>>> --
>>> 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/17464186-b8c2-45eb-8c45-7a57b72a3a6an%40googlegroups.com
>>> <https://groups.google.com/d/msgid/php-fig/17464186-b8c2-45eb-8c45-7a57b72a3a6an%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> http://about.me/kenguest/
>>
>> --
>> 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/CAKcc2m8%2BTR1BsAfwvV3rKErjbtjVU8PNvhhomR9XCKeEDtnRkw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/php-fig/CAKcc2m8%2BTR1BsAfwvV3rKErjbtjVU8PNvhhomR9XCKeEDtnRkw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CANsgjnv75K%2BiMfW%2BNHcyBx9srMaGQpn76LoxYakp%2BPuhKF7atg%40mail.gmail.com.

Re: [Internals][ELECTIONS] Request for Nominations

[Chuck Burgess]

I'll renominate Ken.
CRB

On Fri, Feb 9, 2024, 07:57 Ken Guest  wrote:

> I would like to serve another term as a member of the Core Committee, so I
> am seeking a renomination.
>
> Thanks
>
> Ken
>
> On Fri, 9 Feb 2024 at 13:05, Mark Niebergall 
> wrote:
>
>> My apologies all, I have a typo in the date for elections ending.
>>
>> On Thursday, February 8, 2024 at 5:19:21 PM UTC-7 Mark Niebergall wrote:
>>
>> Hello Everyone,
>>
>> It is a little late, but it is election time again. To make up for some
>> time, we are immediately opening the nominations.
>>
>> The following 4 Core Committee seats are up for election: Chris
>> Tankersley, Korvin Szanto, Enrico Zimuel, and Ken Guest.
>>
>> There is also 1 Secretary position up for election: Steve Winter.
>>
>> Those with seats expiring may express their intention to run again for
>> election. Anyone else is also welcome to seek a nomination to be included
>> in the election.
>>
>> Nominations will be open until 2024-02-16 00:00 UTC, at which time the
>> election will start. Elections will run for two weeks, ending 2024-01-01
>> 00:00 UTC.
>>
>>
>>  Elections will run for two weeks, ending 2024-03-01 00:00 UTC (not
>> 2024-01-01, which has already passed).
>>
>>
>>
>> Feel free to reach out to the other two secretaries (Alessandro and
>> Mark), or any other sitting PHP-FIG member, to ask for a nomination or for
>> further information.
>>
>> *FAQ:*
>>
>> Q: Who can be nominated?
>> A: Anyone! The secretaries of the PHP-FIG are basically administrative
>> clerks and community handlers. For more details, see
>> https://www.php-fig.org/bylaws/mission-and-structure/#secretaries
>> The CC members of the PHP-FIG are basically the technical steering
>> committee; citing the bylaw:
>> https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee
>>
>> Q: Who can nominate?
>> A: Citing the bylaw: "Candidates for Secretary or the Core Committee must
>> be nominated/proposed by an existing Project Representative or FIG
>> Secretary to be considered, and must publicly accept their nomination in
>> order to be valid. Prospective candidates may seek nominations in any way
>> they see fit."
>>
>> For full election bylaws, please see the PHP-FIG bylaws:
>> https://www.php-fig.org/bylaws/elections-and-vacancies/
>>
>>
>> Thanks,
>>
>> Mark Niebergall
>> PHP-FIG Secretary
>>
>> --
>> 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/17464186-b8c2-45eb-8c45-7a57b72a3a6an%40googlegroups.com
>> 
>> .
>>
>
>
> --
> http://about.me/kenguest/
>
> --
> 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/CAKcc2m8%2BTR1BsAfwvV3rKErjbtjVU8PNvhhomR9XCKeEDtnRkw%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntF7zi3n0Vtyo%2BaJ0%3DES36vEKMf7Mr6%3DdQ9HLpN2utGvA%40mail.gmail.com.

Re: [VOTE][CC] Expulsion Vote for eZ Systems

[Chuck Burgess]

+1
CRB

On Thu, Oct 5, 2023, 09:43 Vincent de Lau  wrote:

> +1, unfortunate indeed.
>
> On Thursday, October 5, 2023 at 4:39:26 PM UTC+2 Navarr Barnier wrote:
>
>> +1.  An unfortunate necessity.
>>
>> On Thursday, October 5, 2023 at 10:37:39 AM UTC-4 Vincent de Lau wrote:
>>
>>> This thread is to collect Core Committee votes on the eZ Systems
>>> Expulsion vote.
>>>
>>> The proposal is to expel eZ Systems as a Member Project.
>>>
>>> There have been various efforts to prevent this drastic measure, without
>>> any result. The final discussion thread with the background leading to this
>>> proposal can be found here:
>>> https://groups.google.com/g/php-fig/c/zYvUOTH-y3I
>>>
>>> Voting ends by 2023-10-19 17:00 UTC
>>>
>>> Voting options:  For (+1), Against (-1), or Abstain (+0)
>>> Quorum: 50%
>>> Majority: 50%
>>> https://www.php-fig.org/bylaws/voting-protocol/#expulsion-vote
>>>
>>> ONLY CORE COMMITTEE MEMBERS CAN VOTE HERE
>>
>> --
> 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/646d82cc-9340-4d42-8276-4eb1fa180ebbn%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntbf_kfah683vvvPNr8ZOLO0Y9jOD12y9hLHZvYq8C7-g%40mail.gmail.com.

Re: [VOTE][CC] Expulsion Vote for Stormpath PHP SDK

[Chuck Burgess]

+1
CRB

On Thu, Oct 5, 2023, 09:43 Vincent de Lau  wrote:

> +1, unfortunate indeed.
>
> On Thursday, October 5, 2023 at 4:39:31 PM UTC+2 Navarr Barnier wrote:
>
>> +1.  An unfortunate necessity.
>>
>> On Thursday, October 5, 2023 at 10:38:37 AM UTC-4 Vincent de Lau wrote:
>>
>>> This thread is to collect Core Committee votes on the Stormpath PHP SDK
>>> Expulsion vote.
>>>
>>> The proposal is to expel Stormpath PHP SDK as a Member Project.
>>>
>>> There have been various efforts to prevent this drastic measure, without
>>> any result. The final discussion thread with the background leading to this
>>> proposal can be found here:
>>> https://groups.google.com/g/php-fig/c/zYvUOTH-y3I
>>>
>>> Voting ends by 2023-10-19 17:00 UTC
>>>
>>> Voting options:  For (+1), Against (-1), or Abstain (+0)
>>> Quorum: 50%
>>> Majority: 50%
>>> https://www.php-fig.org/bylaws/voting-protocol/#expulsion-vote
>>>
>>> ONLY CORE COMMITTEE MEMBERS CAN VOTE HERE
>>
>> --
> 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/0fbe60d8-dd66-4eeb-a128-fd930bcc5efan%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuunaGdMfcxyV0K3gsiDgnoTdogmLivb_46WjTbQobo%2BQ%40mail.gmail.com.

Re: [VOTE][CC] New bylaw: funding

[Chuck Burgess]

+1
CRB

On Thu, Aug 31, 2023, 03:07 Alessandro Lai 
wrote:

> This is the voting thread dedicated to Core Committee members only.
>
> I'm proposing a new bylaw do handle funding and fiscal representation of
> the PHP-FIG.
>
> The discussion thread can be found here:
> https://groups.google.com/g/php-fig/c/6uC3hjL0Nig
> Further discussion and the full text of the bylaw can be found in this PR:
> https://github.com/php-fig/fig-standards/pull/1295
>
> Per voting protocol: https://www.php-fig.org/bylaws/voting-protocol/
>
>- Voting options are For (+1), Against (-1), or Abstain (+0)
>- Quorum is 50%, a 2/3 majority is required for passage.
>- Voting ends in two weeks, 2023-09-14 17:00:00 UTC
>
> --
> 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/6661ea7f-22ba-4c2e-97dd-f0a97ee73ff7n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnu8GBT7ujkPKrFQAxj2_yPVmihVThQWhhB%3Dqhu1S6UyOQ%40mail.gmail.com.

Re: [VOTE][CC] Hyperf Membership vote

[Chuck Burgess]

+1
CRB


On Mon, Jul 24, 2023, 04:14 Vincent de Lau  wrote:

> This thread is to collect Core Committee votes on the Hyperf Membership
> vote.
>
> The proposal is to accept Hyperf as a Member Project. Hyperf will be
> represented by Leo Cavalcante. The membership application is being
> sponsored by Vincent de Lau as a Core Committee member.
>
> The membership application and discussion thread can be found here:
> https://groups.google.com/g/php-fig/c/zwsMt9E6wzw
>
> Voting ends by 2023-08-07 10:00 UTC
>
> Voting options:  For (+1), Against (-1), or Abstain (+0)
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#membership-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE HERE
>
> --
> 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/6e06dcbc-e9af-4f65-a59a-a29e20451eb4n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjns-ASP31e3jQT0LJ1sY4YWnNy%3DpG9D1g3d_pwHDexoi9Q%40mail.gmail.com.

Re: [VOTE][CC] Copyright Ownership Approval Vote

[Chuck Burgess]

+1
CRB
*about.me/ashnazg *


On Sat, Jul 15, 2023 at 5:49 AM Jaap van Otterdijk  wrote:

> +1
>
> Jaapio
> Op 14 jul. 2023, om 18:48, Vincent de Lau  schreef:
>>
>> +1
>>
>> Kind regards,
>> Vincent de Lau
>>
>> On Friday, July 14, 2023 at 6:45:01 PM UTC+2 Navarr Barnier wrote:
>>
>>> +1
>>>
>>> On Friday, July 14, 2023 at 12:36:35 PM UTC-4 Larry Garfield wrote:
>>>
 +1

 --
 Larry Garfield
 la...@garfieldtech.com

 On Fri, Jul 14, 2023, at 4:24 PM, Mark Niebergall wrote:
 > Hi Everyone,
 >
 > I'm calling a CC vote for the approval of the Copyright Ownership
 > updates. This change adds a "Copyright Ownership" section to the
 > Licensing Policies section
 > (https://www.php-fig.org/bylaws/licensing-policies/). The associated
 PR
 > is: https://github.com/php-fig/fig-standards/pull/1290
 >
 > Approval Voting rules apply
 > (https://www.php-fig.org/bylaws/voting-protocol/#vote-types):
 > • Only Core Committee members may vote, either For (+1), Against
 (-1),
 > or Abstain (+0). Quorum is 50%. A 2/3 majority is required for
 passage.
 > Voting will be open for two weeks (until 2023-07-28 16:30:00 UTC) or
 > until all quorum members have voted, whichever occurs first. If the
 > vote passes, the PR will be merged and the Licensing Policies will be
 > updated on the website.
 >
 > - Mark Niebergall
 >
 >
 > --
 > 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+u...@googlegroups.com.
 > To view this discussion on the web visit
 >
 https://groups.google.com/d/msgid/php-fig/bac05ee7-803a-444d-949f-43443a6e0b51n%40googlegroups.com
 > <
 https://groups.google.com/d/msgid/php-fig/bac05ee7-803a-444d-949f-43443a6e0b51n%40googlegroups.com?utm_medium=email_source=footer>.


>>> --
> 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/6389df02-09cd-43c5-9f15-fff627698135%40ijaap.nl
> 
> .
>

-- 
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/CANsgjnuk86z40ag0ECMaw3usxENZTw8kKOYdha_UFwWkvh6W-A%40mail.gmail.com.

Re: [VOTE][CC][PSR-7] Errata proposal, urlencoding clarification

[Chuck Burgess]

+1
CRB

On Wed, Jun 14, 2023, 09:47 Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> +1 from me
>
> On Wed, Jun 14, 2023, 9:01 AM Matthew Weier O'Phinney <
> mweierophin...@gmail.com> wrote:
>
>> In https://github.com/php-fig/fig-standards/pull/1298, David Buchmann
>> proposed errata regarding expectations around URL encoding behavior of the
>> authority segment, as well as expectations to prevent double encoding. The
>> discussion period resulted in a few verbiage changes to improve clarity.
>>
>> As such, I am now initiating the vote. This vote is for core committee
>> members only. CC members, please vote in the thread following. The vote
>> will be complete two weeks from today.
>>
>> --
>> Matthew Weier O'Phinney
>> mweierophin...@gmail.com
>> https://mwop.net/
>> he/him
>>
> --
> 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/CAJp_myVYYUf73KyCPgq__3wt7Mj2Ww2NsLacn%2B32TpOshvYjQg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntfPd6GN%3DthTSOho6Xf6xFJuWeuhRABsDH7hZxx-DAtqg%40mail.gmail.com.

Re: [VOTE][CC] Coding Style 2.0.0 Approval Vote

[Chuck Burgess]

+1
CRB
*about.me/ashnazg *


On Tue, Mar 21, 2023 at 11:44 AM Alessandro Chitolina 
wrote:

> +1
> Il giorno lunedì 20 marzo 2023 alle 17:31:09 UTC+1 Ken Guest ha scritto:
>
>> +1
>>
>> On Monday, March 20, 2023 at 4:18:55 PM UTC Navarr Barnier wrote:
>>
>>> +1
>>>
>>> On Monday, March 20, 2023 at 12:18:32 PM UTC-4 Chris Tankersley wrote:
>>>
 +1

 On Mon, Mar 20, 2023 at 12:17 PM Korvin Szanto 
 wrote:

> +1
>
> On Mon, Mar 20, 2023, 12:17 PM Larry Garfield 
> wrote:
>
>> +1
>>
>> --
>>   Larry Garfield
>>   la...@garfieldtech.com
>>
>> On Mon, Mar 20, 2023, at 11:05 AM, Korvin Szanto wrote:
>> > Hi Everyone,
>> > The `2.0.0` version of the Coding Style PER has been approved by its
>> > working group. This update introduces requirements for new PHP
>> syntax
>> > and offers clarification on existing syntax such as trailing commas,
>> > empty spaces in function and class bodies, new keywords, named
>> > arguments, match expressions, short closures, enums, attributes, and
>> > more.
>> >
>> > You can review the full list of changes here:
>> > https://github.com/php-fig/per-coding-style/compare/1.0.0...0e0fc1d
>> >
>> > This is an approval vote limited to the Core Committee. A 50% quorum
>> > and a 2/3 majority are required for this vote to pass. If successful
>> > `0e0fc1d` will be tagged as `2.0.0`.
>> >
>> > Thanks,
>> > Korvin
>> >
>> > --
>> > 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+u...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/php-fig/CANeXGWW7VPwak_u84%3DyTiGW5MywencSrkYqD_M1WOd3gAoM_BA%40mail.gmail.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+u...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/d5043493-e5e8-4f01-b1b9-6594dc2bb89e%40app.fastmail.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+u...@googlegroups.com.
>
 To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CANeXGWWrn69qcAW9a7Ui3unE4caeBWZqBqY%2BN_--o2LJuhO0Nw%40mail.gmail.com
> 
> .
>
 --
 Chris Tankersley
 http://ctankersley.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/62d06349-1fa5-4226-a592-d8e44872d761n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnsufFNLW5aDRrwxFvrWs3EEDrG0zVmADNPskGcvQj83rQ%40mail.gmail.com.

Re: [VOTE][PSR-7] Type declaration updates

[Chuck Burgess]

+1
CRB

On Mon, Mar 13, 2023, 15:03 Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> As the two week comment period has concluded, I hereby call a vote of the
> Core Committee to approve the following PRs to update PSR-7 to add explicit
> type declarations.
>
> This is a Core Committee vote requiring a 50% quorum and 2/3 majority,
> with voting ending on 30 March 2023.
>
>
>- Version 1.1 patch (parameter type declarations):
>https://github.com/php-fig/http-message/pull/94
>- Version 2.0 patch (return type declarations):
>https://github.com/php-fig/http-message/pull/95
>- Specification errata patch:
>https://github.com/php-fig/fig-standards/pull/1296
>
> --
> 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/d84ebc94-ee4e-4928-aceb-10563b25a163n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntcHCq-AxqPm-Nmy%2Bwb_NvMbtpb9s_fksV2LyDXL%3DU%2BBQ%40mail.gmail.com.

Re: [ACCEPTANCE VOTE][CC] PSR-20 Clock Interface

[Chuck Burgess]

Voting closed November 18th, with these results:

Voting +1:
Matthew Weier O’Phinney
Chuck Burgess
Michelle Sanver
Alessandro Chitolina
Ken Guest
Jaap van Otterdijk
Navarr Barnier

Not voting:
Larry Garfield
Cees-Jan Kiewiet
Chris Tankersley
Korvin Szanto
Enrico Zimuel

With 50% quorum met (7/12) and 2/3 threshold met (+7/-0), the vote passes.
Secretaries, please designate PSR-20 as accepted.  The Working Group is
hereby dissolved, with Chris Seufert as the PSR-20 Editor going forward
(unless he wishes to designate an alternate).

CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Thu, Nov 3, 2022 at 1:47 PM Chuck Burgess  wrote:

> I am opening an ACCEPTANCE VOTE for PSR-20, the Clock Interface. Per the
> by-laws, the  acceptance vote is limited to Core Committee members. The
> vote will close either at 23:59:59 UTC on 18 November 2022, or when all
> CC members have cast their vote, whichever comes first.
>
> - Specification:
> https://github.com/php-fig/fig-standards/blob/master/proposed/clock.md
> <https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md>
>
> - Meta document:
> https://github.com/php-fig/fig-standards/blob/master/proposed/clock-meta.md
> <https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md>
>
>
> Trial Implementations:
> - https://packagist.org/packages/welearn/clock
> - https://packagist.org/packages/org_heigl/clock
>
> Real-life implementations waiting for PSR-20 to be ready:
> - https://packagist.org/packages/lcobucci/clock
> - https://packagist.org/packages/kreait/clock
> - https://packagist.org/packages/beste/clock
>
> PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
> Current CC Members are as follows:
>
> Larry Garfield
> Matthew Weier O’Phinney
> Cees-Jan Kiewiet
> Chris Tankersley
> Korvin Szanto
> Chuck Burgess
> Enrico Zimuel
> Michelle Sanver
> Alessandro Chitolina
> Ken Guest
> Jaap van Otterdijk
> Navarr Barnier
>
>
> Chuck Burgess, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuyr2rxs3VL57dOJWBNFxTM3YxPAM3DgHy0nuOZ6D2TbQ%40mail.gmail.com.

Re: [ACCEPTANCE VOTE][CC] PSR-20 Clock Interface

[Chuck Burgess]

+1
CRB

On Thu, Nov 3, 2022, 13:47 Chuck Burgess  wrote:

> I am opening an ACCEPTANCE VOTE for PSR-20, the Clock Interface. Per the
> by-laws, the  acceptance vote is limited to Core Committee members. The
> vote will close either at 23:59:59 UTC on 18 November 2022, or when all
> CC members have cast their vote, whichever comes first.
>
> - Specification:
> https://github.com/php-fig/fig-standards/blob/master/proposed/clock.md
> <https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md>
>
> - Meta document:
> https://github.com/php-fig/fig-standards/blob/master/proposed/clock-meta.md
> <https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md>
>
>
> Trial Implementations:
> - https://packagist.org/packages/welearn/clock
> - https://packagist.org/packages/org_heigl/clock
>
> Real-life implementations waiting for PSR-20 to be ready:
> - https://packagist.org/packages/lcobucci/clock
> - https://packagist.org/packages/kreait/clock
> - https://packagist.org/packages/beste/clock
>
> PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
> Current CC Members are as follows:
>
> Larry Garfield
> Matthew Weier O’Phinney
> Cees-Jan Kiewiet
> Chris Tankersley
> Korvin Szanto
> Chuck Burgess
> Enrico Zimuel
> Michelle Sanver
> Alessandro Chitolina
> Ken Guest
> Jaap van Otterdijk
> Navarr Barnier
>
>
> Chuck Burgess, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuhcNPLJkoYzVN8578%2ByGq820G7fBUYt3Hc8i4N-JrN_w%40mail.gmail.com.

[ACCEPTANCE VOTE][CC] PSR-20 Clock Interface

[Chuck Burgess]

I am opening an ACCEPTANCE VOTE for PSR-20, the Clock Interface. Per the
by-laws, the  acceptance vote is limited to Core Committee members.
The vote will
close either at 23:59:59 UTC on 18 November 2022, or when all CC members
have cast their vote, whichever comes first.

- Specification:
https://github.com/php-fig/fig-standards/blob/master/proposed/clock.md
<https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md>

- Meta document:
https://github.com/php-fig/fig-standards/blob/master/proposed/clock-meta.md
<https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md>


Trial Implementations:
- https://packagist.org/packages/welearn/clock
- https://packagist.org/packages/org_heigl/clock

Real-life implementations waiting for PSR-20 to be ready:
- https://packagist.org/packages/lcobucci/clock
- https://packagist.org/packages/kreait/clock
- https://packagist.org/packages/beste/clock

PLEASE DO NOT VOTE UNLESS YOU ARE A CC MEMBER.
Current CC Members are as follows:

Larry Garfield
Matthew Weier O’Phinney
Cees-Jan Kiewiet
Chris Tankersley
Korvin Szanto
Chuck Burgess
Enrico Zimuel
Michelle Sanver
Alessandro Chitolina
Ken Guest
Jaap van Otterdijk
Navarr Barnier


Chuck Burgess, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjns_yQx8ma-OK1Jc%3D5Jt9_8eqe7UBeAn%2B0VRKwNX8aj7jg%40mail.gmail.com.

Re: [Vote][PSR-20] Readiness Vote

[Chuck Burgess]

+1
CRB


On Sun, Aug 21, 2022, 19:17 Chris Seufert  wrote:

> As Editor of PSR-20, I hereby call a Readiness Vote for PSR-20, "Clock
> Interface".
>
> This vote is for members of the PSR-20 Working Group only, who are:
>
> Luís Cobucci
> Pol Dellaiera
> Ben Edmunds
> Jérôme Gamez
> Andreas Heigl
> Andreas Möller
>
> If you are not one of those people, please do not vote on this thread.
>
> The spec to be voted on is here:
> https://github.com/php-fig/fig-standards/blob/master/proposed/clock.md
> https://github.com/php-fig/fig-standards/blob/master/proposed/clock-meta.md
>
> Additionally, a Composer package with the spec-defined interfaces is here:
> https://github.com/php-fig/clock
>
> The following implementations as a demonstration of the viability of the
> specification:
> https://packagist.org/providers/psr/clock-implementation
>
> The vote will remain open for 2 weeks ending on September 5th or until
> all 6 WG
> members have voted, whichever comes first. If it meets a 2/3 majority, the
> spec will go to the Core Committee for Review, moderated by our Sponsor,
> Chuck Burgess. It will be eligible for an Acceptance Vote one month from
> that date.
>
> Chris Seufert
> PSR-20 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAN1g4Sz1RyU5gDOMQ8VCZ4oaFeZ8iy8wiP82nTLUGO2Yr8Futg%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAN1g4Sz1RyU5gDOMQ8VCZ4oaFeZ8iy8wiP82nTLUGO2Yr8Futg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANsgjnuos%2Bb11dctJW06b5OtCA_NbnMN%2Bt%2Bw_RKL--SH%3DaLnRw%40mail.gmail.com.

Re: [VOTE][CC] fig/log-test 1.0.0 Approval Vote

[Chuck Burgess]

+1
CRB

On Fri, Aug 19, 2022, 01:17 Ralf Lang  wrote:

> Hello everyone,
>
>
> I hereby call a CC vote for the approval of the first release 1.0.0 of
> auxiliary resource fig/log-test.
>
> The library is a direct port of existing repo psr/log-util (unreleased)
> which has been in the current form for long but has naming issues. You can
> view it as-is here: https://github.com/php-fig/log-test/ - Direct editing
> was the exception.
> Further evolution will be handled as PRs with the appropriate process.
>
> As per the bylaws I understand this is an Approval vote and it requires
> 2/3 approval/yes of voting CC Members, voting quorum 50%.
>
> Mission and Structure
>
>- Auxiliary Resources (ARs) are additional tools, code libraries, or
>examples that relate to or support a PSR or PER. Examples include common
>partial implementations of a PSR or PER, "no-op" implementations, or
>testing utilities for PSR or PER implementations. All ARs must directly
>relate to one or more PSRs or PERs. An AR is developed by a Maintainer.
>- For changes that would qualify as major releases, the release is
>subject to a mandatory Approval Vote from the Core Committee.
>
> Voting Protocol
>
>- Only Core Committee members may vote, either For (+1), Against (-1),
>or Abstain (+0). Quorum is 50%. A 2/3 majority is required for passage.
>
> Votes take place over a period of two weeks (or at the reaching of 100%
> quorum), so votes will be accepted up to 2022-09-02 11:00:00 UTC.
>
>
> Regards
>
> Ralf Lang
>
> --
> 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/23ffedad-e087-f10c-da66-d7f95c61e26e%40gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuwF122ML%3DsLgVEWYc_yzZBiXmAU3s2N45xxDmgEUFepA%40mail.gmail.com.

[Nomination][CC] Jaap van Otterdijk

[Chuck Burgess]

I nominate Jaap van Otterdijk for the role of CC member.  He is a developer
at Ingewikkeld and on the phpDocumentor core team.

Chuck Burgess
Core Committee member

-- 
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/CANsgjnsA69HxkA2k92jummkssm-dhjeCmWkhFk9dbvS%3DU3kXSg%40mail.gmail.com.

Re: PSR-20 Clock status

[Chuck Burgess]

Chris,
If you'll send me (my handle at php.net) your email address, I can send you
the readiness vote draft.  You can then send it out officially as Editor.

Working Group,
If you can check in on the Discord channel, maybe we can get this effort
going again.

CRB

On Thu, Aug 4, 2022, 13:11 Chuck Burgess  wrote:

> Given no further discussion, I'm trying to reach the Editor via Github and
> Discord (and here, if you see this, Chris Seufert) to get his ok on a
> readiness vote.
> CRB
>
> On Sat, Jul 23, 2022, 11:36 Chuck Burgess  wrote:
>
>> On the timezone being undefined... the UNIX timestamp integer returned by
>> DateTimeImmutable->getTimestamp() gives a reliably unique value for an
>> instant in time, and the only effect a timezone has on that value is a
>> format string you can retrieve based on that integer timestamp, right?  So
>> it's not that you have an ambiguous value in hand... it's just that the
>> interface doesn't demand it present its "string value" in a single way...
>> right?
>> CRB
>> *about.me/ashnazg <http://about.me/ashnazg>*
>>
>>
>> On Sat, Jul 23, 2022 at 11:00 AM Chuck Burgess 
>> wrote:
>>
>>> My rewording PR for the timezone FAQ section is up, in case you want to
>>> review it.  I did not expand on any ideas already there... just tried to
>>> tighten up the phrasing.
>>> CRB
>>> *about.me/ashnazg <http://about.me/ashnazg>*
>>>
>>>
>>> On Wed, Jul 20, 2022 at 8:49 AM Larry Garfield 
>>> wrote:
>>>
>>>> Great.  When last I looked at it, I still had concerns around the UTC
>>>> question. "Undefined behavior" bothers me, and even with the added text I
>>>> wasn't fully convinced that leaving the timezone undefined was the right
>>>> call.  Other than that it seemed fine to me.
>>>>
>>>> --
>>>>   Larry Garfield
>>>>   la...@garfieldtech.com
>>>>
>>>> On Tue, Jul 19, 2022, at 5:25 PM, Chuck Burgess wrote:
>>>> > After the progress Chris and I made since Sunday, I want to do one
>>>> more
>>>> > read-over, possibly a wording PR... and then see if he as Editor is
>>>> > ready for the next formal step.
>>>> > CRB
>>>> >
>>>> > On Tue, Jul 19, 2022, 17:18 Larry Garfield 
>>>> wrote:
>>>> >> What's the verdict here?
>>>> >>
>>>> >> --
>>>> >>   Larry Garfield
>>>> >>   la...@garfieldtech.com
>>>> >>
>>>> >> On Tue, Jul 5, 2022, at 6:30 AM, Chuck Burgess wrote:
>>>> >> > Sorry folks... if there was another email thread on this trying to
>>>> move
>>>> >> > it along, I somehow missed it... and if Discord was deemed the
>>>> official
>>>> >> > replacement to replace the email group for such communications, I
>>>> must
>>>> >> > have missed it too... I haven't had enough space in my office area
>>>> to
>>>> >> > keep my OSS laptop open 24x7 like I used to do.
>>>> >> >
>>>> >> > I'll catch things up in the next week or so... I have something
>>>> going
>>>> >> > on late this week that will get in the way, which is why I think
>>>> it
>>>> >> > could take me into next week to catch things up.
>>>> >> > CRB
>>>> >> >
>>>> >> > On Tue, Jul 5, 2022, 03:58 Andreas Heigl 
>>>> wrote:
>>>> >> >>
>>>> >> >>
>>>> >> >> On 05.07.22 10:17, Alessandro Lai wrote:
>>>> >> >> > What's the status on the spec? IIRC is basically complete,
>>>> right? We just
>>>> >> >> > need to push it to the approval vote...
>>>> >> >>
>>>> >> >> There are still unresolved PRs regarding timezone issues.
>>>> >> >>
>>>> >> >> The spec is in the same state as it was almost a year ago. Since
>>>> then I
>>>> >> >> have tried at least twice to get it towards an approval vote but
>>>> neither
>>>> >> >> the sponsor or the editor were responding nor was the CC taking
>>>> any actions.
>>>> >> >>
>>>> >> >> In at least the last try from my s

Re: [Nomination][CC] Chuck Burgess

[Chuck Burgess]

I accept... thanks Vincent.
CRB

On Mon, Aug 8, 2022, 04:44 Vincent de Lau  wrote:

> Hi all,
>
> Hereby I nominate Chuck Burgess for the role of CC member.
>
> --
> Kind Regards,
> Vincent de Lau
> PHP-FIG Secretary
>
>
> --
> 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/c1eb04e1-d4f8-478a-afe2-83b2ddaf3fddn%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/c1eb04e1-d4f8-478a-afe2-83b2ddaf3fddn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANsgjntfykso%2BF%2BMZqsLzerBWSVb1RdFmdE-yVUBMB_%3DxAoSNg%40mail.gmail.com.

Re: Rename php-fig/log-util into php-fig/log-util-test

[Chuck Burgess]

On Wed, Aug 3, 2022, 10:12 Ralf Lang  wrote:

>
> Am 03.08.2022 um 16:55 schrieb Larry Garfield:
> > On Wed, Aug 3, 2022, at 6:56 AM, Vincent de Lau wrote:
> >> The bylaws are not very clear on this, but I would think an Implicit
> >> Approval would be sufficient here. My interpretation would be that a
> >> 1.0.0 release would require an Approval Vote, so there is enough room
> >> to intervene before publishing a 1.0.0 release.
> >>
> >> While on the subject of renaming, it seems to me that this package
> >> should use the vendor `fig` instead of `psr`. Similarly, it should use
> >> the `Fig` namespace instead the `Psr`. See
> >> https://www.php-fig.org/bylaws/psr-naming-conventions/. If you feel
> >> there is sufficient reason to keep these, I would think it would be
> >> wise to seek Implicit Approval as well, or leave it to the Approval
> >> Vote.
> >>
> >> Regards,
> >> Vincent de Lau
> >> PHP-FIG Secretary
> > Uitl packages and any other aux resources are required to use a Fig
> namespace:
> >
> > https://www.php-fig.org/bylaws/psr-naming-conventions/
> >
> > No vote needed, that's just what is required.
> >
> > Since this is a test-only package, I'd probably say log-test rather than
> log-util-test, but that's not a hill I'd die on.  I am also OK with
> Implicit Approval.  (So, I guess this is automatically approved unless
> someone from the CC asks for a vote within the next week.)
> >
> > --Larry Garfield
>
> I'm fine with either fig/log-util-test or fig/log-test. The latter is
> shorter but still descriptive.
>
> So after the waiting threshold we would need somebody with sufficient
> access to the github organisation to rename the package - I can do the
> composer metadata changes as required asap afterwards.
>

+1 for fig/log-test...
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnvFi34gBMrb2OC14RT0yrY7p-u3E%3DBJYuuTE9c%3D_G5LAg%40mail.gmail.com.

Re: [Internal][ELECTIONS] August 2022 election round, request for nominations

[Chuck Burgess]

I would like to serve another term, so I am seeking a renomination.
CRB

On Wed, Aug 3, 2022, 06:23 Vincent de Lau  wrote:

> Hi all,
>
> It is that time of year again! And I don't mean time for vacation, but
> time for the August 2022 election round.
>
> The terms of the following people will be ending by the end of August:
> - Cees-Jan Kiewiet (Core Committee)
> - Chuck Burgess (Core Committee)
> - Woody Gilk (Core Committee)
> - Ben Edmunds (Core Committee)
> - Alessandro Lai (Secretary)
>
> With this email, we open the nomination period, which will end by
> 2022-08-12 17:00:00 UTC. Voting will start 24 hours later and last for 14
> days.
>
> Unfortunately we are a bit late with announcing this election round, but
> please give this a bit of attention and think of the people you would like
> to see filling these roles in the PHP-FIG. Although official nominations
> need to be done by a Project representative or Secretary, recommendations
> are welcome from anyone in the community.
>
> For details about eligibility and the nomination process, see the by-laws:
> https://www.php-fig.org/bylaws/elections-and-vacancies/. Please keep in
> mind that nomination and acceptance needs to be done on the mailing list.
> If you need any help with the nomination process or have any other
> question, feel free to reach out to one of the secretaries either by mail
> or on Discord.
>
> Kind regards,
>
> Vincent de Lau
> PHP-FIG Secretary
>
> --
> 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/9397a80b-e12d-4f4d-b990-409e9865afc9n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/9397a80b-e12d-4f4d-b990-409e9865afc9n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANsgjnsYAF7kFSgkx0UjSQ2Dru-yKZuT2T%2Bc42Cs%3DmZg5-yCsQ%40mail.gmail.com.

Re: PSR-20 Clock status

[Chuck Burgess]

Given no further discussion, I'm trying to reach the Editor via Github and
Discord (and here, if you see this, Chris Seufert) to get his ok on a
readiness vote.
CRB

On Sat, Jul 23, 2022, 11:36 Chuck Burgess  wrote:

> On the timezone being undefined... the UNIX timestamp integer returned by
> DateTimeImmutable->getTimestamp() gives a reliably unique value for an
> instant in time, and the only effect a timezone has on that value is a
> format string you can retrieve based on that integer timestamp, right?  So
> it's not that you have an ambiguous value in hand... it's just that the
> interface doesn't demand it present its "string value" in a single way...
> right?
> CRB
> *about.me/ashnazg <http://about.me/ashnazg>*
>
>
> On Sat, Jul 23, 2022 at 11:00 AM Chuck Burgess 
> wrote:
>
>> My rewording PR for the timezone FAQ section is up, in case you want to
>> review it.  I did not expand on any ideas already there... just tried to
>> tighten up the phrasing.
>> CRB
>> *about.me/ashnazg <http://about.me/ashnazg>*
>>
>>
>> On Wed, Jul 20, 2022 at 8:49 AM Larry Garfield 
>> wrote:
>>
>>> Great.  When last I looked at it, I still had concerns around the UTC
>>> question. "Undefined behavior" bothers me, and even with the added text I
>>> wasn't fully convinced that leaving the timezone undefined was the right
>>> call.  Other than that it seemed fine to me.
>>>
>>> --
>>>   Larry Garfield
>>>   la...@garfieldtech.com
>>>
>>> On Tue, Jul 19, 2022, at 5:25 PM, Chuck Burgess wrote:
>>> > After the progress Chris and I made since Sunday, I want to do one
>>> more
>>> > read-over, possibly a wording PR... and then see if he as Editor is
>>> > ready for the next formal step.
>>> > CRB
>>> >
>>> > On Tue, Jul 19, 2022, 17:18 Larry Garfield 
>>> wrote:
>>> >> What's the verdict here?
>>> >>
>>> >> --
>>> >>   Larry Garfield
>>> >>   la...@garfieldtech.com
>>> >>
>>> >> On Tue, Jul 5, 2022, at 6:30 AM, Chuck Burgess wrote:
>>> >> > Sorry folks... if there was another email thread on this trying to
>>> move
>>> >> > it along, I somehow missed it... and if Discord was deemed the
>>> official
>>> >> > replacement to replace the email group for such communications, I
>>> must
>>> >> > have missed it too... I haven't had enough space in my office area
>>> to
>>> >> > keep my OSS laptop open 24x7 like I used to do.
>>> >> >
>>> >> > I'll catch things up in the next week or so... I have something
>>> going
>>> >> > on late this week that will get in the way, which is why I think it
>>> >> > could take me into next week to catch things up.
>>> >> > CRB
>>> >> >
>>> >> > On Tue, Jul 5, 2022, 03:58 Andreas Heigl  wrote:
>>> >> >>
>>> >> >>
>>> >> >> On 05.07.22 10:17, Alessandro Lai wrote:
>>> >> >> > What's the status on the spec? IIRC is basically complete,
>>> right? We just
>>> >> >> > need to push it to the approval vote...
>>> >> >>
>>> >> >> There are still unresolved PRs regarding timezone issues.
>>> >> >>
>>> >> >> The spec is in the same state as it was almost a year ago. Since
>>> then I
>>> >> >> have tried at least twice to get it towards an approval vote but
>>> neither
>>> >> >> the sponsor or the editor were responding nor was the CC taking
>>> any actions.
>>> >> >>
>>> >> >> In at least the last try from my side to get to a readiness vote
>>> was
>>> >> >> also the option contained to take over the responsibility of the
>>> PSR.
>>> >> >> There has been no response whatsoever regarding that.
>>> >> >>
>>> >> >> Cheers
>>> >> >>
>>> >> >> Andreas
>>> >> >>
>>> >> >> >
>>> >> >> > It would be a shame to abandon it now, when it's so close to the
>>> finish
>>> >> >> > line...
>>> >> >> >
>>> >> >> > Il giorno domenica 3 luglio 2022 alle 19:15:37

Re: PSR-20 Clock status

[Chuck Burgess]

On the timezone being undefined... the UNIX timestamp integer returned by
DateTimeImmutable->getTimestamp() gives a reliably unique value for an
instant in time, and the only effect a timezone has on that value is a
format string you can retrieve based on that integer timestamp, right?  So
it's not that you have an ambiguous value in hand... it's just that the
interface doesn't demand it present its "string value" in a single way...
right?
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Sat, Jul 23, 2022 at 11:00 AM Chuck Burgess  wrote:

> My rewording PR for the timezone FAQ section is up, in case you want to
> review it.  I did not expand on any ideas already there... just tried to
> tighten up the phrasing.
> CRB
> *about.me/ashnazg <http://about.me/ashnazg>*
>
>
> On Wed, Jul 20, 2022 at 8:49 AM Larry Garfield 
> wrote:
>
>> Great.  When last I looked at it, I still had concerns around the UTC
>> question. "Undefined behavior" bothers me, and even with the added text I
>> wasn't fully convinced that leaving the timezone undefined was the right
>> call.  Other than that it seemed fine to me.
>>
>> --
>>   Larry Garfield
>>   la...@garfieldtech.com
>>
>> On Tue, Jul 19, 2022, at 5:25 PM, Chuck Burgess wrote:
>> > After the progress Chris and I made since Sunday, I want to do one more
>> > read-over, possibly a wording PR... and then see if he as Editor is
>> > ready for the next formal step.
>> > CRB
>> >
>> > On Tue, Jul 19, 2022, 17:18 Larry Garfield 
>> wrote:
>> >> What's the verdict here?
>> >>
>> >> --
>> >>   Larry Garfield
>> >>   la...@garfieldtech.com
>> >>
>> >> On Tue, Jul 5, 2022, at 6:30 AM, Chuck Burgess wrote:
>> >> > Sorry folks... if there was another email thread on this trying to
>> move
>> >> > it along, I somehow missed it... and if Discord was deemed the
>> official
>> >> > replacement to replace the email group for such communications, I
>> must
>> >> > have missed it too... I haven't had enough space in my office area
>> to
>> >> > keep my OSS laptop open 24x7 like I used to do.
>> >> >
>> >> > I'll catch things up in the next week or so... I have something
>> going
>> >> > on late this week that will get in the way, which is why I think it
>> >> > could take me into next week to catch things up.
>> >> > CRB
>> >> >
>> >> > On Tue, Jul 5, 2022, 03:58 Andreas Heigl  wrote:
>> >> >>
>> >> >>
>> >> >> On 05.07.22 10:17, Alessandro Lai wrote:
>> >> >> > What's the status on the spec? IIRC is basically complete, right?
>> We just
>> >> >> > need to push it to the approval vote...
>> >> >>
>> >> >> There are still unresolved PRs regarding timezone issues.
>> >> >>
>> >> >> The spec is in the same state as it was almost a year ago. Since
>> then I
>> >> >> have tried at least twice to get it towards an approval vote but
>> neither
>> >> >> the sponsor or the editor were responding nor was the CC taking any
>> actions.
>> >> >>
>> >> >> In at least the last try from my side to get to a readiness vote
>> was
>> >> >> also the option contained to take over the responsibility of the
>> PSR.
>> >> >> There has been no response whatsoever regarding that.
>> >> >>
>> >> >> Cheers
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> >
>> >> >> > It would be a shame to abandon it now, when it's so close to the
>> finish
>> >> >> > line...
>> >> >> >
>> >> >> > Il giorno domenica 3 luglio 2022 alle 19:15:37 UTC+2 Larry
>> Garfield ha
>> >> >> > scritto:
>> >> >> >
>> >> >> >> The PSR-20 working group has been inactive for many months now
>> (it's been
>> >> >> >> 10 months since any changes to the spec document[1]), far longer
>> than the
>> >> >> >> allowed time for a working group to be inactive. The Editor,
>> Chris Seufert,
>> >> >> >> has been inactive and unreachable via Discord in the WG's
>> channel for
>> >> >> >>

Re: PSR-20 Clock status

[Chuck Burgess]

My rewording PR for the timezone FAQ section is up, in case you want to
review it.  I did not expand on any ideas already there... just tried to
tighten up the phrasing.
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Wed, Jul 20, 2022 at 8:49 AM Larry Garfield 
wrote:

> Great.  When last I looked at it, I still had concerns around the UTC
> question. "Undefined behavior" bothers me, and even with the added text I
> wasn't fully convinced that leaving the timezone undefined was the right
> call.  Other than that it seemed fine to me.
>
> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> On Tue, Jul 19, 2022, at 5:25 PM, Chuck Burgess wrote:
> > After the progress Chris and I made since Sunday, I want to do one more
> > read-over, possibly a wording PR... and then see if he as Editor is
> > ready for the next formal step.
> > CRB
> >
> > On Tue, Jul 19, 2022, 17:18 Larry Garfield 
> wrote:
> >> What's the verdict here?
> >>
> >> --
> >>   Larry Garfield
> >>   la...@garfieldtech.com
> >>
> >> On Tue, Jul 5, 2022, at 6:30 AM, Chuck Burgess wrote:
> >> > Sorry folks... if there was another email thread on this trying to
> move
> >> > it along, I somehow missed it... and if Discord was deemed the
> official
> >> > replacement to replace the email group for such communications, I
> must
> >> > have missed it too... I haven't had enough space in my office area to
> >> > keep my OSS laptop open 24x7 like I used to do.
> >> >
> >> > I'll catch things up in the next week or so... I have something going
> >> > on late this week that will get in the way, which is why I think it
> >> > could take me into next week to catch things up.
> >> > CRB
> >> >
> >> > On Tue, Jul 5, 2022, 03:58 Andreas Heigl  wrote:
> >> >>
> >> >>
> >> >> On 05.07.22 10:17, Alessandro Lai wrote:
> >> >> > What's the status on the spec? IIRC is basically complete, right?
> We just
> >> >> > need to push it to the approval vote...
> >> >>
> >> >> There are still unresolved PRs regarding timezone issues.
> >> >>
> >> >> The spec is in the same state as it was almost a year ago. Since
> then I
> >> >> have tried at least twice to get it towards an approval vote but
> neither
> >> >> the sponsor or the editor were responding nor was the CC taking any
> actions.
> >> >>
> >> >> In at least the last try from my side to get to a readiness vote was
> >> >> also the option contained to take over the responsibility of the
> PSR.
> >> >> There has been no response whatsoever regarding that.
> >> >>
> >> >> Cheers
> >> >>
> >> >> Andreas
> >> >>
> >> >> >
> >> >> > It would be a shame to abandon it now, when it's so close to the
> finish
> >> >> > line...
> >> >> >
> >> >> > Il giorno domenica 3 luglio 2022 alle 19:15:37 UTC+2 Larry
> Garfield ha
> >> >> > scritto:
> >> >> >
> >> >> >> The PSR-20 working group has been inactive for many months now
> (it's been
> >> >> >> 10 months since any changes to the spec document[1]), far longer
> than the
> >> >> >> allowed time for a working group to be inactive. The Editor,
> Chris Seufert,
> >> >> >> has been inactive and unreachable via Discord in the WG's channel
> for
> >> >> >> several months. The Sponsor, Chuck Burgess, has also not
> responded to
> >> >> >> messages on Discord in the WG's channel.
> >> >> >>
> >> >> >> Per the bylaws[2]:
> >> >> >>
> >> >> >> -
> >> >> >> The Editor or Sponsor of a Working Group may step down at any
> time by
> >> >> >> informing the Core Committee via the mailing list. If the
> departing
> >> >> >> individual specifies an intended replacement from the Working
> Group
> >> >> >> membership, that individual will assume the vacant role
> immediately, by
> >> >> >> Implicit Approval. If necessary, a Decision Vote to appoint a new
> Editor or
> >> >> >> Sponsor may be held following a suitable nomination period.
> >> >> >>
> >

Re: PSR-20 Clock status

[Chuck Burgess]

After the progress Chris and I made since Sunday, I want to do one more
read-over, possibly a wording PR... and then see if he as Editor is ready
for the next formal step.
CRB

On Tue, Jul 19, 2022, 17:18 Larry Garfield  wrote:

> What's the verdict here?
>
> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> On Tue, Jul 5, 2022, at 6:30 AM, Chuck Burgess wrote:
> > Sorry folks... if there was another email thread on this trying to move
> > it along, I somehow missed it... and if Discord was deemed the official
> > replacement to replace the email group for such communications, I must
> > have missed it too... I haven't had enough space in my office area to
> > keep my OSS laptop open 24x7 like I used to do.
> >
> > I'll catch things up in the next week or so... I have something going
> > on late this week that will get in the way, which is why I think it
> > could take me into next week to catch things up.
> > CRB
> >
> > On Tue, Jul 5, 2022, 03:58 Andreas Heigl  wrote:
> >>
> >>
> >> On 05.07.22 10:17, Alessandro Lai wrote:
> >> > What's the status on the spec? IIRC is basically complete, right? We
> just
> >> > need to push it to the approval vote...
> >>
> >> There are still unresolved PRs regarding timezone issues.
> >>
> >> The spec is in the same state as it was almost a year ago. Since then I
> >> have tried at least twice to get it towards an approval vote but
> neither
> >> the sponsor or the editor were responding nor was the CC taking any
> actions.
> >>
> >> In at least the last try from my side to get to a readiness vote was
> >> also the option contained to take over the responsibility of the PSR.
> >> There has been no response whatsoever regarding that.
> >>
> >> Cheers
> >>
> >> Andreas
> >>
> >> >
> >> > It would be a shame to abandon it now, when it's so close to the
> finish
> >> > line...
> >> >
> >> > Il giorno domenica 3 luglio 2022 alle 19:15:37 UTC+2 Larry Garfield ha
> >> > scritto:
> >> >
> >> >> The PSR-20 working group has been inactive for many months now (it's
> been
> >> >> 10 months since any changes to the spec document[1]), far longer
> than the
> >> >> allowed time for a working group to be inactive. The Editor, Chris
> Seufert,
> >> >> has been inactive and unreachable via Discord in the WG's channel for
> >> >> several months. The Sponsor, Chuck Burgess, has also not responded to
> >> >> messages on Discord in the WG's channel.
> >> >>
> >> >> Per the bylaws[2]:
> >> >>
> >> >> -
> >> >> The Editor or Sponsor of a Working Group may step down at any time by
> >> >> informing the Core Committee via the mailing list. If the departing
> >> >> individual specifies an intended replacement from the Working Group
> >> >> membership, that individual will assume the vacant role immediately,
> by
> >> >> Implicit Approval. If necessary, a Decision Vote to appoint a new
> Editor or
> >> >> Sponsor may be held following a suitable nomination period.
> >> >>
> >> >> Should a Working Group be missing an Editor for 60 days; be missing a
> >> >> Sponsor for 60 days; have insufficient active members for 60 days;
> or show
> >> >> no signs of activity for six months, then the Core Committee may
> hold a
> >> >> Decision Vote to name a new Editor or Sponsor, following a suitable
> >> >> nomination process. One of the options in that Decision Vote must be
> to
> >> >> dissolve the Working Group. If no suitable candidates for Editor or
> Sponsor
> >> >> may be found, then the Working Group is automatically dissolved.
> >> >> -
> >> >>
> >> >> At this time, the PSR-20 WG is inactive. There are four possible next
> >> >> steps:
> >> >>
> >> >> 1. The Sponsor becomes active again and nominates a new Editor who
> can
> >> >> complete the PSR and bring it to a vote. If there is a dispute over
> who the
> >> >> Editor should be, the CC will hold a Decision Vote.
> >> >>
> >> >> 2. The Sponsor may step down as Sponsor, in which case a new Sponsor
> from
> >> >> the CC will need to step forward. If there is a dispute over who the
> Editor
> >> >>

Re: PSR-20 Clock status

[Chuck Burgess]

Sorry folks... if there was another email thread on this trying to move it
along, I somehow missed it... and if Discord was deemed the official
replacement to replace the email group for such communications, I must have
missed it too... I haven't had enough space in my office area to keep my
OSS laptop open 24x7 like I used to do.

I'll catch things up in the next week or so... I have something going on
late this week that will get in the way, which is why I think it could take
me into next week to catch things up.
CRB

On Tue, Jul 5, 2022, 03:58 Andreas Heigl  wrote:

>
>
> On 05.07.22 10:17, Alessandro Lai wrote:
> > What's the status on the spec? IIRC is basically complete, right? We just
> > need to push it to the approval vote...
>
> There are still unresolved PRs regarding timezone issues.
>
> The spec is in the same state as it was almost a year ago. Since then I
> have tried at least twice to get it towards an approval vote but neither
> the sponsor or the editor were responding nor was the CC taking any
> actions.
>
> In at least the last try from my side to get to a readiness vote was
> also the option contained to take over the responsibility of the PSR.
> There has been no response whatsoever regarding that.
>
> Cheers
>
> Andreas
>
> >
> > It would be a shame to abandon it now, when it's so close to the finish
> > line...
> >
> > Il giorno domenica 3 luglio 2022 alle 19:15:37 UTC+2 Larry Garfield ha
> > scritto:
> >
> >> The PSR-20 working group has been inactive for many months now (it's
> been
> >> 10 months since any changes to the spec document[1]), far longer than
> the
> >> allowed time for a working group to be inactive. The Editor, Chris
> Seufert,
> >> has been inactive and unreachable via Discord in the WG's channel for
> >> several months. The Sponsor, Chuck Burgess, has also not responded to
> >> messages on Discord in the WG's channel.
> >>
> >> Per the bylaws[2]:
> >>
> >> -
> >> The Editor or Sponsor of a Working Group may step down at any time by
> >> informing the Core Committee via the mailing list. If the departing
> >> individual specifies an intended replacement from the Working Group
> >> membership, that individual will assume the vacant role immediately, by
> >> Implicit Approval. If necessary, a Decision Vote to appoint a new
> Editor or
> >> Sponsor may be held following a suitable nomination period.
> >>
> >> Should a Working Group be missing an Editor for 60 days; be missing a
> >> Sponsor for 60 days; have insufficient active members for 60 days; or
> show
> >> no signs of activity for six months, then the Core Committee may hold a
> >> Decision Vote to name a new Editor or Sponsor, following a suitable
> >> nomination process. One of the options in that Decision Vote must be to
> >> dissolve the Working Group. If no suitable candidates for Editor or
> Sponsor
> >> may be found, then the Working Group is automatically dissolved.
> >> -
> >>
> >> At this time, the PSR-20 WG is inactive. There are four possible next
> >> steps:
> >>
> >> 1. The Sponsor becomes active again and nominates a new Editor who can
> >> complete the PSR and bring it to a vote. If there is a dispute over who
> the
> >> Editor should be, the CC will hold a Decision Vote.
> >>
> >> 2. The Sponsor may step down as Sponsor, in which case a new Sponsor
> from
> >> the CC will need to step forward. If there is a dispute over who the
> Editor
> >> should be, the CC will hold a Decision Vote. The new Sponsor will then
> take
> >> step 1.
> >>
> >> 3. Neither the Sponsor nor Editor are heard from, so the CC appoints a
> new
> >> Sponsor and Editor by Decision Vote.
> >>
> >> 4. The working group is dissolved and PSR-20 is listed as abandoned.
> >>
> >> Of note: Other current members of the working group[3] are eligible to
> be
> >> the new Editor, but the Sponsor must be a member of the Core Committee.
> >>
> >> If nothing happens within 2 weeks, I believe we should declare option 4
> >> enacted by default and the WG abandoned.
> >>
> >> (I would personally like to avoid option 4, as I really do believe this
> >> spec is valuable and should be completed.)
> >>
> >> [1] https://github.com/php-fig/fig-standards/tree/master/proposed
> >> [2]
> >>
> https://www.php-fi

Re: [VOTE][CC] Coding Style 1.0.0 Approval Vote

[Chuck Burgess]

+1

On Wed, May 25, 2022, 11:20 Korvin Szanto  wrote:

> Hi Everyone,
> The Coding Style PER 1.0.0 tag has been voted ready by the working group.
> This
> version of the Coding Style PER is effectively the same as PSR-12 with only
> basic updates to terminology, naming, and formatting so any project
> compatible with PSR-12 today will also be compatible with this proposed
> 1.0.0.
> Please review the full list of changes here:
> https://github.com/php-fig/per-coding-style/compare/8201676...b5cac84
>
> This is an approval vote limited to Core Committee members, so quorum is
> 50%
> and 2/3 majority is required to pass. If this vote passes, `b5cac84` will
> be
> tagged as `1.0.0`.
>
> Thanks,
> Korvin
>
> --
> 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/CANeXGWUR2Q3pv4Vuqce0w3WFO7%3DnfJSm0Hncmi3eaFbs%3DcEKyQ%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntWXDZseCm1%2BWVMiboeAQGb6egYPFHekjei-iBUPpuoQQ%40mail.gmail.com.

Re: [Vote] Maintainer for log-util library

[Chuck Burgess]

+1

On Wed, May 18, 2022, 13:36 Larry Garfield  wrote:

> I hereby open a Core Committee Vote to appoint Ralf Lang as Maintainer for
> a new log-util library that kinda-sorta exists but has no releases yet. :-)
>
> https://github.com/php-fig/log-util/
>
> This is an Approval Vote, Core Committee only, quorum is 50%, passage is
> 2/3.  The vote will end on 1 June or when all of the CC has voted,
> whichever occurs first.
>
> --
>   Larry Garfield
>   la...@garfieldtech.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/f7e8b221-fb23-4894-8dd8-7745d3ee110e%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntwSea2EHEuU4R6fDdVVpQydr%2Bpx8fDWcD34R4n7w94eQ%40mail.gmail.com.

Re: [VOTE][PSR-7] Header validation errata

[Chuck Burgess]

+1

On Wed, Apr 20, 2022, 09:28 Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> Hi, all!
>
> The two week discussion period regarding proposed errata on PSR-7 related
> to validation of header fields has completed. We had some feedback
> basically immediately, and that feedback was incorporated. For reference:
>
> - https://github.com/php-fig/fig-standards/pull/1274
>
> The tl;dr: PSR-7 implementations SHOULD strictly validate header names and
> contents according to the most recent HTTP specification ([RFC 7230#3.2][1]
> at the time of writing). The implementation SHOULD reject invalid values
> and SHOULD NOT make any attempt to automatically correct the provided
> values. The errata provides more specific details about this validation,
> but it's primarily around line wrapping of headers.The changes are
> suggested to ensure that implementations provide a minimum amount of
> security for end-users.
>
> At this time, I am opening a VOTE for inclusion of this errata in PSR-7.
> The vote is open to CC members only, and requires a 50% quorum, and a 2/3
> approval to pass. The vote will end 2 weeks from the time I send this.
>
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> he/him
>
> --
> 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/CAJp_myVoiiH2qd_HwTxT5UgSeGqNVqmsQ4sDur1Km%2BYuqccigQ%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnub%2BRWOhM_mYTki67DXd%2BH21QpVobBW4T0jGv50ejK-2Q%40mail.gmail.com.

Re: [ENTRANCE] [VOTE] [CC] Tracing PSR

[Chuck Burgess]

+1

CRB

On Tue, Mar 29, 2022, 03:03 Alessandro Chitolina  wrote:

> As the Sponsor for this candidate PSR, after seeing a positive response
> and a great interest from the community, I hereby call the Entrance Vote.
>
> The PR of this proposal is here:
> https://github.com/php-fig/fig-standards/pull/1273
>
> Editor: Adam Allport
> Sponsor: Alessandro Chitolina
> Working Group Members
> Alex Bouma
> Ben Edmunds
> Brett McBride
> Timo Michna
>
> Please do not reply to this topic if you are not a CC member.
>
> --
> 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/46b2a157-b19f-4f98-842c-a85ae2707437n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntLEFyan3UhLqxd1GN6zTvFjeXLzsBW9PLun7cX1hxiTQ%40mail.gmail.com.

Re: [VOTE] Core Committee Election January 2022

[Chuck Burgess]

Ken Guest
Korvin Szanto
Chris Tankersley
Enrico Zimuel
Florian Engelhardt
Navarr Barnier

CRB (PEAR)

On Sat, Jan 15, 2022, 10:51 Vincent de Lau  wrote:

> Hello everyone,
>
> Yesterday the nomination period ended, and we got 7 nominations in total,
> which is great!
> For the secretary seat, we have one uncontested nomination. For the Core
> Committee, we have 6 nominations against 4 available seats, so this means
> that we will be holding a proper election, starting now! The nominees are
> (in temporal order of nomination):
>
>- Korvin Szanto - https://groups.google.com/g/php-fig/c/Rv43KRFOt_A
>- Navarr Barnier - https://groups.google.com/g/php-fig/c/kAOTuIFB7Eg
>- Chris Tankersley - https://groups.google.com/g/php-fig/c/xtrwd7o6SOQ
>- Ken Guest - https://groups.google.com/g/php-fig/c/QtKqPOYZ2HA
>- Florian Engelhardt -
>https://groups.google.com/g/php-fig/c/wjxZf1VMzDA
>- Enrico Zimuel - https://groups.google.com/g/php-fig/c/vA-dFT8lXbM
>
> You can find information about the nominees inside the linked nomination
> thread. Full information about the Core Committee vote and role is visible
> in the bylaws here:
> https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee *Who
> can vote?* As specified in the bylaws, the vote for CC members is open to
> Project Representatives and individuals from the community. To be eligible
> to vote as an individual, the bylaw established the following threshold:: 
> *"Any
> individual that has posted a non-trivial message in the official FIG venue
> (mailing list, forum, etc.) at least five (5) times within the past
> calendar year as of the start of nominations [...] is eligible to vote on
> Core Committee candidates."* We will obviously consider Discord in this
> account; feel free to reach to me or any other secretary to check on the
> matter. *When can you vote?* Voting will be open in this thread until
> January 29th 17:00 UTC.
> *How to vote*
> Votes are cast by replying in this thread on the list. For individuals
> that have not used the mailing list before, please be sure to identify
> yourself, for instance by including your Discord or Github handle.
> 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 all the candidates in order of preference
> for example: 1. Luke 2. Leia 3. Anakin 4. Rey 5. Padmé 6. Finn At the end
> of the voting phase, secretaries will be announcing the results, and all
> the newly elected (both CC members and secretary). Thanks, and happy
> voting! Alessandro Lai and Vincent de Lau PHP-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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/22dd11d5-8d4a-46d7-ab77-e291b4e03f49n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuYdOOiF_%3DRyT8WdmrD_htq-1Tb5-KQTxnjr4vU19yq0A%40mail.gmail.com.

Re: [ENTRANCE] [VOTE] [CC] PER Coding Style

[Chuck Burgess]

+1

On Sat, Jan 15, 2022, 21:33 Chris Tankersley  wrote:

> As the sponsor for this PER Working Group, I hereby call an entrance vote
> for the PER Coding Style.
>
> The purpose of this PER is to migrate PSR-12 to a living document under
> the new PHP Evolving Recommendations structure. This will allow the coding
> style recommendations to more quickly integrate new syntax features
> provided by the language.
>
> The PER will be worked on here:
> https://github.com/php-fig/per-coding-style
>
> This is a Core Committee vote only.
>
> Editor: Alexander Makarov
> Sponsor: Chris Tankersley
> Working Group:
> - Ken Guest
> - Larry Garfield
> - Korvin Szanto
> - Woody Gilk
>
> We have a few others interested that may join the WG later.
>
> --
> Chris Tankersley
> http://ctankersley.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAL9n4XMhazaQfZxfpuTrSM%3Dy2XcmE5kFD9nXZkgqK9_EuLF3sA%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnvHvBjjtdMpKNRTXpvrwBqwuc5fQVy_x9cJeykkf_bhFA%40mail.gmail.com.

Re: [Entrance Vote]{CC] Localization PSR

[Chuck Burgess]

+1

On Wed, Dec 8, 2021, 16:04 Larry Garfield  wrote:

> After a great deal of offlist discussion, I hereby call an Entrance Vote
> on a Code Localization PSR.
>
> Specifically, the charter is here:
>
> https://github.com/php-fig/fig-standards/pull/1259/files
>
> Little has been firmly defined yet, of course.  That's why we're building
> a Working Group. :-)  But we have narrowed the scope to something we
> believe is manageable.
>
> We are open to, and still soliciting, additional WG members who have
> particular experience with major projects that have existing code
> localization systems.  Additional personnel MAY be added in the future,
> therefore.
>
> This is a Core Committee vote only.  Non-CC members, please sit tight. :-)
>
> --
>   Larry Garfield
>   la...@garfieldtech.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/6b75ff3d-f909-49d3-a277-00e49d1fa8ae%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuNvYFOZ8uujx1QwFk4oAu%2BoYo2OY10uugmRhi5qRzwmg%40mail.gmail.com.

Re: [VOTE][CC] PSR-16 (simple-cache) evolution

[Chuck Burgess]

+1

On Thu, Oct 14, 2021, 02:12 Alessandro Lai 
wrote:

> Hello everyone,
> I hereby call a CC vote for the approval of the evolution of PSR-16 -
> Simple Cache.
>
> The change in the spec is reviewable in this PR:
> https://github.com/php-fig/fig-standards/pull/1252
> Inside the PR description you'll find the links to the two PR containing
> the code changes:
>  - v2 adds parameters types, and makes CacheException extend \Throwable
>  - v3 (which obviously builds upon the previous) adds return types
>
> Both require PHP 8 at a minimum, since mixed and union types were needed,
> and also to avoid issues when extending \Throwable (as it happened with the
> evolution of PSR-11, see https://github.com/php-fig/container/issues/33).
>
> As per our bylaws:
>  - only Core Committee members may vote
>  - either For (+1), Against (-1), or Abstain (+0)
>  - quorum is 50%
>  - a 2/3 majority is required for passage.
>
> Votes take place over a period of two weeks (or at the reaching of 100%
> quorum), so votes will be accepted up to 2021-10-28 10:00:00 UTC.
>
> --
> 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/78c7b658-9db7-46a0-b715-b8b96e236dedn%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnt95VpFGBfLoiqkN%2BxRci1kJJ2q_JPbhf0WGh5pWTSq6g%40mail.gmail.com.

Re: [PSR-20] Feedback for the ClockInterface

[Chuck Burgess]

I think I remember most/all of the working group projects argued against
the TZ piece. The metadoc specifically says TZ is not included... maybe
that section should go deeper into the decision... ?
CRB

On Mon, Sep 13, 2021, 09:39 Woody Gilk  wrote:

> On Mon, Sep 13, 2021 at 9:26 AM Larry Garfield 
> wrote:
>
>> On Sun, Sep 12, 2021, at 12:53 PM, Andreas Heigl wrote:
>> > Hey all.
>> >
>> > Some months of work have past for the Working Group for PSR-20
>> > (ClockInterface).
>> >
>> > By now our idea of the interface has stabilized, a lot of internal
>> > decissions have been made and a lot of discussion with different people
>> > – especially maintainers of different clock implementations – have been
>> > done and had their influence on the interface and on the meta-document
>> > associated with it.
>> >
>> > Time to open up the discussion to the list and to external feedback.
>> >
>> > Please give feedback regarding the Interface[1] and the
>> > Meta-Document[2]. Either on the PSR-20 Channel on Discord[3], via the
>> > mailinglist or via PullRequests against those two documents.
>> >
>> > Cheers
>> >
>> > Andreas
>> >
>> > [1]
>> >
>> https://github.com/php-fig/fig-standards/blob/master/proposed/clock-meta.md
>> > [2]
>> https://github.com/php-fig/fig-standards/blob/master/proposed/clock.md
>> > [3] https://discord.com/channels/788815898948665366/818850995186171918
>>
>> I filed a small PR with some typo fixes. Nothing major.
>>
>> Overall I like the simplicity of it.  My main concern is, unsurprisingly,
>> around the timezone question, and usability.
>>
>> Right now, if I want "now" I can just call `new DateTimeImmutable('now',
>> new DateTimeZone('whatever'))` directly.  It's a single call.
>>
>> With the proposed interface, I will virtually always need to create TWO
>> DTI objects; one that gets returned by now(), and one returned by calling
>> setTimezone() on it.  (Because I never trust what the system timezone is
>> set to, and neither should you.)  That is slightly less performant, and
>> also clunkier feeling.  And that means people will forget to do it.
>>
>> I fear that, in its current form, we'll end up with a lot of people
>> assuming the timezone they get back from now() is reasonable, when in fact
>> it's not defined at all, and end up with subtle bugs.
>>
>
>
> I feel like the timezone concerns are not as dire as they might initially
> seem, because:
>
> 1. It is easy to wrap this interface with a local implementation that will
> always return the date object in (eg) UTC. It's about 3 actual lines of
> code.
> 2. In environments that we (really do) control, we can set `date.timezone`
> and not have to think about it again.
>
> That being said, I think it would also be reasonable for
> `ClockInterface::now()` to ALWAYS return a date in UTC timezone. That would
> create a stronger definition and eliminate most concerns about time zones.
> --
> Woody Gilk
> https://www.shadowhand.com
>
>
>>
>> --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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/f74c10e6-79ea-4113-913c-b79ded8407d3%40www.fastmail.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/CAGOJM6J62LT-Q6QJW5_RbghjSzSQqij%2BOn6QVTL5zi%2B4eQmb1Q%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntfP_No6v3xdfkcMMvS3m-88Gz8WBfORjr5KL7ptPp%3DpQ%40mail.gmail.com.

Re: [VOTE][CC] Bylaw change: introduce PHP Evolving Recommendations (PERs)

[Chuck Burgess]

+1

CRB

On Tue, Sep 7, 2021, 12:06 Vincent de Lau  wrote:

> This is the voting thread for the Core Committee only. There is a separate
> thread for Project Representative
>
> Larry Garfield has created a proposal for a change to the bylaws to
> introduce PHP Evolving Recommendations. As part of that proposal, some
> restructuring of the bylaws has been performed to be streamline the PSR,
> PER and AR processes.
>
> The discussion thread can be found here:
> https://groups.google.com/g/php-fig/c/gLNKg9jpRCU and some additional
> discussions on Discord.
>
> The proposed change can be seen in the pull request:
> https://github.com/php-fig/fig-standards/pull/1235 *(commit on day of
> voting fdadde82c28d517b515b6aa87d42cb71daded4b4)*
>
>
> Per the voting protocol: https://www.php-fig.org/bylaws/voting-protocol/
>
>- Voting options are For (+1), Against (-1), or Abstain (+0)
>- Quorum is 50%, a 2/3 majority is required for passage.
>- Voting ends in two weeks, 2021-09-21 17:00:00 UTC
>
>
> --
> 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/4d18ec79-8417-4938-aa7b-6fbd32c4b22bn%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnt7%2BMdWPbWnAX-aeJyRAc8M%2BvOiwFMwNmQVsytJ-Cp3DA%40mail.gmail.com.

Re: Proposal: PHP Evolving Recommendations (PERs)

[Chuck Burgess]

I added some tiny correction comments, but overall, I like it 
CRB


On Thu, Aug 26, 2021, 10:00 Ken Guest  wrote:

> Hi,
>
> I think having Evolving Proposals would be a good thing.
>
> Then people only have to bookmark the PER once and revisit it when
> appropriate instead of having to follow a trail to see what the most
> up-to-date recommendation is.
> For example, somebody coming back to PHP after a while might not know that
> PSR-12 exists but knows about PSR-2. When they find PER-CodingStandards
> they can be sure of the most recent PSR in that area.
>
> I mentioned this on Discord today. Alessandro Lai suggested that for this
> scenario in relation to code, we can bind that to new major versions, for
> CS maybe we can use a meta-package so projects can declare with a
> constraint their "version" of adherence to the PER.
>
> I think that for deprecated PSRs -  in this instance PSR 2 -  we could
> expand the Deprecated Notice block to identify and link to the pertinent
> PSR.
> This would mean someone will hopefully have fewer steps to go through to
> find the most recent relevant PSR.
>
> As an example the message "Deprecated - As of 2019-08-10 PSR-2 has been
> marked as deprecated. PSR-12 is now recommended as an alternative." would
> be changed to "Deprecated - As of 2019-08-10 PSR-2 has been marked as
> deprecated. Please consult PER-CodingStandards to quickly identify the most
> recent applicable PSR. At the time of this update, PSR-12 is the new
> Recommendation superseding this one (PSR-2)."
>
> Regards,
>
> Ken
>
> On Mon, 16 Aug 2021 at 21:24, Larry Garfield 
> wrote:
>
>> Thank you everyone for the feedback here and on GitHub.  Based on that,
>> I've refactored the bylaws quite a bit more to support a cleaner way to
>> define the PER process, and to split auxiliary resources (eg, util
>> libraries) off to their own setup.  The full changelog is in the PR:
>>
>> https://github.com/php-fig/fig-standards/pull/1235
>>
>> Feedback, round two!
>>
>> --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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/fa785737-c508-4e41-a799-790e2dd487a0%40www.fastmail.com
>> .
>>
>
>
> --
> http://about.me/kenguest/
>
> --
> 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/CAKcc2m_67PHxwd9GwVOojpXBm9Us4%3DQHHLsUk3n%3DLHYtV0cWVg%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnv7qFv%2Bv7uVB-qtywekvq%2BRcsdssq0X%3DwmyTbghFrKjrQ%40mail.gmail.com.

Re: [PSR-12] Proposal for a @generated tag

[Chuck Burgess]

PSR-19 actually... that's the tag catalog.
CRB


On Tue, Aug 10, 2021, 11:09 'Alexander Makarov' via PHP Framework
Interoperability Group  wrote:

> That sounds like a candidate for PSR-5, not for PSR-12.
>
> On Tuesday, August 10, 2021 at 7:05:01 PM UTC+3 ezimuel wrote:
>
>> Hi,
>>
>> While working with generated PHP files, I noticed we don't have a
>> specific phpDoc tag to inform us that a file/class/function has been
>> generated.
>>
>> Right now, I'm using a simple comment like this:
>> https://github.com/elastic/elasticsearch-php/blob/master/src/Elasticsearch/Endpoints/Count.php#L25
>> This information is really important because the generated file should
>> not be edited manually:-)
>>
>> My proposal is to add a @generated tag for PSR-12 as follows:
>> /**
>>  * @generated using util/GenerateEndpoints.php script
>>  */
>>
>> What do you think?
>> Thanks!
>>
>> Regards,
>> Enrico Zimuel
>> https://zimuel.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/6d0cbf93-e8e4-4447-83b2-03f5d456a1can%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuUQwyftPg5t9C7%3DRMP-T9oggd0KcON7CRRLidLPz3DOw%40mail.gmail.com.

Re: [VOTE][CC] AzuraCast Membership vote

[Chuck Burgess]

+1

Chuck Burgess (CC)

On Sat, Jul 31, 2021, 10:05 Vincent de Lau  wrote:

> This thread is to collect votes on the AzuraCast Membership vote.
>
> Details:
>  - membership request:
> https://groups.google.com/g/php-fig/c/0fVYv0ha4Lo/m/SN7_aviaBAAJ
>  - proposed project representative: Felix Bachmann, which is the second
> lead developer.
>  - disclosure: Current Secretary Buster Neese is a project lead for
> AzureCast. He will continue to be secretary and thus will not represent
> AzuraCast.
>  - request sponsored by Larry Garfield 2 weeks ago:
> https://groups.google.com/g/php-fig/c/0fVYv0ha4Lo/m/SN7_aviaBAAJ
>
> Voting ends by 2021-08-14 17:00 UTC
>
> Voting options:  For (+1), Against (-1), or Abstain (+0)
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#membership-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE HERE
>
> --
> 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/d514a947-c254-4da0-af2c-6fba1dca4743n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/d514a947-c254-4da0-af2c-6fba1dca4743n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANsgjnv-owGAFPs7-StQLQJobjQ6A7npfNs-k%3D6Loxtc9EE%3DqA%40mail.gmail.com.

Re: [Vote] PSR-3 Updates for Types

[Chuck Burgess]

Sorry for missing this, team... I'm catching up this morning and see that I
just missed it.  FTR, I'd have been +1 too.
CRB
*about.me/ashnazg *


On Tue, Jul 13, 2021 at 9:10 AM Larry Garfield 
wrote:

> On Fri, Jun 25, 2021, at 9:35 AM, Larry Garfield wrote:
> > Hear ye, hear ye!  I hereby open the vote on the type upgrades for
> > PSR-3.  Essentially, the vote is to merge and tag the following PRs:
> >
> > https://github.com/php-fig/fig-standards/pull/1231
> > https://github.com/php-fig/log/pull/76
> > https://github.com/php-fig/log/pull/77
> >
> > This is a Core Committee Vote, quorum 50% and requiring 66% approval.
> >
> > CC members, make with the voting.  And welcome to our new CC members
> > and their first task on the job. :-)
>
> Final results:
>
> Yes: 8
> No: 0
>
> Quorum (6) was reached. The vote passes.  Huzzah!
>
> Secretaries, I'm not sure I have access to commit and tag the repo
> branches.  Please either do so or give me access to do so.
>
> --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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/76748db8-fa61-451d-ac22-5c1072e3a988%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnsLNHj7yZQniqJSN%2BMSu2hovipUa-OLVeM0VLNTF2D3HA%40mail.gmail.com.

Re: [VOTE] Core Committee Election

[Chuck Burgess]

1. Matthew Weier O'Phinney
2. Larry Garfield
3. Michelle Sanver
4. Woody Gilk
5. Alessandro Chitolina

Chuck Burgess (PEAR)


On Thu, Jun 10, 2021, 10:42 Alessandro Lai 
wrote:

> Hello everyone,
> as specified in the previous thread (
> https://groups.google.com/g/php-fig/c/9Xeon2rP4SE), yesterday the
> nominations ended, and since today it's possible to vote for the renewal of
> the terms that are up for this elections.
>
> We have *5 spots on the Core Committee* up for reelection, four with a
> full two year term and a shorter one, that will end in August 2021, due to
> Beau Simensen stepping down; we also have one full-term spot for secretary.
>
> Since we have only one unopposed nomination for the secretary election, we
> will need to vote for the Core Committee positions only, for which we have
> five nominations (listed in chronological order of nomination):
>
>  - Larry Garfield
>  - Matthew Weier O'Phinney
> <https://groups.google.com/d/topic/php-fig/PAnOZqE4QiQ/discussion>
>  - Michelle Sanver
>  - Alessandro Chitolina
>  - Woody Gilk
> <https://groups.google.com/d/topic/php-fig/wVIhtZNVgmM/discussion>
>
> Full information about the Core Committee vote and role is visible in the
> bylaws here:
> https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee
>
> *Who can vote?*
> As specified in the bylaws, any Project Representative or any participant
> in the PHP-FIG ML can vote on the CC elections. A ML participant is defined
> in the bylaws as follows:
> "Any individual that has posted a non-trivial message in the official FIG
> venue (mailing list, forum, etc.) at least five (5) times within the past
> calendar year as of the start of nominations [...] is eligible to vote on
> Core Committee candidates."
>
>  *When can you vote?*
> Voting will be open in this thread until June 24th 23:59 UTC.
>
> *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
>
> At the end of the voting phase I will be announcing the results, and all
> the newly elected (both CC members and secretary), as announced before.
> Vote ordering will be also used to assign the terms, so the last of the
> elected will take the shorter one.
>
> Thanks!
>
> Alessandro Lai
> PHP-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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/622d8c4f-d242-403c-8170-33f412850bcdn%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/622d8c4f-d242-403c-8170-33f412850bcdn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANsgjnue71mSpR771gKee7fgR%3DBhdJ84gCAh9MZ7HQKW8wYJnQ%40mail.gmail.com.

Re: [VOTE][CC] Bylaw CS update

[Chuck Burgess]

+1

On Wed, Mar 31, 2021, 02:15 Alessandro Lai 
wrote:

>
> Hello everyone,
> this my seem a small formality, but we need a vote for a small bylaw
> amendment: https://github.com/php-fig/fig-standards/pull/1203
>
> Basically, we need to update the guidelines to follow PSR-12, since it
> deprecated PSR-2.
>
> As per our voting protocol:
> https://www.php-fig.org/bylaws/voting-protocol/
>
> This is a vote for the Core Committee only.
> Quorum is 50%.
> A 2/3 majority is required for passage.
> Voting ends in two weeks, at midnight UTC between 14th & 15th of April.
>
> I'll be opening a separate thread for project representative.
>
> --
> 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/0f947e00-2141-4ca6-910c-03b416878dcbn%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnunFPrw5gZYQ1KqbZgsKoWO7PQRi-e_zeKPvGAb3QkNaw%40mail.gmail.com.

Re: [Internal] Sunset Slack workspace?

[Chuck Burgess]

+1

On Wed, Mar 24, 2021, 07:24 Alessandro Lai 
wrote:

> Hello everyone,
> I'm happy to see that the Discord experiment is going well: over 200 users
> have joined, the newly formed WG for PSR-20 has found a home there, and
> we've now migrated the Twitter and site deploy integration too.
>
> So, my question is: should we close/retire the Slack workspace? It's
> basically silent, noone is using it, and our collective RAMs would surely
> be happier with one less workspace to be kept open.
>
> WDYT?
>
> --
> 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/9b86ef3a-e7bd-4577-9d32-37a201bf7dabn%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnukRmhW8%3D9Mh4Lh8H12Y%2B%3Dc7JyuB5GXJ06is26LP20DQQ%40mail.gmail.com.

Re: [ENTRANCE] [VOTE] [CC] Clock Interface PSR

[Chuck Burgess]

Should be 20... Doc Tag Catalog is 19.
CRB

On Wed, Mar 24, 2021, 06:42 Pol Dellaiera  wrote:

> PSR19 or PSR20 ?
>
> On Wednesday, March 24, 2021 at 12:37:16 PM UTC+1 alessand...@gmail.com
> wrote:
>
>> Vote is closed, all current CC members have cast their vote.
>>
>> We have a new PSR-19 in draft status!
>>
>> Il giorno martedì 23 marzo 2021 alle 16:55:39 UTC+1 ch...@ctankersley.com
>> ha scritto:
>>
>>> -1
>>>
>>> -Chris
>>>
>>> On Mon, Mar 15, 2021 at 7:35 PM Chuck Burgess 
>>> wrote:
>>>
>>>> As the Sponsor for this new candidate PSR, I hereby call the Entrance
>>>> Vote.
>>>>
>>>>
>>>> Proposal PR: https://github.com/php-fig/fig-standards/pull/1224
>>>>
>>>>
>>>> Editor: Chris Seufert
>>>> Sponsor:  Chuck Burgess - PHP-FIG
>>>> Working Group:
>>>> - Jérôme Gamez (kreait/clock)
>>>> - Andreas Möller (ergebnis/clock)
>>>> - Luís Cobucci (lcobucci/clock)
>>>> - Pol Dellaiera
>>>> - Ben Edmunds
>>>> - Andreas Heigl (ergebnis/clock)
>>>>
>>>>
>>>> Please do not reply to this topic if you are not a CC member.
>>>> --
>>>>
>>>> --
>>>>
>>> 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+u...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/php-fig/CANsgjnsAk9%2BmEEgM2od81rs5JttLHV%3DDuYpkaMF9qtuFx%3DwEGQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/php-fig/CANsgjnsAk9%2BmEEgM2od81rs5JttLHV%3DDuYpkaMF9qtuFx%3DwEGQ%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>> Chris Tankersley
>>> http://ctankersley.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/3cf4dae2-5303-4857-b8bf-c3cf3393f198n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/3cf4dae2-5303-4857-b8bf-c3cf3393f198n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANsgjntjyx5AhMmngNQwfjmY%2B1Okbbj%2BBv%3DNfOPxVEgAEcnJ%2Bg%40mail.gmail.com.

Re: [ENTRANCE] [VOTE] [CC] Clock Interface PSR

[Chuck Burgess]

+1

On Mon, Mar 15, 2021, 18:35 Chuck Burgess  wrote:

> As the Sponsor for this new candidate PSR, I hereby call the Entrance Vote.
>
>
> Proposal PR: https://github.com/php-fig/fig-standards/pull/1224
>
>
> Editor: Chris Seufert
> Sponsor:  Chuck Burgess - PHP-FIG
> Working Group:
> - Jérôme Gamez (kreait/clock)
> - Andreas Möller (ergebnis/clock)
> - Luís Cobucci (lcobucci/clock)
> - Pol Dellaiera
> - Ben Edmunds
> - Andreas Heigl (ergebnis/clock)
>
>
> Please do not reply to this topic if you are not a CC member.
> --
>

-- 
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/CANsgjnsdkV0s-RX2w2DG1Gyb_5TMzas3mr_U-Fpi46bfy2xuuw%40mail.gmail.com.

[ENTRANCE] [VOTE] [CC] Clock Interface PSR

[Chuck Burgess]

As the Sponsor for this new candidate PSR, I hereby call the Entrance Vote.


Proposal PR: https://github.com/php-fig/fig-standards/pull/1224


Editor: Chris Seufert
Sponsor:  Chuck Burgess - PHP-FIG
Working Group:
- Jérôme Gamez (kreait/clock)
- Andreas Möller (ergebnis/clock)
- Luís Cobucci (lcobucci/clock)
- Pol Dellaiera
- Ben Edmunds
- Andreas Heigl (ergebnis/clock)


Please do not reply to this topic if you are not a CC member.
--

-- 
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/CANsgjnsAk9%2BmEEgM2od81rs5JttLHV%3DDuYpkaMF9qtuFx%3DwEGQ%40mail.gmail.com.

Re: Propsal Idea: ClockInterface

[Chuck Burgess]

I'll sponsor this... there seems to be a good amount of interest.
CRB

On Mon, Mar 8, 2021, 18:08 Larry Garfield  wrote:

> On Mon, Mar 8, 2021, at 5:14 PM, Chris Seufert wrote:
> > Hi,
> >
> > To update anyone on the progress made via the currently pull requests
> > on github. The consensus is that the interface spec should be far
> > simpler than the initial proposed one, and now looks as follows:
> >  >
> > namespace Psr\Clock;
> >
> > interface ClockInterface
> > {
> > /**
> >  * Returns the current time as a DateTimeImmutable Object
> >  */
> > public function now(): \DateTimeImmutable;
> >
> > }
> >
> >
> > After reaching out to several clock library authors. I have had
> > positive feedback from the most prominent library authors, and everyone
> > else who has commented on the PR is in general agreement on the spec.
> > As this is my first time working with getting something published as a
> > standard I am not sure what to do next, do I need to find a sponsor?
> > How would I go about that?
> >
> > Link to spec:
> > https://github.com/php-fig/fig-standards/pull/1224/files
>
> The full process is described here:
> https://www.php-fig.org/bylaws/psr-workflow/
>
> Short version: At this stage, you need yourself as Editor (I presume), one
> Core Committee member as a Sponsor, and 3 or more other people who can be
> anyone involved.  (Presumably the other existing library authors.)  Then
> the Sponsor calls an Entrance Vote on the proposal to date.  The Sponsor
> can help shepherd the spec through the remaining stages.
>
> So the next step is, who from the CC wants to Sponsor this?
>
> --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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/4b223db1-e784-4d7e-b8fe-660920c6dc09%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnv8skp-8SqjomBreQVaiSKCb%2BBWZUO%3DBwxaU_8NKTCZig%40mail.gmail.com.

Re: [Vote] PSR-13 Link Errata

[Chuck Burgess]

+1

On Wed, Feb 24, 2021, 15:51 Larry Garfield  wrote:

> Since there seems to be no dissension, no sense waiting any longer.
>
> I am hereby calling an Errata vote on the following Link fixes, including
> the linked (no pun intended) PRs.
>
> https://github.com/php-fig/fig-standards/pull/1222
>
> This is a CC Vote, requiring 2/3 to pass.  Voting will remain open until
> 10 March, unless all 11 CC members vote before then.  (Hint hint, folks.
> :-) )
>
> --
>   Larry Garfield
>   la...@garfieldtech.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/bd840128-4b76-41f6-b028-a7a98d3da420%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnvx9upEaWtBOE6MfzFYSpYh0t%2B7Uswd75YKZEBFTmniNA%40mail.gmail.com.

Re: [VOTE][PSR-11] Type Updates

[Chuck Burgess]

+1

On Fri, Feb 19, 2021, 08:31 Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> Hi, everyone!
>
> On 2021-01-25, I opened the discussion period around updating PSR-11 per
> the PSR Evolution bylaw (https://www.php-fig.org/bylaws/psr-evolution/).
> The discussion centers around three related proposals:
>
> - https://github.com/php-fig/fig-standards/pull/1215 (the errata for the
> specification)
> - https://github.com/php-fig/container/pull/20 (the first step of the
> evolution, adding argument typehints, and modifying defined exception
> interfaces to extend Throwable)
> - https://github.com/php-fig/container/pull/28 (the second step of the
> evolution, adding return typehints where reasonable)
>
> Since opening the discussion period, the main question was whether the
> second step should have the specification target PHP 8 in order to pick up
> the "mixed" type. Consensus is that we should target PHP 7 releases at this
> time, as this will allow libraries to adopt the changes faster. (As an
> example, we're only just now getting around to having
> laminas-servicemanager typehint explicitly against PSR-11 and not
> container-interop; we'll be able to jump to the latest versions of the spec
> immediately as a result.)
>
> As the discussion period has passed the two-week minimum threshold, I now
> hereby open the vote.
>
> +1 to merge the patches and create the new releases
> -1 to leave things as-is
> +0 to abstain
>
> Thanks in advance, everyone!
>
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> he/him
>
> --
> 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/CAJp_myVHMjmrQmk5LP_5rvdLYzbTPquQJSX%2BDE%2B2KS4UzbsJ2A%40mail.gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnvyfyeBtPrk-yFYp3NrhMLfOkM4EAtn_D7swLH4p0c%2BQg%40mail.gmail.com.

Re: [Vote] [PSR-6] Type updates

[Chuck Burgess]

+1

On Sat, Jan 16, 2021, 11:09 Larry Garfield  wrote:

> I hereby call a vote of the Core Committee to approve the following PRs to
> update PSR-6 to use modern PHP typing capabilities, as previously discussed.
>
> This is a Core Committee vote requiring a 50% quorum and 2/3 majority,
> with voting ending on 30 January.
>
> CC members, please cast your votes.
>
> Spec: https://github.com/php-fig/fig-standards/pull/1220
> Step 1: https://github.com/php-fig/cache/pull/23
> Step 2: https://github.com/php-fig/cache/pull/24
>
> --
>   Larry Garfield
>   la...@garfieldtech.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/09b03692-a9d4-4f14-a931-7723aaf94d19%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnvxY-Cq2UedtdZTRKCUzquEMJwJhK-n-4tX8PRLzG%2BPNw%40mail.gmail.com.

Re: [Vote] [PSR-13] updates

[Chuck Burgess]

+1

On Sat, Jan 16, 2021, 11:07 Larry Garfield  wrote:

> I hereby call a vote of the Core Committee to approve the following PRs to
> update PSR-13 to use modern PHP typing capabilities, as previously
> discussed.
>
> This is a Core Committee vote requiring a 50% quorum and 2/3 majority,
> with voting ending on 30 January.
>
> CC members, please cast your votes.
>
> Step 1: https://github.com/php-fig/link/pull/6
> Step 2: https://github.com/php-fig/link/pull/7
> Spec: https://github.com/php-fig/fig-standards/pull/1199
>
> --
>   Larry Garfield
>   la...@garfieldtech.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/fb854aac-a513-4d19-b2f0-1a4740e7d1e8%40www.fastmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnsBWpQjtbZp8yfML876tMAtEFW98qtiN_Oi0p_fx9dDfg%40mail.gmail.com.

Re: [Internal][ELECTIONS] Core Committee nominations needed!

[Chuck Burgess]

I accept... thanks Mike.
CRB

On Thu, Aug 13, 2020, 08:31 Mike van Riel  wrote:

> As phpDocumentor representative, I re-nominate Chuck Burgess for a new
> term.
>
> On Tuesday, 11 August 2020 at 16:00:17 UTC+2 alessand...@gmail.com wrote:
>
>> Thank you Ben for stepping up, and thank you Woody for the sponsorship.
>>
>> Nomination received!
>>
>> Il giorno domenica 9 agosto 2020 alle 17:02:06 UTC+2 ben.e...@gmail.com
>> ha scritto:
>>
>>> Thanks Woody! I accept the nomination.
>>>
>>> For those that don’t know me, here’s some info:
>>> I’ve been a software engineer for ~15 years, using PHP since the early
>>> PHP 4 days. I’m a Staff Engineer at Wayfair, working on our PHP Platforms
>>> team with a focus on accelerating and empowering the >1k PHP engineers
>>> here.
>>>
>>> I co-host the PHP Town Hall podcast and host the More Than Code podcast.
>>> I do some open source work, mostly around CodeIgniter and Ion Auth. I’m on
>>> the CodeIgniter Steering Committee and Security Team.
>>>
>>> I’ve been around the PHP community for ages now but haven’t had the time
>>> to contribute to the FIG until recently. I’d really love to contribute back
>>> to the group. It’s made my life as a developer immensely better over the
>>> years.
>>>
>>> Feel free to message if you have any questions for me. Thanks all!
>>
>> --
> 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/079bc416-37aa-4be3-9238-cab22a1939bbn%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/079bc416-37aa-4be3-9238-cab22a1939bbn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANsgjnuGBWQOhTun2dQ7FHVcESG1cu%3DHeW7nzexcuXNjMVej-w%40mail.gmail.com.

Re: [Internal][ELECTIONS] Secretary nominations needed!

[Chuck Burgess]

As the PEAR representative, I nominate Alessandro Lai for a new term.
CRB

On Wed, Jul 29, 2020, 09:45 Alessandro Lai 
wrote:

>
> Hello everyone,
> it's that time of the year again: August will be an election month, and a
> Secretary seat (mine!) is expiring, and we need to fill it again.
>
> For the full rules, you can refer to our bylaw (which I'll be quoting
> below): https://www.php-fig.org/bylaws/elections-and-vacancies/
>
> I'm opening this thread to ask for *Secretary nominations*. This thread
> will stay open *up to August 13rd*, and the voting will be following
> shortly after.
>
> *FAQ:*
> Q: Who can be nominated?
> A: Anyone! The secretaries of the PHP-FIG are basically administrative
> clerks and community handlers. For more details, see
> https://www.php-fig.org/bylaws/mission-and-structure/#secretaries
>
> Q: Who can nominate?
> A: Citing the bylaw: "Candidates for Secretary or the Core Committee must
> be nominated/proposed by an existing Project Representative or FIG
> Secretary to be considered, and must publicly accept their nomination in
> order to be valid. Prospective candidates may seek nominations in any way
> they see fit."
>
> Feel free to reach out to me, the other two secretaries (Asmir & Buster)
> or any other sitting PHP-FIG member to ask for a nomination or for further
> informations.
>
> --
> 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/64c91a3e-7a15-411b-a8da-a1604951f454n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnverOsn2-Rw-mVJBmmi%3DsBCST2eY_crgqaDSc3bKd8O0g%40mail.gmail.com.

Re: [VOTE][CC] Errata bylaw update

[Chuck Burgess]

+1

On Thu, Jul 9, 2020, 03:46 Alessandro Lai 
wrote:

> Since the mandatory two weeks are passed on the discussion (
> https://groups.google.com/g/php-fig/c/CObJmc5jDcE), I'm hereby calling a
> CC vote for this bylaw change.
>
> As always, quorum is 50%, majority 2/3.
> Vote will end July 23rd, 23:59:59 UTC.
>
> THIS THREAD IS FOR CORE COMMITTEE VOTES ONLY
>
> --
> 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/718c7275-04ae-4e60-a4ec-6330cd893ed0n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntP7qNZ_z%2B97rZ-pzrikoMD9DamPqWNOm9_z%3D_yNwi7wg%40mail.gmail.com.

Re: [VOTE][CC] TYPO3 Membership vote

[Chuck Burgess]

+1

On Fri, Jul 3, 2020, 02:16 Alessandro Lai 
wrote:

> This thread is to collect votes on the TYPO3 Membership vote.
>
> Details:
>  - membership request:
> https://groups.google.com/d/topic/php-fig/qDOyOuLuoKc/discussion
>  - proposed project representative: Benni Mack, which is project lead
>  - request sponsored by Matteo Beccati 2 weeks ago:
> https://groups.google.com/d/msg/php-fig/qDOyOuLuoKc/HtwMXZ_jBgAJ
>
>
> Quorum: 50%
> Majority: 50%
> https://www.php-fig.org/bylaws/voting-protocol/#membership-vote
>
> ONLY CORE COMMITTEE MEMBERS CAN VOTE HERE
>
> --
> 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/cf05addb-2600-483c-ae7c-8766cf6f27c2o%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnuSHX43FJ84x4ScOjDZZdKQPg8TmbPh9RiMk6Hk_00seg%40mail.gmail.com.

Re: PSR Evolution, PSR-13, and nuance

[Chuck Burgess]

A lengthy Slack discussion brought us to the thoughts that:

* both the *string* typehint and the *static* return type issues should 
make us wait until *PHP8* to incorporate those changes in the PSR interfaces

* at a minimum, in PHP7, this would mean doing the previously proposed 
typehint upgrade *without* *string*, followed by the return type upgrade 
*without* *self*/*static*... and then a *third* upgrade in *PHP8* to do 
*string* typehints and *static* return types

* though some might choose to do the typehint upgrade without *string* pre-
*PHP8*, potentially many would then wait until *PHP8* to do *one* return 
type upgrade that included *static*... with *string* typehints conveniently 
tagging along

* with *PHP8* scheduled for later this year, maybe it's cleaner to *just 
wait on all PSR upgrades* until *PHP8*, so that no special treatment is 
required in the upgrades


Again, it is the headaches from the *string* typehints (and its *Stringable* 
entanglements) 
along with the *static* return (the proper choice for the earlier *self* use 
cases) that makes it problematic to include these two in *PHP7*.

What does everything think about going with the overall *wait-for-PHP8* 
approach?
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/930707db-1ce7-4050-bc8e-1f846893362b%40googlegroups.com.

Re: PSR Evolution, PSR-13, and nuance

[Chuck Burgess]

I'll second Korvin's pair of "BC" choices.
CRB

On Friday, March 6, 2020 at 7:17:26 PM UTC-6, Korvin Szanto wrote:
>
>
>
> On Mon, Mar 2, 2020 at 9:00 AM Matthew Weier O'Phinney <
> mweiero...@gmail.com > wrote:
>
>>
>>
>> On Sun, Feb 23, 2020 at 1:58 PM Larry Garfield > > wrote:
>>
>>> OK, this has been sitting far too long now.  Mostly my fault, but no one 
>>> else seems to be pressing the issue, either...
>>>
>>> Background: Back in December I filed a pair of PRs to update PSR-13 to 
>>> use type hints, per the recently-passed evolution bylaw.  I figured it 
>>> would make a good test case to flush out edge cases, and I was right.
>>>
>>> PRs:
>>> https://github.com/php-fig/link/pull/6
>>> https://github.com/php-fig/link/pull/7
>>>
>>> From the discussion here, there, and elsewhere (musical references FTW), 
>>> I've identified two primary concerns that should be *globally* resolved for 
>>> any spec updating in this fashion, not just PSR-13, although PSR-13 is the 
>>> case in point.
>>>
>>> 1) string parameters are a potential BC break in strict mode; does that 
>>> require a v2 rather than v1.1?
>>>
>>> This is an issue that Symfony ran into when upgrading some of its own 
>>> libraries, and prompted the "Stringable" RFC from Nicolas for PHP 8. (cf 
>>> https://wiki.php.net/rfc/stringable, currently in voting as I write 
>>> this, and seems likely to pass but not overwhelmingly.)
>>>
>>> The specific issue is that if a method takes an untyped string 
>>> parameter, right now that implicitly means `string` or "object with 
>>> __toString"... at least most of the time.
>>>
>>> If it is typed `string`, then in weak mode it means the same, although 
>>> the object will get cast to a real string at call time rather than sometime 
>>> later; in strict mode, a Stringable object is no longer allowed.  That 
>>> means a nominal API change, which should necessitate a new major of the 
>>> interface package (v2, not v1.1).  (According to Nicolas on the PHP 
>>> Internals News podcast (https://phpinternals.news/39), Symfony missed 
>>> this implication originally and inadvertently broke Drupal, which was 
>>> passing a stringable object to a method to which they'd added a string type 
>>> hint.  That was the impetus for the Stringable RFC.)
>>>
>>> Example (try flipping the declare statement on and off):
>>>
>>> https://3v4l.org/0dpsJ
>>>
>>> It's been pointed out that since by design an implementation can 
>>> continue to omit the parameter type, it's a BC break by the implementer, 
>>> not the spec, and thus the spec has only a non-breaking change and can be a 
>>> 1.1.  I disagree; for one, I don't expect most implementers to be thinking 
>>> of that sort of nuance.  Honestly I likely wouldn't until it tripped 
>>> someone up.  For another, we *want* implementers to be, in the long run, 
>>> fully implementing the spec and not dropping random parameters, even if the 
>>> language allows it.  That would result in some implementations accepting 
>>> stringable objects and others not, which is directly contrary to the goal 
>>> of interoperability.
>>>
>>
>> I disagree with this analysis.
>>
>> If the specification indicates that an argument should be a string, then 
>> passing anything other than a string for that argument is an error on the 
>> part of the user. If the particular implementation allows it, then that 
>> implementation is coded incorrectly.
>>
>> While I understand and appreciate the issue that Symfony has experienced, 
>> I'd argue that their change to use strict_types fixed an issue with their 
>> code, and Drupal then discovered they were incorrectly consuming the 
>> Symfony API. If Symfony type-hinted as "string", but allowed non-strings 
>> previously, this change is a bugfix. Yes, Drupal is left needing to change 
>> their code after a minor release, but they should have been using it 
>> correctly previously, and either casting to string ((string) $value) or 
>> calling the object's `__toString()` method.
>>
>> Yes, PHP has allowed munging types when undefined or in weak mode. 
>> Generally speaking, if the type is important, the implementation should:
>>
>> - when untyped, check the type explicitly
>> - when weakly typed, assume that the consumer is casting
>> - when strictly typed, require the consumer to cast
>>
>> It's that second point where I can see the potential argument around 
>> "well, PHP will cast objects that define __toString()"; that is in fact 
>> exactly what happens when an object defining __toString is encountered when 
>> passed to a parameter defining a string typehint when strict_types is not 
>> enabled. That said, _doing so is counter to the type hint_, and even your 
>> IDE will tell you there's an error (e.g., intelephense raises "Expected 
>> type 'string' Found '{Object type}'"); as a consumer, you shouldn't rely on 
>> PHP's value munging _as you cannot know that strict_types is NOT enabled_, 
>> unless your tests pass without munging. And even then, 

Re: Easy object based relational php database system that saves data to files only needing 1 file (the library php file)

[Chuck Burgess]

You continue to send more emails on a topic not relevant for this forum,
even after being told it is not relevant.  This moves from being incorrect
behavior to being unwelcome behavior.

Repeated, unwelcome emails are spam.

Developers that are interested in libraries **know how to search for
libraries**.  So your own argument for sending these emails is not
convincing.

I'm afraid that I have to second the motion to block this sender if our
bylaws allow it.
CRB


On Sat, Mar 21, 2020, 07:44 Kristjan Robam  wrote:

> I am not spamming. I upladed a new php library, that many people would
> need.
> I also removed one unneccessary comment.
>
> Kristjan Robam
> E-mail: rob am man 2020 @ hot mail . com
>
> reede, 20. märts 2020 18:23.14 UTC+2 kirjutas Alessandro Lai:
>>
>> Kristjan,
>> as a moderator, I'm officially asking you to stop spamming this list.
>> This is not the place to publicize a personal library. Places like
>> www.reddit.com/r/php are best suited for this kind of communications.
>>
>> I'll delete or block further messages of this kind.
>>
>> Il giorno venerdì 20 marzo 2020 16:07:15 UTC+1, Kristjan Robam ha scritto:
>>>
>>> I am building new libraries, that can help people.
>>>
>>> Meanwhile I have taken off the unneccessary comments.
>>>
>>>
>>> Kristjan Robam
>>>
>>>
>>> reede, 20. märts 2020 15:40.46 UTC+2 kirjutas Larry Garfield:

 Kristjan,

 This is really not what this list is for.  This is for working on
 inter-project collaboration and standards, not a blow by blow of a new
 library you're building.  Please stop spamming the list.

 --
   Larry Garfield
   la...@garfieldtech.com

 On Fri, Mar 20, 2020, at 8:39 AM, Kristjan Robam wrote:
 > Took off unneccessary testing purpose echoes.
 >
 >
 > Kristjan
 >
 >  --
 >  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...@googlegroups.com.
 >  To view this discussion on the web visit
 >
 https://groups.google.com/d/msgid/php-fig/718e0eaa-836b-4dd3-91a3-394285992422%40googlegroups.com
 <
 https://groups.google.com/d/msgid/php-fig/718e0eaa-836b-4dd3-91a3-394285992422%40googlegroups.com?utm_medium=email_source=footer>.

 > Attachments:
 > * easyphpdb.php

>>> --
> 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/68f29d90-750a-4f80-bd85-cf94204bed64%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnt__cSO8sSgtUi7X2vt9Y%2BSA7Ruiruk9Hdf9Yx_zKed1Q%40mail.gmail.com.

Re: [VOTE] Core Committee Election

[Chuck Burgess]

 1. Enrico Zimuel
 2. Massimiliano Arione
 3. Korvin Szanto
 4. Chris Tankersley
 5. Ben Edmunds

On Fri, Jan 10, 2020, 02:42 Alessandro Lai 
wrote:

> Hello everyone,
> as specified in the previous thread (
> https://groups.google.com/d/topic/php-fig/te-IAmuZte0/discussion),
> yesterday at midnight UTC the nominations ended, and since today it's
> possible to vote for the renewal of the terms that are up for this
> elections.
>
> We have *4 spots on the Core Committee* up for reelection; we also have
> one full-term spot for secretary but, since we have only one unopposed
> nomination for the secretary election, we will need to vote for the Core
> Committee positions only, for which we have five nominations (listed in
> chronological order of nomination):
>
>  - Enrico Zimuel:
> https://groups.google.com/d/topic/php-fig/G9O263am5Bs/discussion
>  - Massimiliano Arione:
> https://groups.google.com/d/topic/php-fig/CXS_djlzI6E/discussion
>  - Korvin Szanto:
> https://groups.google.com/d/topic/php-fig/suq1VFu3N8Y/discussion
>  - Chris Tankersley:
> https://groups.google.com/d/topic/php-fig/O-qPhtb3li4/discussion
>  - Ben Edmunds:
> https://groups.google.com/d/topic/php-fig/xk6cHWzOr6s/discussion
>
> Full information about the Core Committee vote and role is visible in the
> bylaws here:
> https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee
>
> *Who can vote?*
> As specified in the bylaws, any Project Representative or any participant
> in the PHP-FIG ML can vote on the CC elections. A ML participant is defined
> in the bylaws as follows:
> "Any individual that has posted a non-trivial message in the official
> PHP-FIG venue (mailing list, forum, etc.) at least five (5) times within
> the past calendar year as of the start of nominations [...] is eligible to
> vote on Core Committee candidates."
>
> *When can you vote?*
> Voting will be open in this thread until January 23rd 23:59:59 UTC.
>
> *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
>
> At the end of the voting phase I will be announcing the results, and all
> the newly elected (both CC members and secretary), as announced before.
> Thanks!
>
> Alessandro Lai
> PHP-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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/c9f56a7f-adf7-4b31-b5a9-65635560d104%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntf8gjm_kORdJMEh2%2BR7qu9xDRTK3UDSGiztyXr0_eFMw%40mail.gmail.com.

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

[Chuck Burgess]

Ah, then ignore my PEAR vote as well...
CRB

On Wed, Nov 13, 2019, 03:11 Alessandro Lai 
wrote:

> Matthew's and Matteo's votes are to be ignored, since they already voted
> as CC members.
>
> Il giorno mercoledì 13 novembre 2019 10:05:16 UTC+1, Matteo Beccati ha
> scritto:
>>
>> +1 from Revive Adserver
>>
>> On 11/11/2019 10:49, Alessandro Lai wrote:
>> > 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
>> > following our Voting Protocol:
>> >
>> > https://www.php-fig.org/bylaws/voting-protocol/
>> >
>> > THIS THREAD IS FOR VOTES OF PROJECT REPRESENTATIVES ONLY; 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 no 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/fc771d51-13e8-411f-8b0e-eae400f92897%40googlegroups.com
>> > <
>> https://groups.google.com/d/msgid/php-fig/fc771d51-13e8-411f-8b0e-eae400f92897%40googlegroups.com?utm_medium=email_source=footer>.
>>
>>
>>
>> --
>> Matteo Beccati
>>
>> Development & Consulting - http://www.beccati.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/b38d2167-2a86-49dd-a14e-1c3378e2b0d2%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnvdoG8%3DhTB-XEwLetGvvbPpnR5KwucD8W%2BeQqCm-4UGMw%40mail.gmail.com.

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

[Chuck Burgess]

+1 from PEAR

On Mon, Nov 11, 2019, 03:49 Alessandro Lai 
wrote:

> 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 following our
> Voting Protocol:
>
> https://www.php-fig.org/bylaws/voting-protocol/
>
> THIS THREAD IS FOR VOTES OF PROJECT REPRESENTATIVES ONLY; 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 no 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/fc771d51-13e8-411f-8b0e-eae400f92897%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnvZhc%3D_HRCYYsPHE5kBi3iMMfaj%2BSrjsRMeTFA52AD6WA%40mail.gmail.com.

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

[Chuck Burgess]

+1

On Mon, Nov 11, 2019, 03:48 Alessandro Lai 
wrote:

> 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/c2879540-00c4-4dcd-b4d9-6c4fba50c8fc%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnsQtPGRE%2BvfmNDj0dq_xWCYzCQiVems62tf9%2Bu1cb2VEA%40mail.gmail.com.

Re: A question about PSR-12

[Chuck Burgess]

Ah, then I was way off... I thought this was about union typing in a
docblock 臘‍♂️

On Sun, Sep 22, 2019, 11:32 Korvin Szanto  wrote:

> PHP 7.1 added exception multicatch using a single pipe operator, so no we
> wouldn't want to use an OR operator here
>
> https://www.php.net/manual/en/language.exceptions.php
>
> On Sun, Sep 22, 2019, 8:49 AM Chuck Burgess  wrote:
>
>> That's not a pipeline from code... it's only an OR delimiter in the
>> pseudo code of documenting.
>> CRB
>>
>> On Sun, Sep 22, 2019, 10:47 Memo Chou 
>> wrote:
>>
>>> Hi, everyone!
>>>
>>> This is a part of PSR-12.
>>>
>>> Can anybody tell me why use pipeline here? Is it should be an "or"(||)?
>>>
>>> OtherThrowableType | AnotherThrowableType
>>>
>>> Thanks!
>>>
>>> [image: 螢幕快照 2019-09-22 下午11.45.00.png]
>>>
>>> --
>>> 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/3ad8cf97-5a9a-4529-b4ee-06be47177e18%40googlegroups.com
>>> <https://groups.google.com/d/msgid/php-fig/3ad8cf97-5a9a-4529-b4ee-06be47177e18%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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/CANsgjnu37K3_%3DuBSCDJJ%3D1UFHRr87kvGAQ%3Dg3g0axCiTyUQCKA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/php-fig/CANsgjnu37K3_%3DuBSCDJJ%3D1UFHRr87kvGAQ%3Dg3g0axCiTyUQCKA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CANeXGWVgcj_ymuiLX92_g%3D%2Bb1qGbdwEPiFd71pu7ZJuTq1D9MA%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CANeXGWVgcj_ymuiLX92_g%3D%2Bb1qGbdwEPiFd71pu7ZJuTq1D9MA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANsgjntKBOEfituw3m%2BbwFzX7_WB3DCcV%2BgfOPczd8BagC6byg%40mail.gmail.com.

Re: A question about PSR-12

[Chuck Burgess]

That's not a pipeline from code... it's only an OR delimiter in the pseudo
code of documenting.
CRB

On Sun, Sep 22, 2019, 10:47 Memo Chou  wrote:

> Hi, everyone!
>
> This is a part of PSR-12.
>
> Can anybody tell me why use pipeline here? Is it should be an "or"(||)?
>
> OtherThrowableType | AnotherThrowableType
>
> Thanks!
>
> [image: 螢幕快照 2019-09-22 下午11.45.00.png]
>
> --
> 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/3ad8cf97-5a9a-4529-b4ee-06be47177e18%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjnu37K3_%3DuBSCDJJ%3D1UFHRr87kvGAQ%3Dg3g0axCiTyUQCKA%40mail.gmail.com.

Re: [VOTE] [Accept] PSR-12 Extended Coding Style Guide

[Chuck Burgess]

+1

On Mon, Aug 5, 2019, 10:53 Samantha Quiñones 
wrote:

> +1
>
> Very exciting stuff!
>
> --
> 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/4bf9d77c-41a5-41c8-af6b-db7a1beb5855%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CANsgjntmGdEu5f8dfW5pMkLTw8Yfw6-kQU7roScuUrFRUpxV1A%40mail.gmail.com.

Re: [VOTE] Core Committee Election

[Chuck Burgess]

>From PEAR:

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

CRB
*about.me/ashnazg *


On Sun, May 5, 2019 at 4:48 PM Alessandro Lai 
wrote:

> Hello everyone,
> as specified in the previous thread (
> https://groups.google.com/d/topic/php-fig/SSGn1VJtOJs/discussion),
> yesterday at midnight the nominations ended, and since today it's possible
> to vote for the renewal of the terms that are up for this elections.
>
> We have *5 spots on the Core Committee* up for reelection, four with a
> full two year term and a shorter one, that will end in August 2020, due to
> Lukas stepping down; we also have one full-term spot for secretary.
> Since we have only one unopposed nomination for the secretary election, we
> will need to vote for the Core Committee positions only, for which we have
> seven nominations (listed in chronological order of nomination):
>
>  - Woody Gilk
> https://groups.google.com/d/topic/php-fig/DaoLQAiykpc/discussion
>  - Larry Garfield
> https://groups.google.com/d/topic/php-fig/HqtrPuUI_YQ/discussion
>  - Adam Englander
> https://groups.google.com/d/topic/php-fig/3TjKW8MmBks/discussion
>  - Matthew Weier O'Phinney
> https://groups.google.com/d/topic/php-fig/PAnOZqE4QiQ/discussion
>  - Matteo Beccati
> https://groups.google.com/d/topic/php-fig/Mahn59nAmbU/discussion
>  - Beau Simensen
> https://groups.google.com/d/topic/php-fig/v1cPGmMT430/discussion
>  - Benni Mack
> https://groups.google.com/d/topic/php-fig/wVIhtZNVgmM/discussion
>
> Full information about the Core Committee vote and role is visible in the
> bylaws here:
> https://www.php-fig.org/bylaws/mission-and-structure/#the-core-committee
>
> *Who can vote?*
> As specified in the bylaws, any Project Representative or any participant
> in the PHP-FIG ML can vote on the CC elections. A ML participant is defined
> in the bylaws as follows:
> "Any individual that has posted a non-trivial message in the official FIG
> venue (mailing list, forum, etc.) at least five (5) times within the past
> calendar year as of the start of nominations [...] is eligible to vote on
> Core Committee candidates."
>
>
> *When can you vote?*
> Voting will be open in this thread until May 19th 23:59 UTC.
>
> *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
>
> At the end of the voting phase I will be announcing the results, and all
> the newly elected (both CC members and secretary), as announced before.
> Vote ordering will be also used to assign the terms, so the last of the
> elected will take the shorter one.
>
> Thanks!
>
> Alessandro Lai
> PHP-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/9e1624fa-b968-43c6-923f-5d507774703e%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/CANsgjnsoxhLEe0%3DVHh0_1p2ZEAAdNA3uD0Z0jBU9AKPgT2Du_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [INTERNAL] Core Committee & Secretary nominations open

[Chuck Burgess]

I nominate Sara Goleman for another CC term, if she's willing.
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/CANsgjnvebBiVtq1%2BXMUR5V7u5c29wg-GyfauoK9YK18yBhtXEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [INTERNAL] Core Committee & Secretary nominations open

[Chuck Burgess]

I nominate Margaret Staples for another Secretary term, if she's willing.
CRB

On Mon, Apr 8, 2019, 05:56 Alessandro Lai 
wrote:

> Hello everyone,
> May is approaching, and since it's the designated month for the next
> election cycle, we need to get started on nominations!
>
> This time we have 5 seats up which are expiring:
>
> Secretary:
>  - Margaret Staples (@dead_lugosi)
>
> Core Committee:
>  - Beau Simensen (@beausimensen)
>  - Larry Garfield (@Crell)
>  - Matthew Weier O’Phinney (@mwop)
>  - Sara Golemon (@SaraMG)
>
> We also have one CC member who wants to step down, Lukas Kahwe Smith, due
> to lack of time to dedicate to the role.
>
> I would like to take the chance to thank all of them for their help and
> work inside the PHP-FIG during their terms. Thank you!
>
> 
>
> Ok, now it's nominations time! If you are willing to step up for this
> election cycle, even for those that are seeking to be re-elected, please
> seek a nomination as required by our bylaws:
> https://www.php-fig.org/bylaws/elections-and-vacancies/#nomination
>
> If you're interested but you want more details on the roles, look up to
> the bylaws and feel free to contact one of the secretaries or the current
> CC members.
> *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.
>
> *Nominations close on May 5th 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 PHP-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 PHP-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 PHP-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
>
> However, it is important to note that you are voting for people, not
> projects, so please do not vote in people because they are the lead on
> 'Project X'; but rather you might vote for them because they have
> experience as a framework maintainer or legacy project maintainer and
> therefore have a different view on things. CC members should be
> representing the opinion of the wider PHP ecosystem and community as CC
> members, not of projects they are affiliated with, and some will likely not
> be affiliated with any project at all. Furthermore, this should not become
> a popularity contest of 'who is the most well known' but who would make the
> most well-balanced core committee that accurately represents the interests
> of you, the member projects and wider PHP community.
>
>
> *What's the timetable?*
> April 8th: Nominations open
> May 5th: Nominations close
> May 6th: Election voting begins
> May 19th: voting ends
> May 26th: new CC members 

Re: PSR-19. inline @see tag

[Chuck Burgess]

Correct... things were being pared out of the doc initially, in an attempt
to get consensus on a minimum baseline of items.  Restoring some things
would follow, as well as potential new things.
CRB

On Thu, Apr 18, 2019, 14:55 Joe T.  wrote:

> Hopefully this is just part of the early draft process and more work will
> be done to fully detail the already supported functionality to make it part
> of the standard. i'd hate to see existing features omitted from the PSR.
> That basically means phpDoc has two options:
>
>1. Drop functionality many people find useful.
>2. Ignore the PSR, defeating its purpose.
>
>
> -jlt
>
>
>
> On Thursday, 18 April 2019 15:30:53 UTC-4, Google user wrote:
>>
>> in phpdocumentor's phpdoc documentation it's stated that @see tag does
>> have inline syntax:
>>
>>> Syntax
>>> @see [URI | FQSEN] []
>>> or inline
>>> {@see [URI | FQSEN] []}
>>> http://docs.phpdoc.org/references/phpdoc/tags/see.html#syntax
>>
>>
>> why does psr-19 omits it?
>>
>>> Syntax
>>> @see [URI | "FQSEN"] []
>>>
>>> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#syntax-11
>>
>>
>> imo, this is very useful feature, i'm convinced it should be allowed
>>
>> what is the reason to exclude it from standard?
>>
> --
> 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/215b9c56-a9a0-45b6-a64c-040016c0d165%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/CANsgjnsmEYSHYVAj70P%2BwyDo%3DpBnvak%3DRhXTWC%3DGixyoq1TJcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Chuck Burgess]

+1

CRB

On Sun, Mar 10, 2019, 13:31 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/b46fe9d1-0290-4b31-9629-03ffe109b709%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/b46fe9d1-0290-4b31-9629-03ffe109b709%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/CANsgjntskrXy0H9To37uCLK8dp%3DsvkVECGmy_29-%3DX932MtNLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-14 Event Dispatcher

[Chuck Burgess]

LGTM... my only feedback was my corrections PR --
https://github.com/php-fig/fig-standards/pull/1149
I'm also good with both of these being applied:
https://github.com/php-fig/fig-standards/pull/1152
https://github.com/php-fig/fig-standards/pull/1153

CRB
*about.me/ashnazg *


On Thu, Feb 21, 2019 at 2:33 PM Larry Garfield 
wrote:

> On Wed, Jan 30, 2019, at 12:31 PM, Cees-Jan Kiewiet wrote:
> > Yes 27th of February 2019 is the correct deadline.
> >
> > On Wed, Jan 30, 2019 at 7:17 PM Girgias 
> wrote:
> > > The review period deadline needs to be changed. The 27th of Jan 2019
> was two days ago.
> > > Did you mean 27th of February 2019?
> > >
> > > Best regards
> > >
> > > George P. Banyard
> > >
> > >
> > > On Wed, 30 Jan 2019 at 19:05, Cees-Jan Kiewiet 
> wrote:
> > >> As of today, with a unanimous vote from the working group, we
> formally begin the REVIEW phase of the proposed PSR-14 (Event Dispatcher)
> 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/event-dispatcher.md
> > >> - Metadocument:
> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md
> > >>
> > >> During the Review phase, acceptable changes to the specification
> include wording, typographical fixes, and clarifications. If you feel major
> changes are necessary or have, please bring your arguments/questions 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 27 Jan 2019 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.
> > >>
> > >> Cees-Jan Kiewiet, your friendly neighbourhood PSR-14 Sponsor
>
> Core Committee members: How shall the WG interpret your silence? :-)  As
> approval or indifference?
>
> If approval, please let us know that you're approving so we know not to
> worry when it comes time to call a vote. :-)
>
> Beuller?
>
> --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/ac14ce13-e39b-4227-b9d7-68c7ef6bd834%40www.fastmail.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/CANsgjnts%2BVHR_9XcYutRCRKmMHJ%3DY5t6kV0hq5Stu8SV9q%2BryA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Adopt Code Manifesto

[Chuck Burgess]

Looking over both the manifesto and the covenant, I didn't really notice
anything that would conflict between the two, if we wanted to simply
include *both*... doing so would just be presenting an intersection of
their requirements.  Is that too much verbiage overall?  Maybe just link to
both, since they are standalone entities (that seem to be versioned, or at
least versionable)?  Stating that we want to abide by both, then
delineating how those in FIG positions can act to enforce, ... maybe that
would cover the concerns mentioned?
CRB
*about.me/ashnazg *


On Thu, Jan 24, 2019 at 7:54 AM Larry Garfield 
wrote:

> On Wed, Jan 23, 2019, at 1:58 PM, Lukas Kahwe Smith wrote:
> >
> > On Wed, 23 Jan 2019 at 20:42, Matthew Weier O'Phinney
> >  wrote:
> > >
> > >
> > > On Wed, Jan 23, 2019 at 2:49 AM Lukas Kahwe Smith <
> sm...@pooteeweet.org> wrote:
> > >> On Wed, Jan 23, 2019 at 1:17 AM Larry Garfield <
> la...@garfieldtech.com> wrote:
> > >>  >
> > >>  > Greetings, FIGians.
> > >>  >
> > >>  > This has been bounced around in back channels on and off for a
> while, so I think it's finally time to make it official. I propose that we
> officially adopt the Code Manifesto[1] as our official standard of behavior.
> > >>  >
> > >>  > Specifically, as follows:
> > >>  >
> > >>  > https://github.com/php-fig/fig-standards/pull/1143
> > >>  >
> > >>  > WHY?
> > >>  >
> > >>  > First off, I want to be clear that I am NOT making this
> recommendation in response to any current issue. I am not aware of any
> current issue that would require invoking or even discussing invoking the
> guidelines listed here. FIG has been delightfully boring in that regard for
> quite some time and, "good lord willin' and the creek don't rise", it will
> stay that way.
> > >>  >
> > >>  > That of course is the best time to discuss such matters, as they
> can be looked at from a reasonably objective and dispassionate perspective.
> The definition of expected behavior of current official FIG members is
> quite vague and wishy washy (by design), and having clearer up-front
> expectations is good should the need ever arise.
> > >>  >
> > >>  > WHY THE MANIFESTO?
> > >>  >
> > >>  > A number of organizations and projects have of late adopted the
> "Contributor Covenant" as their code of conduct. My concern with the
> Covenant is that it is a very negative document; in contrast, the Manifesto
> provides guidelines of good behavior rather than an enumeration of bad
> behavior. In my experience, a positive document tends to encourage the
> desired behavior better than a negative one.
> > >>
> > >>  We had a brief discussion on this point via IRC a few days ago. While
> > >>  such a document is a very small step forward, I personally think that
> > >>  the manifesto lack of naming problematic behavior is its biggest
> > >>  weakness, since it does very little to assure people that you are
> > >>  willing to name problematic behavior when it occurs, when you cannot
> > >>  even do so in the rules you publish.
> > >>
> > >
> > > I tend to agree with Lukas here, and have a bit of background to share.
> > >
> > > A few years ago, Zend Framework adopted Code Manifesto to govern our
> projects, for many of the same reasons Larry has stated: we like the
> emphasis on positive guidelines of acceptable behaviour over an enumeration
> of punishments for bad behaviour.
> > >
> > > In practice, it's been problematic, for a number of reasons.
> > >
> > > When unacceptable behaviour is observed, there's no clear contact to
> report to. This leaves people either waiting and hoping somebody will step
> in, or leaving the conversation to avoid the person.
> > >
> > > Additionally, when somebody does step in (generally somebody with
> moderation rights in whichever community forum the interactions are
> occurring on), there's then questions:
> > >
> > > - What behaviour was observed? How is it against the code?
> > > - What direction should be provided to the user to prevent future
> issues?
> > > - Is banning necessary? If so, how long? Should it ever be permanent?
> > >
> > > Essentially, a code without an explicit process for calling out
> violations and dealing with them makes addressing problems entirely
> subjective and at the whim of those with moderation powers.
> > >
> > > In terms of reporting, reporting MUST be able to be done anonymously,
> to prevent retribution by the accused against the accuser; people who abuse
> the rules are simply more likely to retaliate. Without this, members of the
> community have no safe way to report that prevents further abuse.
> > >
> > > In sum: I love the Code Manifesto as a guideline for how people
> > should interact within the community. However, it's not a code of
> > conduct; a code of conduct needs to outline the specific behaviours
> > that will trigger actions, how to report these safely, and what actions
> > may be taken. These are required to ensure a safe and fair process.
> > for a 

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

[Chuck Burgess]

Yes, out of scope, at least here at the beginning.  Once we get a baseline
draft covering the minimal "already in use old stuff" covered, I'm
expecting us to open up topics on "new stuff" to add, generics included.
Not that I'm convinced we'll get that one nailed down to enough agreement
that we can for sure include it in this round of PSRs... my point is only
that I wish to not let such a future/forward looking discussion derail the
rest of the PSR content.
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Mon, Dec 10, 2018 at 9:41 PM Jan Tvrdík  wrote:

> Yes, it needs generics syntax, making it currently intentionally
> out-of-scope.
> If you don't mind ugly hacks with unclear semantics that may stop working
> in the future, you can also use `iterable|User[]`.
>
>
> On Saturday, December 8, 2018 at 9:44:14 PM UTC+1, Chuck Burgess wrote:
>>
>> I'm thinking this use case will probably need to rely on some kind of
>> collection/generics syntax.  Do we know if PhpStorm / PHPStan / etc have
>> looked at syntaxes for this use case?
>> CRB
>> *about.me/ashnazg <http://about.me/ashnazg>*
>>
>

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

Re: Test dependencies in the psr/log package??

[Chuck Burgess]

At first glance, I think I'm good with moving this out to a log-util
package, with perhaps a bump to v1.2.  Adjusting testcases has never really
urged me into being concerned about versioning, at least when working in my
packages.  The BC extent of anyone actually depending on these for their
own tests should just be a `require` section adjustment in their
`composer.json`, right?  Namespacing of our other util packages that I
spot-checked look like they stick to the namespace of the PSR interfaces
that they tie back to, so these classes in the util package would keep
their current namespace.
CRB
*about.me/ashnazg *


On Tue, Dec 11, 2018 at 5:23 AM Rasmus Schultz  wrote:

> As I've noted on the PR thread:
>
> Introducing the test facilities in the first place was a "bug", and fixing
> it will break tests only.
>
> Versioning that fix as a major is wrong, since there are no breaking
> changes to the library itself.
>
> If you're very concerned about breaking somebody's tests, you could do a
> minor release some months earlier with deprecations for these facilities
> and a note stating the date by which they will be removed.
>
> Versioning the removal as a major will create an endless cascade of
> dependency issues for something that doesn't affect production code.
>
> Please no.
>
> On Tue, Dec 11, 2018, 09:33 Alessandro Lai  wrote:
>
>> Sorry for adding this with so much little notice. I added that since the
>> other one was already present, and that wouldn't change the number of
>> implicit dependency on that package.
>>
>> Obviously not using that class will not trigger any issue, but removing
>> that now would be a BC, so I'm against doing that: breaking SemVer would be
>> a very bad example here.
>>
>> I'm all for splitting it into a separate package, but I would like the CC
>> input on this, since my previous action seems to be debatable. In any case,
>> this would require a 2.0 of psr/log, but I fear that that change would
>> scare a lot of people... Even the 1.1 ruffed some feathers!
>>
>> Il giorno venerdì 7 dicembre 2018 20:23:42 UTC+1, Larry Garfield ha
>> scritto:
>>>
>>> On Friday, December 7, 2018 10:19:45 AM CST Rasmus Schultz wrote:
>>> > I noticed the introduction of two PHPUnit-specific test-dependencies
>>> into
>>> > the psr/log package:
>>> >
>>> > https://github.com/php-fig/log/tree/1.1.0/Psr/Log/Test
>>> >
>>> > How is this in any way acceptable?
>>> >
>>> > The dependency isn't even declared in the "composer.json" file - but
>>> that's
>>> > kind of besides the point.
>>> >
>>> > First of all, PHPUnit isn't PHP - introducing facilities for a
>>> specific
>>> > test-framework is extremely opinionated and does not belong in an
>>> package
>>> > with interfaces designed to bridge projects and provide
>>> interoperability
>>> > between different frameworks. (PHPUnit being a test-framework.)
>>> >
>>> > Moreover, these facilities aren't a dependency, at all - you can use
>>> this
>>> > package just fine without it. There is no rational reason not to
>>> package
>>> > these dependencies separately.
>>> >
>>> > These facilities belong in a different package that depends on
>>> psr/log, so
>>> > you can version them separately. Stuffing these into the package
>>> itself is
>>> > extremely controversial and could create a serious problem with
>>> versioning.
>>> > (having to version the interfaces as 2.0 for a breaking change to the
>>> > test-facilities!)
>>> >
>>> > I'm calling for a bugfix release to remove these ASAP.
>>> >
>>> > Who's even responsible for this?
>>> >
>>> > There's no issue-tracker on the GitHub project, and I don't see any
>>> > discussion about it in this forum.
>>> >
>>> > wtf?
>>>
>>> One of them has been there for years.  The other was just added recently
>>> with
>>> little notice.
>>>
>>> This has been discussed before, and frankly I agree that the tests
>>> should not
>>> be in the package at all.  We have -util packages for this sort of
>>> thing.
>>>
>>> Related discussion:
>>>
>>> https://github.com/php-fig/log/pull/52#issuecomment-378323725
>>>
>>> --Larry Garfield
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/php-fig/DsmK600GAas/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/ed94acf6-698c-4410-8b10-44dba2f40ef7%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 

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

[Chuck Burgess]

I'm thinking this use case will probably need to rely on some kind of
collection/generics syntax.  Do we know if PhpStorm / PHPStan / etc have
looked at syntaxes for this use case?
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Mon, Nov 12, 2018 at 11:38 AM Woody Gilk  wrote:

> Could we use:
>
> @return iterable
>
> ?
>
> Also generators can return key => value:
>
> @return iterable
>
> Would imply:
>
> yield $key => $user;
>
> --
> Woody Gilk
> https://shadowhand.me
>
>
> On Mon, Nov 12, 2018 at 11:34 AM Larry Garfield 
> wrote:
>
>> On Monday, November 12, 2018 10:06:08 AM CST Chuck Burgess wrote:
>> > So here we do indeed have a special IDE implementation to try to deal
>> with
>> > the OP's kind of use case.
>> >
>> > Again, I can't envision a more standardized way to solve this with tags
>> > themselves.
>> >
>> >
>> > I'll mention this again, with regard to this use case though:
>> > Stepping back a moment... that /* @var */ usage... seems like I've only
>> > ever seen that used to typehint the $item portion of the example, not
>> the
>> > $stream portion... $stream should have been figured out earlier when it
>> was
>> > first populated, either by its own /* @var */ doc or by the return type
>> of
>> > whatever function/method actually populated it.
>> >
>> > Would using the /* @var */ in this manner not solve this use case?
>> > CRB
>> > *about.me/ashnazg <http://about.me/ashnazg>*
>>
>> I agree that, when putting a @var over a foreach, only the $item is
>> really
>> relevant to document.
>>
>> My use case may be tangential/related, as I'm talking more about how to
>> specify "iterable of X" in "the return type of whatever function/method
>> actually populated it".
>>
>> While it would be lovely to say that [] implies any "collection", I don't
>> think PHP will let us do that.  Arrays and iterables are not
>> interchangeable,
>> as there's a few dozen functions that work on arrays but not iterables.
>>
>> To wit:
>>
>> /**
>>  * @return int[]
>>  */
>> function foo() : iterable {
>>
>> }
>>
>> int[] implies "Array of ints", which means calling array_* functions on
>> it is
>> a totally legit thing to do.  But what's returned is an iterable, which
>> means
>> there's no guarantee that it's an array; it could return any Traversable,
>> or
>> foo() could be a generator itself.  In those cases, the docblock is now
>> materially wrong and misleading.
>>
>> I'm not sure what the best solution here is, but I do think we need one.
>>
>> (And that's before we get into the excitement of an iterable that returns
>> non-
>> numeric keys, which is also completely valid, so we have to think about
>> something like Go maps, yeaa!)
>>
>> --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/39547303.NTl641kpUQ%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/CAGOJM6%2BV8Da%3Dc_%3Di2Rq%3D5Vq8uQ6%2BvX7sdnoVeq%2BKZde5of7DEg%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BV8Da%3Dc_%3Di2Rq%3D5Vq8uQ6%2BvX7sdnoVeq%2BKZde5of7DEg%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/CANsgjnvDEC8nN%3DZQWH7A04MYcv51hKj%2BmMrxoJBB8SJTY45giA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-19] Multiline descriptions for @property and @method

[Chuck Burgess]

Something I'd highlight is that the main discussion here revolves around
the specific Description portion of tags, whereas Jan's PR example talks
about multi-lining the Type portion, which is something I don't recall ever
coming across before.

-1 from me on allowing for multi-line Types... this could get hairy trying
to tease out actual Types without colliding with the Description when the
Variable was omitted.
+1 from me on allowing for multi-line Descriptions... this only involved
newlines and whitespace, since the Description is the last piece of the Tag
syntax... and this kind of multi-lining has existed for years.

CRB
*about.me/ashnazg *


On Fri, Dec 7, 2018 at 1:23 PM Larry Garfield 
wrote:

> In practice I don't know how we can not support multi-line tag
> descriptions.
> Many parameter descriptions or return descriptions really do need that
> level
> of detail, and there's hundreds of thousands of examples of it in the
> wild.
> Even many of our own PSRs have multi-line tag descriptions.
>
> It may be hard, but I don't think we can avoid it.  We just need to put
> rules
> around them that make them both parsable and human-comprehensible.  (I
> know,
> "just" in that sentence needs really big scare quotes.  Simple, but not
> easy.
> :-) )
>
> --Larry Garfield
>
> On Friday, December 7, 2018 12:39:11 PM CST Jan Tvrdík wrote:
> > Multiline descriptions for tags are lot more complicated than it may
> > intuitively seem. Writing a grammar that matches behavior that human
> > intuitively expects is very tricky. It's not enough to just say, that
> > multiline descriptions are allowed. For some random examples see
> > https://github.com/phpstan/phpdoc-parser/issues/6#issuecomment-362243651
> .
> >
> > On Thursday, November 15, 2018 at 3:35:45 PM UTC+1, Marcos Passos wrote:
> > > Hello folks,
> > >
> > > I would like to propose standardizing support to multiline
> descriptions in
> > > magic @property and @method annotation. Not allowing it has the impact
> of
> > > having long lines with bad readability and no paragraph support.
> > >
> > > What is your opinion on that?
> > >
> > > - Marcos
>
> --
> 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/1725610.d5TsaTEq9S%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/CANsgjnuKLPR6xPsGJvbPwC312gM0_t02KOfY%3DmZ4c1tVZKbuzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-19 Prevent PHPDoc inheritance

[Chuck Burgess]

I'm -1 on this... it seems too edge casey to me to come up with a new
complex way to handle it.
CRB
*about.me/ashnazg *


On Wed, Nov 28, 2018 at 11:44 AM Miguel Rosales 
wrote:

> (I think I've sent this message to 3 wrong places now - trying again... 臘)
>
> Personally, I think that if a class is an implementation of an interface,
> their methods' docblocks should stick to the interface methods' docblocks
> as they are, because that fits better with the purpose behind using
> interfaces in 1st place, and that's what I always do in my code...
>
> That being said, I'm not sure how you'd implement "eliminating @todo
> entries which aren't applicable to the implementation", because note that
> you can have multiple @todo entries in the interface. How do you identify
> which one is the one you want to eliminate?
> For something like @throws, it's the same thing, although at least you can
> identify each tag by the exception they throw - anyway, you'd need
> something like a new "negation tag" like @not-throws (?), so you can
> override each specific exception that might be defined in the
> implementation... no?
>
> As I said, *personally* I don't consider this an important feature to
> focus on...
>
> El miércoles, 28 de noviembre de 2018, 17:04:31 (UTC), Daniel Hunsaker
> escribió:
>>
>> Reading through this, I couldn't help but think the example was getting
>> in the way of the suggestion, here. There are any number of tags, besides
>> `@throws`, which could benefit from being removed from child
>> implementations without outright replacing them, given the right use cases.
>> Removal of optional parameters. Dropping attributions without providing
>> one's own. Eliminating `@todo` entries which aren't applicable to the
>> implementation. Any of these for an `extends` rather than an `implements`.
>> And so on.
>>
>> I mean, maybe I misunderstood the original suggestion itself, but it
>> seemed like it covered myriad scenarios, rather than just the specific
>> example.
>>
>> - Dan
>>
>> On Mon, Nov 26, 2018, 07:46 Nicholas Ruunu  wrote:
>>
>>> Yeah, that's a valid point.
>>> In PHPStorm you can just overwrite `@throws` with nothing, or with
>>> anything that's not an exception like `-` and it won't squawk.
>>> What about just doing something like that?
>>>
>>>
>>> On 26 November 2018 at 15:16:12, Alexandru Pătrănescu (drea...@gmail.com)
>>> wrote:
>>>
>>> A RemoteStringLoader implementation that will fetch the string from a
>>> remote location and then use StringLoader by composition.
>>>
>>> Alex
>>>
>>> On Mon, Nov 26, 2018 at 3:57 PM Woody Gilk  wrote:
>>>
 On Mon, Nov 26, 2018 at 6:56 AM Marcos Passos 
 wrote:

> Think about a loader interface, that can throw a LoadingException. A
> StringLoader will never throw an exception, and any class tightly coupled
> to it should not care about LoadingException.
>

 In what situation would you have code tightly coupled to the
 implementation instead of the interface?

 --
 Woody Gilk
 https://shadowhand.me

 --
 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+u...@googlegroups.com.
 To post to this group, send email to php...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/php-fig/CAGOJM6JABnTv0%3DO4OCGNUMs_2YPR4pxe%3DBXg1j5%2B2ayNWHgBZg%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+u...@googlegroups.com.
>>> To post to this group, send email to php...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/php-fig/CAAwdEzDXSt7DxNJYDzmA8bTv5nnxxL2jmdOHR2pdXUj2qSbiow%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+u...@googlegroups.com.
>>> To post to this group, send email to php...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/php-fig/etPan.5bfc0739.14709aeb.259%40ruu.nu
>>> 

Re: PSR-19 @triggers tag

[Chuck Burgess]

I'm accustomed to seeing such old-style error behavior wrapped by
exceptions as much as possible, so I'm -1 on the idea.

Working Group / others, thoughts?
CRB
*about.me/ashnazg *


On Mon, Nov 26, 2018 at 5:00 AM Magnar Ovedal Myrtveit 
wrote:

> Would it be interesting to include a @triggers tag in PSR-19? This would
> be used with code that may call trigger_error() or other code that may
> trigger errors, such as filesize(), mime_content_type(), filemtime(),
> md5_file(), pspell_new(), etc. (There are really many!)
>
> Examples would be:
>
> @triggers E_ERROR Some text explaining what might trigger the error.
>
> @triggers E_WARNING Some text explaining what might trigger the warning.
>
> --
> 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/a044b2ab-a22a-4385-9a26-95c2fc1ac121%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/CANsgjnujHCAJd7rSvMYXX7az-8zM-%3DFJONz3JMJW44P3G5D0Pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-5] Intersection Types

[Chuck Burgess]

Yep... that's why I like Larry's suggestion to apply & before | when both
are used.
CRB

On Fri, Nov 23, 2018, 09:55 Matthew Brown  One problem with allowing just one of & or |
>
> The type \Mockery\MockInterface&\Foo\Bar|null should be valid IMO
>
> On Nov 21, 2018, at 7:44 AM, cyrilverl...@free.fr wrote:
>
> Hi everyone,
>
> I have posted this PR and i am sorry i could not participate in this
> discussion earlier.
>
> @CRB, thanks for accepting the PR.
>
> The main reason i did this PR is because PHPUnit adds some methods to a
> mock object and phpstan-phpunit seems to correctly represent the resulting
> object using the intersection operator (&).
> I understand though that having a full algebraic description type may lead
> to complex syntaxes, hard to read codes and hard to create parsers.
> I am all for following PHP as much as possible.
> For now, Alexey's proposition will suffice to me :
>
>> Let's allow only ONE type of operator - "|" or "&" and no braces.
>>
> So the following examples would be allowed :
> @var null|int $foo
> @var Foo&\PHPUnit\Framework\MockObject\MockObject $foo
>
> But not :
> @var null|Foo $object
>
> I am not very familliar with the ABNF grammar, so feel free to correct me.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/php-fig/W1VyAtoqGQ8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/6e76c1be-d793-4ce0-9d60-819045b55d18%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/D3021A22-FD3D-445A-B622-D68CBC07F913%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 
https://groups.google.com/d/msgid/php-fig/CANsgjnueodEkGyxp2YNSDHQ%2BUD8XN%2Bbt2q--zB5rkhSq%3DxfRHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-5] Intersection Types

[Chuck Burgess]

I went ahead and merged in the open PR to include Intersection Types in the
draft.  This PR did not indicate anything with regard to order of
precedence, so anything that develops from this ML thread can be added via
a new PR.
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Tue, Nov 13, 2018 at 8:09 PM Matthew Brown 
wrote:

> I agree that expressions like (A | B) & C should probably not be allowed,
> but I disagree that we should refrain, in principle, from allowing people
> to type their code in docblocks more expressively than PHP allows (in
> supported syntax).
>
> I like that docblocks can go further - it means not having to add runtime
> checks, while having a reasonable degree of confidence (with static
> analysis tools) that your code will work.
>
> On Nov 13, 2018, at 5:48 PM, Miguel Rosales 
> wrote:
>
> A bit late to the party, but just wanted to give a big +1 to Larry's
> comment above - I don't think this feature should be defined in the docs
> when the language itself doesn't allow it, and afaik (may be wrong) there's
> no evidence that it will be supported in the future...
>
> Probably my opinion is influenced by the fact I personally don't like
> union/intersection types - I think in many cases you can avoid them using
> interfaces and/or a bit of refactoring, and if not, there are other
> features that could solve the same problem in better ways (imho anyway)
> e.g. method overloading or even "scalar objects". Adding full support for
> this in a PSR could definitely influence the community in one direction
> that may not the best one...
>
> As a side note, there was a thread about adding more support to generics
> where it was said that that's a language-specific feature out of scope of
> the PSR (which makes perfect sense), and this sounds quite similar to me :)
>
> - I've used the OR | operator a lot, but since PHP7, I always try to rely
> less on phpdoc for typing, and more on the language itself, and in may
> cases when I need to add an OR, I consider a refactoring instead.
>
> El viernes, 19 de octubre de 2018, 13:50:34 (UTC+1), Chuck Burgess
> escribió:
>>
>> Hello everyone,
>>
>> There is a new PR [1] from a contributor, asking for an Intersection Type
>> Operator.  This appears to simply use `&` akin to how `|` is used for Union
>> Types.
>>
>> Neither Unions nor Intersections are (yet) in the language itself, but
>> `string|null` Union Typing in Tags has been in wide usage for a while now.
>> In looking over RFCs on attempts to get these two Type Operators into the
>> language, it seems likely to me that the Operators chosen will be `|` and
>> `&` if they do ever get in.  As such, I'm personally good with the choice
>> of `&` for Intersection Operator for Typing in Tags.
>>
>> Please keep discussion on this request on this ML thread.
>>
>> Chuck Burgess, Editor
>>
>> [1] -- https://github.com/php-fig/fig-standards/pull/1104
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/php-fig/W1VyAtoqGQ8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/d6471893-ece3-4fc6-bc9e-672dffe408ca%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/d6471893-ece3-4fc6-bc9e-672dffe408ca%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/BCC53CCB-E7D8-4CF8-96D4-6F49F3E97138%40gmail.com
> <https://groups.google.com/d/msgid/php-fig/BCC53CCB-E7D8-4CF8-96D4-6F49F3E97138%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/CANsgjnvhwmThx%3D3Eaoy0L3Kpd%2B3BmV_d1j58vJzfeHHyobZt_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-19] Multiline descriptions for @property and @method

[Chuck Burgess]

Not really... in that sense, one could argue that *all* Tags are
"single-line by nature", in that every piece of a Tag (except Description)
is expected to be on its first line.  Only the Description would reasonably
be expected to run multiline, and the generic Tag syntax ABNF allows for
that (or at least it's supposed to).

We probably do need to highlight more frequently in the examples that
multiline Descriptions are perfectly valid.  I don't remember thinking of
that aspect the last time I went through the drafts and made notes to
myself.
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Thu, Nov 15, 2018 at 9:00 AM Marcos Passos 
wrote:

> The issue here is such "magic" annotations are single-line by nature:
>
> /**
>>  * @method static Foo bar() This method has a long description that
>> extends through several lines.
>>  * This line should also be included in the documentation of Foo:bar()
>>  */
>> class Foo
>> {
>> }
>
>
> It is by no means evident that the line that follows the annotation will
> be included in the documentation, although I believe it should. By making
> it explicit in the standard, leaves no room for misinterpretation on
> whether it is the expected result or not.
>
> _marcos
>
> Em qui, 15 de nov de 2018 às 12:44, Chuck Burgess 
> escreveu:
>
>> I don't know that I remember ever encountering any Description piece,
>> whether for DocBlock overall or individual Tags, where multiline was
>> prohibited.
>>
>> The only arguments I've ever seen regarding multiline Tag Descriptions
>> was about indenting the subsequent lines.
>>
>> Let me know if you see any places in the PSR-5 / PSR-19 drafts that seem
>> to prohibit them.
>> CRB
>>
>> On Thu, Nov 15, 2018, 08:35 Marcos Passos > wrote:
>>
>>> Hello folks,
>>>
>>> I would like to propose standardizing support to multiline descriptions
>>> in magic @property and @method annotation. Not allowing it has the impact
>>> of having long lines with bad readability and no paragraph support.
>>>
>>> What is your opinion on that?
>>>
>>> - Marcos
>>>
>>> --
>>> 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/f4cbc59b-0f6b-4a56-a018-9be377ca1ea7%40googlegroups.com
>>> <https://groups.google.com/d/msgid/php-fig/f4cbc59b-0f6b-4a56-a018-9be377ca1ea7%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/CANsgjntihWVr2cCEsfMADaNgdMmS6_QhCGTFLY9iPKuVgXHh1A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/php-fig/CANsgjntihWVr2cCEsfMADaNgdMmS6_QhCGTFLY9iPKuVgXHh1A%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/CANA3DetLvCgsa0nEuqqO3jK-50bFXKVwohu4DwoN95s29OCZ5A%40mail.gmail.com
> <https://groups.google.com/d/msgid/php-fig/CANA3DetLvCgsa0nEuqqO3jK-50bFXKVwohu4DwoN95s29OCZ5A%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/CANsgjnt_DUDd8mb3vbQzzeHNAexBGuuuZVfKw8jWNTkfHEQPRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-19] Multiline descriptions for @property and @method

[Chuck Burgess]

I don't know that I remember ever encountering any Description piece,
whether for DocBlock overall or individual Tags, where multiline was
prohibited.

The only arguments I've ever seen regarding multiline Tag Descriptions was
about indenting the subsequent lines.

Let me know if you see any places in the PSR-5 / PSR-19 drafts that seem to
prohibit them.
CRB

On Thu, Nov 15, 2018, 08:35 Marcos Passos  Hello folks,
>
> I would like to propose standardizing support to multiline descriptions in
> magic @property and @method annotation. Not allowing it has the impact of
> having long lines with bad readability and no paragraph support.
>
> What is your opinion on that?
>
> - Marcos
>
> --
> 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/f4cbc59b-0f6b-4a56-a018-9be377ca1ea7%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/CANsgjntihWVr2cCEsfMADaNgdMmS6_QhCGTFLY9iPKuVgXHh1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-19] Class and methods links

[Chuck Burgess]

Yes indeed... such resolution behavior goes back to phpDocumentor 1.x...
well, the namespace resolution doesn't, but it still applies.
CRB

On Thu, Nov 15, 2018, 08:30 Marcos Passos  Thank you for the quick and welcoming reply.
>
> I believe it also should cover naming resolution rules, to avoid having
> some tools supporting relative class names and others fully-qualified only.
> My suggestion here is to resolve in the same way PHP does: names are
> determined based on the current namespace, import statements, or requires
> being fully-qualified. This strategy is the same that JavaDocs adopts.
>
> - Marcos
>
> On Thursday, November 15, 2018 at 12:22:21 PM UTC-2, Chuck Burgess wrote:
>>
>> Yes, I plan to reintroduce that. The current draft has aspects to it that
>> date way back to efforts in phpDocumentor to deprecate some things,
>> including the @link tag completely.
>>
>> I'm guiding the Working Group through reviews of individual tags right
>> now, and already have this topic as a point to bring up when we get to the
>> @link tag.
>>
>> Still, thanks for noticing and speaking up 
>> CRB
>>
>> On Thu, Nov 15, 2018, 08:17 Marcos Passos >
>>> Hello everyone!
>>>
>>> Reading PSR-19 I could not find any mention to the use of @link to link
>>> constants, methods, and classes. Such a feature allows navigating between
>>> documents easier.
>>>
>>> Any plans to covers it?
>>>
>>> - Marcos
>>>
>>> --
>>> 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+u...@googlegroups.com.
>>> To post to this group, send email to php...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/php-fig/2a1bb268-707f-49eb-8bb6-a6e6660df979%40googlegroups.com
>>> <https://groups.google.com/d/msgid/php-fig/2a1bb268-707f-49eb-8bb6-a6e6660df979%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/526358ee-db52-4f10-868a-8f07da3ee97a%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/526358ee-db52-4f10-868a-8f07da3ee97a%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/CANsgjnuTKhKskTicnZDpo%2BJy4H3BR%3DC68zN1jxhyqTpwW-0pHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-19] Class and methods links

[Chuck Burgess]

Yes, I plan to reintroduce that. The current draft has aspects to it that
date way back to efforts in phpDocumentor to deprecate some things,
including the @link tag completely.

I'm guiding the Working Group through reviews of individual tags right now,
and already have this topic as a point to bring up when we get to the @link
tag.

Still, thanks for noticing and speaking up 
CRB

On Thu, Nov 15, 2018, 08:17 Marcos Passos  Hello everyone!
>
> Reading PSR-19 I could not find any mention to the use of @link to link
> constants, methods, and classes. Such a feature allows navigating between
> documents easier.
>
> Any plans to covers it?
>
> - Marcos
>
> --
> 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/2a1bb268-707f-49eb-8bb6-a6e6660df979%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/CANsgjntznCeGyQEAjaquY18NSk5pzkpKqWvKSx47KdP_TPAn%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

[Chuck Burgess]

So here we do indeed have a special IDE implementation to try to deal with
the OP's kind of use case.

Again, I can't envision a more standardized way to solve this with tags
themselves.


I'll mention this again, with regard to this use case though:
Stepping back a moment... that /* @var */ usage... seems like I've only
ever seen that used to typehint the $item portion of the example, not the
$stream portion... $stream should have been figured out earlier when it was
first populated, either by its own /* @var */ doc or by the return type of
whatever function/method actually populated it.

Would using the /* @var */ in this manner not solve this use case?
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Mon, Nov 12, 2018 at 9:48 AM Alexey Gopachenko 
wrote:

> Gents, in PhpStorm we had to specifically implement support for `Stream`
> implementing some magic interfaces
>
> public final static Map ARRAY_VALUE_PROVIDERS;
> static{
>   ARRAY_VALUE_PROVIDERS = new LinkedHashMap<>();
>   ARRAY_VALUE_PROVIDERS.put("\\Iterator", "#M#C*.current");
>   ARRAY_VALUE_PROVIDERS.put("\\Traversable", "#M#C*.__iterator");
>   ARRAY_VALUE_PROVIDERS.put("\\IteratorAggregate", "#E#M#C*.getIterator");
>   ARRAY_VALUE_PROVIDERS.put("\\ArrayAccess", "#M#C*.offsetGet");
> }
>
> public final static Map ARRAY_KEY_PROVIDERS;
> static{
>   ARRAY_KEY_PROVIDERS = new LinkedHashMap<>();
>   ARRAY_KEY_PROVIDERS.put("\\Iterator", "#M#C*.key");
>   ARRAY_KEY_PROVIDERS.put("\\IteratorAggregate", "#Y#M#C*.getIterator");
>   ARRAY_KEY_PROVIDERS.put("\\ArrayAccess", "#M#C*.offsetGet");
> }
>
>
>
> "Scan all Stream supers; if any matches eg Iterator than in foreach value
> and key TYPES shall be deduced from return types of methods current and key"
>
> this shall work transparently. While this stuff is still "nailed" there as
> of now, its ok to expect to have some meta defining such behaviors.
>
> Basically, this is one of the dynamic cases I was talking to some of you
> about - this is an important user story and has to be handled.
>
> On Saturday, November 10, 2018 at 6:02:42 PM UTC+1, Larry Garfield wrote:
>>
>> Hm, that's not quite what I mean.  IDEs would only need to do that level
>> of
>> deep inspection to generate a doc; I don't need them to generate it in
>> this
>> case if it's hard.
>>
>> I'm thinking more like:
>>
>> /**
>>  * @param Things[] $things
>>  */
>> function do_stuff(iterable $things) {
>>   // ...
>> }
>>
>> The docblock here technically says "$things is an array of Thing
>> objects",
>> whereas the type declaration says "$things is an iterable that produces
>> Thing
>> objects".
>>
>> What should the @param statement be so that it matches the actual code?
>>
>> --Larry Garfield
>>
>> On Friday, November 9, 2018 12:33:00 PM CST Chuck Burgess wrote:
>> > I don't immediately see a way to accomplish this with tags.
>> >
>> > The closest thing to an idea I can come up with here will be dictating
>> a
>> > rule to IDEs:  for any variable representing a collection used by a
>> > foreach, the IDE must do deep class hierarchy mining to find *any and
>> all
>> > potential return mechanisms* in order to enumerate all possible return
>> > types based on what's found.  In the OP's case,
>> >
>> > /* @var Stream $stream */
>> > foreach ($stream as $item)
>> >
>> > that means the IDE must take the Stream interface, find all
>> implementations
>> > of it, find all known array/interable return methods, compile a list of
>> > defined return types, and treat that list as what potential types that
>> > $item might be.
>> >
>> > Is there any similar IDE behavior as a precedent for such a rule /
>> > expectation?
>> >
>> >
>> > Stepping back a moment... that /* @var */ usage... seems like I've only
>> > ever seen that used to typehint the $item portion of the example, not
>> the
>> > $stream portion... $stream should have been figured out earlier when it
>> was
>> > first populated, either by its own /* @var */ doc or by the return type
>> of
>> > whatever function/method actually populated it.
>> >
>> > CRB
>> > *about.me/ashnazg <http://about.me/ashnazg>*
>> >
>> >
>> > On Fri, Nov 9, 2018 at 12:10 PM Larry Garfield 
>>
>> >
>> > w

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

[Chuck Burgess]

In Larry's example, I could envision the usage of the same @param with the
code signatures of (array $things) as well as (iterable $things), and both
be acceptable.  Both seem to say "a collection Things", with the difference
being the expected retrieval mechanism in the code signature typehint
(array vs interable).

Granted, this doesn't help us much with the OP's use case, which centers
on @returns rather than @params.
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Sat, Nov 10, 2018 at 11:02 AM Larry Garfield 
wrote:

> Hm, that's not quite what I mean.  IDEs would only need to do that level
> of
> deep inspection to generate a doc; I don't need them to generate it in
> this
> case if it's hard.
>
> I'm thinking more like:
>
> /**
>  * @param Things[] $things
>  */
> function do_stuff(iterable $things) {
>   // ...
> }
>
> The docblock here technically says "$things is an array of Thing objects",
> whereas the type declaration says "$things is an iterable that produces
> Thing
> objects".
>
> What should the @param statement be so that it matches the actual code?
>
> --Larry Garfield
>
> On Friday, November 9, 2018 12:33:00 PM CST Chuck Burgess wrote:
> > I don't immediately see a way to accomplish this with tags.
> >
> > The closest thing to an idea I can come up with here will be dictating a
> > rule to IDEs:  for any variable representing a collection used by a
> > foreach, the IDE must do deep class hierarchy mining to find *any and all
> > potential return mechanisms* in order to enumerate all possible return
> > types based on what's found.  In the OP's case,
> >
> > /* @var Stream $stream */
> > foreach ($stream as $item)
> >
> > that means the IDE must take the Stream interface, find all
> implementations
> > of it, find all known array/interable return methods, compile a list of
> > defined return types, and treat that list as what potential types that
> > $item might be.
> >
> > Is there any similar IDE behavior as a precedent for such a rule /
> > expectation?
> >
> >
> > Stepping back a moment... that /* @var */ usage... seems like I've only
> > ever seen that used to typehint the $item portion of the example, not the
> > $stream portion... $stream should have been figured out earlier when it
> was
> > first populated, either by its own /* @var */ doc or by the return type
> of
> > whatever function/method actually populated it.
> >
> > CRB
> > *about.me/ashnazg <http://about.me/ashnazg>*
> >
> >
> > On Fri, Nov 9, 2018 at 12:10 PM Larry Garfield 
> >
> > wrote:
> > > "This variable/return is an iterable of Foo objects" seems like an
> > > entirely
> > > reasonable thing to do.  We already have the de facto standard of
> Foo[] to
> > > mean "an array of Foo objects", but that doesn't technically cover any
> > > iterable.  (I'm really big on iterables these days, as anyone who
> follows
> > > my
> > > blog has noticed.)
> > >
> > > --Larry Garfield
> > >
> > > On Thursday, November 8, 2018 1:18:49 PM CST Chuck Burgess wrote:
> > > > Revisiting this, I'm leaning towards there *not* being a way to
> > >
> > > accomplish
> > >
> > > > this in the "one place" manner that you are after.
> > > > CRB
> > > >
> > > > On Wednesday, October 17, 2018 at 1:26:32 PM UTC-5, Woody Gilk wrote:
> > > > > Wouldn't the simple solution be:
> > > > >
> > > > > /** @var $stream Item[] */
> > > > > foreach ($stream as $item) {
> > > > >
> > > > > /* ... */
> > > > >
> > > > > }
> > > > >
> > > > > On Tuesday, October 16, 2018 at 2:02:21 PM UTC-5, Alan Gabriel Bem
> > >
> > > wrote:
> > > > >> I think you missed my point - What I want to achieve is to
> *annotate*
> > > > >> somehow that *Stream* is *iterable* over *Item* object and do it
> in
> > >
> > > *one
> > >
> > > > >> place* instead of every place I'm using `Stream` implementation.
> > > > >>
> > > > >> As I mentioned I could enforce using *Iterator* or
> > > > >> *IteratorAggregate*
> > > > >> (as
> > > > >> it opens the way to specify the *Item* as an iterated type...
> which
> > >
> > > IDEs
> > >
> > > > >> understand), 

Re: [PSR-5] Intersection Types

[Chuck Burgess]

Ok, so we have some level of consensus on allowing both operators, but
having & take precedence over | rather than needing parens if they were
equal precedence.


Alexey, you suggest that the two cannot be used together at all... is the
&-before-| option not workable from your perspective?

CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Mon, Nov 12, 2018 at 9:37 AM Alexey Gopachenko 
wrote:

> Actually I'm just so happy to see that you guys reached this conclusion -
> I was preparing a big post with some statistics about how hard we must work
> to deliver something so controversial and that it will take a HUGE toll on
> everyone even not using the stuff - both from point of making a compliant
> tool will be HARD and that tool (eg PhpStorm or CI analyzer) will be eating
> everyone's resources to just plug the holes in design. Phew.
>
> Let's allow only ONE type of operator - "|" or "&" and no braces.
> This will allow us to have working solutions most for real-world issues.
>
> I have another proposal in the queue - on taking care making entire syntax
> friendly to graceful degradation, but this requires some more work...
>
>
> Regards, Alex
>
>
>
> On Sat, Nov 10, 2018 at 12:14 AM Matthew Brown 
> wrote:
>
>> I agree - I don’t think we want to encourage types that expand into
>> monstrosities once the brackets have been evaluated out. Better to disallow
>> (...) & C.
>>
>> On Nov 9, 2018, at 1:15 PM, Chuck Burgess  wrote:
>>
>> Ah, I had assumed they were same precedence in PHP... it's obviously been
>> way too long since I've seen them in code.
>>
>> I agree with following PHP here, then, as Larry described... @return A &
>> C   |   B & C
>> CRB
>> *about.me/ashnazg <http://about.me/ashnazg>*
>>
>>
>> On Fri, Nov 9, 2018 at 12:10 PM Larry Garfield 
>> wrote:
>>
>>> Honestly, I'm skeptical that we want to develop a grammar for full
>>> algebraic
>>> type definitions in docs when the language doesn't support it.  That
>>> risks
>>> encouraging some very bad practices, and if PHP itself ever adds native
>>> algebraic types it could get weird if there's any inconsistency (which
>>> there
>>> almost certainly will be).
>>>
>>> That said, if we must support it in the doc format then follow the same
>>> precedence order as PHP itself: & binds higher than |.  Having a
>>> different set
>>> of parse rules than PHP itself is the way to madness. :-)
>>>
>>> --Larry Garfield
>>>
>>> On Thursday, November 8, 2018 12:52:18 PM CST Chuck Burgess wrote:
>>> > Previous replies indicate that whitespace around operators is perfectly
>>> > acceptable, so that seems resolved.
>>> >
>>> > What about the issue of operator precedence when "|" and "&" are both
>>> > needed?
>>> >
>>> > Do we want to say one is higher order than the other, resulting in the
>>> > possibility of one Type being listed multiple times:  @return A & C
>>>  |   B
>>> > & C
>>> >
>>> > Or should they be equal precedence, needing parentheses to enforce
>>> order:
>>> > @return (A | B) & C
>>> >
>>> > CRB
>>> >
>>> > On Tuesday, October 23, 2018 at 8:09:19 AM UTC-5, Chuck Burgess wrote:
>>> > > Having both operators at different levels would mean that
>>> combinations
>>> > > such as `@param (A|B) $test` would have to be written as `@param
>>> A|B
>>> > > $test`.
>>> > >
>>> > > I'm not against allowing whitespace around the operators, if the
>>> > > implementors agree it's still easy enough to parse correctly.  Since
>>> the
>>> > > variable name should come between the Types and the Description,
>>> perhaps
>>> > > that's not a big deal.
>>> > >
>>> > > CRB
>>> > > *about.me/ashnazg <http://about.me/ashnazg>*
>>> > >
>>> > > On Sun, Oct 21, 2018 at 9:40 AM  wrote:
>>> > >> Regarding the ABNF grammar, there are few things that need to be
>>> decided.
>>> > >>
>>> > >> (1) Priority / interaction with union and array "operators". I would
>>> > >> strongly recommend disallowing union and intersection on the same
>>> "level"
>>> > >> and always require brackets to explici

Re: [PSR-5][PSR-19] Is there a way to annotate interface that acts as iterator over some type?

[Chuck Burgess]

I don't immediately see a way to accomplish this with tags.

The closest thing to an idea I can come up with here will be dictating a
rule to IDEs:  for any variable representing a collection used by a
foreach, the IDE must do deep class hierarchy mining to find *any and all
potential return mechanisms* in order to enumerate all possible return
types based on what's found.  In the OP's case,

/* @var Stream $stream */
foreach ($stream as $item)

that means the IDE must take the Stream interface, find all implementations
of it, find all known array/interable return methods, compile a list of
defined return types, and treat that list as what potential types that
$item might be.

Is there any similar IDE behavior as a precedent for such a rule /
expectation?


Stepping back a moment... that /* @var */ usage... seems like I've only
ever seen that used to typehint the $item portion of the example, not the
$stream portion... $stream should have been figured out earlier when it was
first populated, either by its own /* @var */ doc or by the return type of
whatever function/method actually populated it.

CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Fri, Nov 9, 2018 at 12:10 PM Larry Garfield 
wrote:

> "This variable/return is an iterable of Foo objects" seems like an
> entirely
> reasonable thing to do.  We already have the de facto standard of Foo[] to
> mean "an array of Foo objects", but that doesn't technically cover any
> iterable.  (I'm really big on iterables these days, as anyone who follows
> my
> blog has noticed.)
>
> --Larry Garfield
>
> On Thursday, November 8, 2018 1:18:49 PM CST Chuck Burgess wrote:
> > Revisiting this, I'm leaning towards there *not* being a way to
> accomplish
> > this in the "one place" manner that you are after.
> > CRB
> >
> > On Wednesday, October 17, 2018 at 1:26:32 PM UTC-5, Woody Gilk wrote:
> > > Wouldn't the simple solution be:
> > >
> > > /** @var $stream Item[] */
> > > foreach ($stream as $item) {
> > >
> > > /* ... */
> > >
> > > }
> > >
> > > On Tuesday, October 16, 2018 at 2:02:21 PM UTC-5, Alan Gabriel Bem
> wrote:
> > >> I think you missed my point - What I want to achieve is to *annotate*
> > >> somehow that *Stream* is *iterable* over *Item* object and do it in
> *one
> > >> place* instead of every place I'm using `Stream` implementation.
> > >>
> > >> As I mentioned I could enforce using *Iterator* or *IteratorAggregate*
> > >> (as
> > >> it opens the way to specify the *Item* as an iterated type... which
> IDEs
> > >> understand), but I don't want to do that because actual iteration
> method
> > >> should depend on how it fits actual implementation. *Traversable* is
> > >> enough in this case because, simply speaking, it is marking *Stream*
> as
> > >> an object you can *foreach* on, but not telling how.
> > >>
> > >> wt., 16 paź 2018 o 19:30 Chuck Burgess 
> napisał(a):
> > >>> I'm tempted to argue that you're *not* sticking to Design By Contract
> > >>> here, because your two `Stream` implementations do not themselves
> give
> > >>> the
> > >>> same contract... at least, the parts of the contract that you're
> wanting
> > >>> to
> > >>> be derived by the IDE.
> > >>>
> > >>> Since it's already necessary to use a `/* @var */` comment block to
> > >>> typehint your local variable, and you don't want to hint
> specifically on
> > >>> your two classes, then perhaps you can do this instead:
> > >>>
> > >>> /* @var $stream Stream|Iterator|IteratorAggregate */
> > >>> foreach ($stream as $item) {
> > >>>
> > >>> $item->...
> > >>>
> > >>> }
> > >>>
> > >>> That leaves you only hinting on interfaces...
> > >>> CRB
> > >>>
> > >>>
> > >>> On Saturday, October 13, 2018 at 5:06:26 PM UTC-5, Alan Gabriel Bem
> > >>>
> > >>> wrote:
> > >>>> It is easy if such interface already extends some kind of
> iterator...
> > >>>>
> > >>>> interface Stream extends IteratorAggregate
> > >>>> {
> > >>>>
> > >>>> /**
> > >>>>
> > >>>>  * @return Item[]
> > >>>>  */
> > >>>>
> > >>>> public function getI

Re: [PSR-5] Intersection Types

[Chuck Burgess]

Ah, I had assumed they were same precedence in PHP... it's obviously been
way too long since I've seen them in code.

I agree with following PHP here, then, as Larry described... @return A & C
 |   B & C
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


On Fri, Nov 9, 2018 at 12:10 PM Larry Garfield 
wrote:

> Honestly, I'm skeptical that we want to develop a grammar for full
> algebraic
> type definitions in docs when the language doesn't support it.  That risks
> encouraging some very bad practices, and if PHP itself ever adds native
> algebraic types it could get weird if there's any inconsistency (which
> there
> almost certainly will be).
>
> That said, if we must support it in the doc format then follow the same
> precedence order as PHP itself: & binds higher than |.  Having a different
> set
> of parse rules than PHP itself is the way to madness. :-)
>
> --Larry Garfield
>
> On Thursday, November 8, 2018 12:52:18 PM CST Chuck Burgess wrote:
> > Previous replies indicate that whitespace around operators is perfectly
> > acceptable, so that seems resolved.
> >
> > What about the issue of operator precedence when "|" and "&" are both
> > needed?
> >
> > Do we want to say one is higher order than the other, resulting in the
> > possibility of one Type being listed multiple times:  @return A & C   |
>  B
> > & C
> >
> > Or should they be equal precedence, needing parentheses to enforce order:
> > @return (A | B) & C
> >
> > CRB
> >
> > On Tuesday, October 23, 2018 at 8:09:19 AM UTC-5, Chuck Burgess wrote:
> > > Having both operators at different levels would mean that combinations
> > > such as `@param (A|B) $test` would have to be written as `@param
> A|B
> > > $test`.
> > >
> > > I'm not against allowing whitespace around the operators, if the
> > > implementors agree it's still easy enough to parse correctly.  Since
> the
> > > variable name should come between the Types and the Description,
> perhaps
> > > that's not a big deal.
> > >
> > > CRB
> > > *about.me/ashnazg <http://about.me/ashnazg>*
> > >
> > > On Sun, Oct 21, 2018 at 9:40 AM  wrote:
> > >> Regarding the ABNF grammar, there are few things that need to be
> decided.
> > >>
> > >> (1) Priority / interaction with union and array "operators". I would
> > >> strongly recommend disallowing union and intersection on the same
> "level"
> > >> and always require brackets to explicitly declare the intention. For
> > >> consistency with union types, array and intersection should be
> allowed on
> > >> the same level with array having higher priority. This matches
> behavior
> > >> used by PHPStan and can be achieved for example with the following
> > >> grammar
> > >>
> > >> type = atomic [union / intersection]
> > >> union= 1*("|" atomic)
> > >> intersection = 1*("&" atomic)
> > >> atomic   = identifier [array] / "(" type ")" [array]
> > >> array= 1*("[]")
> > >> identifier   = keyword / class-name
> > >> keyword  = "array" / "bool" / ...
> > >> class-name   = ["\"] label *("\" label)
> > >> label= label-head *label-tail
> > >> label-head   = ALPHA / "_" / %x80-FF
> > >> label-tail   = ALPHA / DIGIT / "_" / %x80-FF
> > >>
> > >>
> > >> (2) Allowing horizontal whitespaces around operators. With more
> complex
> > >> types it makes sense to allow horizontal whitespaces around
> operators. It
> > >> complicates the grammar a bit, but it makes complex types a lot
> readable.
> > >> It may be better the post allowing horizontal whitespaces as a
> standalone
> > >> PR independent of intersection types.
> > >>
> > >> Regards,
> > >> Jan Tvrdík
> > >>
> > >>
> > >>
> > >> -- Původní e-mail --
> > >>
> > >> Od: Chuck Burgess 
> > >>
> > >> Komu: php-fig@googlegroups.com
> > >>
> > >> Datum: 21. 10. 2018 3:22:06
> > >>
> > >> Předmět: Re: [PSR-5] Intersection Types
> > >>
> > >> Yes, parentheses would be required for controlling order of
> precedence.
> > >>
> > &

Re: [PSR-5] Nullable type shorthand in PHPDoc (e.g. `@return ?string`)

[Chuck Burgess]

I think I would argue that this example is not quite the same thing as a
Nullable Type.  I see the Nullable Type as a special case involving nulls,
but not as *every* case involving nulls.  I see it as a method signature
type hint equivalent of `AnyClass|null`, so that the *signature* can still
provide runtime type enforcement of AnyClass on a passed argument, *but*
will still accept *no argument* (literal null of course being treated
equivalent to no argument).

Your example does *not* allow for no argument at all... you are absolutely
requiring an array.  So this is not the use case of a Nullable Type.  Your
example should lean on the Union operator "|" to denote that the values in
the required array should be strings or literal nulls:

@param (string|null)[] $stringsOrNulls you MUST send me an array, but
inside it, your values can be strings and/or literal nulls

CRB
*about.me/ashnazg *


On Thu, Nov 8, 2018 at 9:59 PM Adrien Crivelli 
wrote:

> I don't think "?" at the beginning is fully enough for the Nullable Type
> use case.
>
> You can easily express a "null or an array of elements that must be
> string" with "?string[]". But how can you express "an array of elements
> that must be string or null" ?
>
> In code that would be:
>
> /**
>  * @param ?string[] $strings
>  */
> function nullOrArrayOfString(?array $strings) {
> }
>
> /**
>  * @param WHAT SHOULD I WRITE HERE ? $stringsOrNulls
>  */
> function arrayOfStringOrNull(array $stringsOrNulls) {
> }
>
> nullOrArrayOfString(null);
> nullOrArrayOfString(['foo', 'bar']);
> nullOrArrayOfString(['foo', null]); // Invalid call !
>
> arrayOfStringOrNull(null); // Invalid call !
> arrayOfStringOrNull(['foo', 'bar']);
> arrayOfStringOrNull(['foo', null]);
>
>
> I think something like "(?string)[]" would be necessary to cover all null
> cases.
>
> --
> 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/c0ba7fdf-5c45-493c-8f66-ff9bccbd7a14%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/CANsgjnuiU0vy7Z4wE4LsTT0goFzLoVS6fArbftETo_UgaQLV3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-19] Working Group Plan

[Chuck Burgess]

Working Group,

Given one approval on the first four tags (api, author, copyright, todo),
the PR to mark them approved is ready for your review [1].  Also, the last
"cleanup / from-old-fork" PR [2] still needs an approval so that I can pull
in that last batch of changes.

In looking over my initial notes on all the remaining tags, I'm thinking
these four will be the easiest to discuss next:
* category [3]
  - Rather than list it as deprecated, should be just leave it out
altogether?
* deprecated [4]
  - The syntax already contains the Ending Version... should we take that
out?  I don't know that the merits of including it was ever justified.
* global [5]
  - I definitely think we should leave this out... let @uses do its job.
* license [6]
  - If we decide to drop file-level docblocks altogether, should the
license tag even continue to exist?  Do we really want to license elements
individually?

Please consider my questions and reply.  For any of these tags that you do
feel should remain in the catalog, please look specifically at those
sections and decide:
- does anything need to be removed
- is any wording unclear
- does it *not* fit with *your* implementation

Lastly, as mentioned before, please join the ML discussions as you are able.
CRB
*about.me/ashnazg <http://about.me/ashnazg>*


[1] -- https://github.com/php-fig/fig-standards/pull/1113 -- "[PSR-19] mark
four tags as approved by WG"
[2] -- https://github.com/php-fig/fig-standards/pull/1109 -- "Downstream
changes from phpDocumentor/fig-standards fork"

[3] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#53-category-deprecated
[4] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#55-deprecated
[5] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#57-global
[6] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#59-license


On Wed, Oct 31, 2018 at 12:56 PM Chuck Burgess  wrote:

> Ok, Working Group, let's start small...
>
> I've gone through the tag catalog (phpdoc-tags.md), and made notes on each
> tag as it is *currently* shown in the catalog.
>
> I see these tags as being perfectly fine, needing no changes: api [1],
> author [2], copyright [3], todo [4].
>
> I'd like the group to look specifically at those sections only, and decide:
> - does anything need to be removed
> - is any wording unclear
> - does it *not* fit with *your* implementation
>
> As we reach consensus on each section, I'll do a PR to mark the section as
> "approved by WG"... these markers will be removed before the acceptance
> vote.
>
> Once we're past this step, I'll bring up specific things on another tag
> section or two. This way, we keep the amount of open topics from getting
> unwieldy.
>
> Granted, the amount of ML threads is beyond such control, so join those
> discussions as you are able.
>
> Does this approach sound ok to the WG?
> CRB
> *about.me/ashnazg <http://about.me/ashnazg>*
>
>
> [1] --
> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#51-api
> [2] --
> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#52-author
> [3] --
> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#54-copyright
> [4] --
> https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#520-todo
>

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

Re: [PSR-5] Nullable type shorthand in PHPDoc (e.g. `@return ?string`)

[Chuck Burgess]

Revisiting this now, I'm having trouble thinking of a "[]" example that 
would break the assumption that "?" at the beginning isn't good enough to 
mean that "if any listed type is nullable, then of course every listed type 
is nullable".

Anyone?  If not, then I'm leaning towards just saying that a simple "?" at 
the beginning is fully enough for the Nullable Type use case.
CRB

On Tuesday, October 16, 2018 at 7:54:17 AM UTC-5, Chuck Burgess wrote:
>
> On Tuesday, October 16, 2018 at 2:26:51 AM UTC-5, Jan Schneider wrote:
>>
>> Zitat von Tyson Andre :
>>
>> Earlier discussion about including this in PSR-5 is found in 
>> https://github.com/phpDocumentor/fig-standards/issues/153 , I'm 
>> re-opening the discussion here. 
>>  
>> This shorthand isn't part of the PSR-5 draft : 
>> https://github.com/phpDocumentor/fig-standards/blob/master/proposed/phpdoc.md#abnf
>>  
>> Reasons:
>>  
>> - Nullable types are part of the language syntax for real signatures, so 
>> adding this in PHPDoc makes some sense
>> - @return ?string is shorter than @return string|null
>> - Many static analyzers support this syntax in PHPDoc already 
>> (Phan/Psalm/PHPStan (and phpdocumentor3 will?)).
>>  
>> Questions that were already brought up:
>>  
>> - A canonical way to represent the union type after parsing it in union 
>> types - ?int|string, ?(int|string), ?int|?string, int|string|null are 
>> equivalent, but which should be preferred for the output of tools
>>   (not sure if that would need to be part of the standard)
>> - Operator precedence (e.g. ?string[]) - I suggested treating that as 
>> ?(string[]), others suggested forbidding ambiguous cases and forcing phpdoc 
>> authors to add brackets - either explicitly write (?string)[] or 
>> ?(string[]).
>>
>> For the sake of unambiguousity I'd prefer the latter, i.e. forcing to use 
>> brackets. This would also solve the first question.
>> --
>> Jan Schneider
>> The Horde Project
>> https://www.horde.org/
>>
>
>
> Normally I lean toward more explicit too.  In the case of nullable, 
> though, I can concede that the more concise "just `?` at the beginning" 
> could be good enough.  Presumably, if the first datatype in a union is 
> allowed to be nullable, then *all* datatypes in the union list *have* to be 
> considered nullable... right? 
>
> @param string|array|\DateTime|null $arg
>
> It wouldn't be reasonable to say "string can be null, but array can't be", 
> because if you pass a null, then what datatype are you saying you are 
> nulling? :-D
>
> Based on this thinking, I can see just having a single `?` prefix without 
> brackentheses (TM), at least not needing the wrapper to denote scope of the 
> `?`.
>
> Scope on a trailing `[]` in a union list... that's another story :-D
> 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/64b45663-f3d8-40d2-87ce-8ee0b589956f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-5] Intersection Types

[Chuck Burgess]

Previous replies indicate that whitespace around operators is perfectly 
acceptable, so that seems resolved.

What about the issue of operator precedence when "|" and "&" are both 
needed?  

Do we want to say one is higher order than the other, resulting in the 
possibility of one Type being listed multiple times:  @return A & C   |   B 
& C

Or should they be equal precedence, needing parentheses to enforce order:  
@return (A | B) & C

CRB

On Tuesday, October 23, 2018 at 8:09:19 AM UTC-5, Chuck Burgess wrote:
>
> Having both operators at different levels would mean that combinations 
> such as `@param (A|B) $test` would have to be written as `@param A|B 
> $test`.
>
> I'm not against allowing whitespace around the operators, if the 
> implementors agree it's still easy enough to parse correctly.  Since the 
> variable name should come between the Types and the Description, perhaps 
> that's not a big deal.
>
> CRB
> *about.me/ashnazg <http://about.me/ashnazg>*
>
>
> On Sun, Oct 21, 2018 at 9:40 AM  wrote:
>
>> Regarding the ABNF grammar, there are few things that need to be decided.
>>
>> (1) Priority / interaction with union and array "operators". I would 
>> strongly recommend disallowing union and intersection on the same "level" 
>> and always require brackets to explicitly declare the intention. For 
>> consistency with union types, array and intersection should be allowed on 
>> the same level with array having higher priority. This matches behavior 
>> used by PHPStan and can be achieved for example with the following grammar
>>
>> type = atomic [union / intersection]
>> union= 1*("|" atomic)
>> intersection = 1*("&" atomic)
>> atomic   = identifier [array] / "(" type ")" [array]
>> array= 1*("[]")
>> identifier   = keyword / class-name
>> keyword  = "array" / "bool" / ...
>> class-name   = ["\"] label *("\" label)
>> label= label-head *label-tail
>> label-head   = ALPHA / "_" / %x80-FF
>> label-tail   = ALPHA / DIGIT / "_" / %x80-FF
>>
>>
>> (2) Allowing horizontal whitespaces around operators. With more complex 
>> types it makes sense to allow horizontal whitespaces around operators. It 
>> complicates the grammar a bit, but it makes complex types a lot readable. 
>> It may be better the post allowing horizontal whitespaces as a standalone 
>> PR independent of intersection types.
>>
>> Regards,
>> Jan Tvrdík
>>
>>
>>
>> -- Původní e-mail --
>>
>> Od: Chuck Burgess 
>>
>> Komu: php-fig@googlegroups.com
>>
>> Datum: 21. 10. 2018 3:22:06
>>
>> Předmět: Re: [PSR-5] Intersection Types
>>
>> Yes, parentheses would be required for controlling order of precedence.
>>
>> In your example, I would expect:
>>
>>
>>
>>
>> * @param (CacheInterface)|ResetableCacheInterface 
>> $cache
>>
>>
>> CRB
>>
>>
>>
>> On Sat, Oct 20, 2018, 17:43 AzJezz  wrote:
>>
>> Hi,
>>
>> i find it quite confusing myself, here's a use case mixing `&` and `|`.
>>
>>
>> ```php
>>
>> >
>> namespace App\Foo;
>>
>> class Bar {
>> /**
>> * in this example `Bar` constructor accepts an object that implement
>> * ( `CacheInterface` and `ResetableInterface` ) or 
>> `ResetableCacheInterface`
>> *
>> * should the doc block be formatted this way :
>> *
>> * @param 
>> object|ResetableCacheInterface $cache
>> *
>> * or maybe like this ?
>> *
>> * @param 
>> object|ResetableInterface $cache
>> *
>> * or maybe we can use parentheses ? ¯\_(ツ)_/¯
>> *
>> * @param object & ( ResetableCacheInterface | ( ResetableInterface & 
>> CacheInterface ) ) $cache
>> */
>> public function __construct($cache) {
>> // initialize cache property
>> }
>> }
>> ```
>>
>>
>>
>>
>> On Sat, Oct 20, 2018 at 11:53 AM Johannes Schmitt  
>> wrote:
>>
>> Hi there,
>>
>> generally, I think the addition of `&` is a great idea.
>>
>>
>> One thing regarding the grammar specifically, right now you would support 
>> mixing `|` with `&` like `A|B`. I'm not sure if mixing would be desirable 
>> (I don't have use-case for this at this point). Al

Re: [PSR-5] Summary

[Chuck Burgess]

Since this thread seems to have wrapped up, I've merged the PR.
CRB

On Tuesday, October 30, 2018 at 2:23:00 PM UTC-5, Woody Gilk wrote:
>
> I would be fine with eliminating the requirement for a full stop so long 
> as the two line break requirement stays. The only problem I see with the 
> full stop requirement is that prevents using other punctuation as a stop, 
> unless said punctuation is declared in the grammar. That gets tricky with 
> i18n, etc. Probably best to leave it out.
>
> I will update the PR accordingly.
> --
> Woody Gilk
> https://shadowhand.me
>
>
> On Mon, Oct 29, 2018 at 3:10 PM Chuck Burgess  > wrote:
>
>> Yes guys, I understand you both.  My comments are directed at the angle 
>> of discussion that the spec *should* **require** periods.  My argument is 
>> that they don't need to be explicitly required... but the spec doesn't care 
>> if they *are* used.  The spec should only care about the two CRLFs between 
>> Summary and anything after it, IMO.
>>
>> I believe this is really the only open question right now... periods 
>> explicitly required to be in spec, or spec doesn't specify anything with 
>> regard to periods... all the examples can certainly include them.
>> CRB
>>
>> On Monday, October 29, 2018 at 2:23:53 PM UTC-5, Ian Littman wrote:
>>>
>>> A full stop is consistent with other PSRs, as is two line breaks between 
>>> summary and description. Particularly after PR 1107 is merged. I'm not 
>>> commenting on whether the full stop should be required or optional, but 
>>> requiring it to not exist would, as mentioned further up the thread, fly in 
>>> the face of what's built out currently.
>>>
>>> On Monday, October 29, 2018 at 2:12:38 PM UTC-5, Miguel Rosales wrote:
>>>>
>>>> Just to make things clear, the "complaint" in my first comment wasn't 
>>>> about the fact that the spec should require full stops, but only about the 
>>>> fact that the PR supposedly created to correct the misleading 
>>>> 2-line-breaks-after-summary recommendation, was also deleting full stops 
>>>> from lots of summaries in the examples, when there was no need for that at 
>>>> all!  
>>>>
>>>> If you ask me, I'd require full stops, but I do see how it may be 
>>>> overkill - what I do think is at least the examples should include them, 
>>>> as 
>>>> a suggestion for best practices, imho anyway.
>>>>
>>>> El lunes, 29 de octubre de 2018, 17:45:36 (UTC), Chuck Burgess escribió:
>>>>>
>>>>> If enough people feel strongly about requiring the period, I won't 
>>>>> stand in the way... but I think it's overkill for the spec.  I think just 
>>>>> saying that "if any content (Description, tags) follows the Summary, 
>>>>> there 
>>>>> MUST be two CRLFs delineating the Summary from the rest" should be 
>>>>> sufficient.  I don't think the spec insisting that the Summary be a 
>>>>> proper 
>>>>> sentence is necessary... it's good form, sure, but no static tools are 
>>>>> going to tell me "Young man, this is Harvard University... we do not end 
>>>>> our sentences with a preposition!!!".  I'd bet that 50% of the docblock 
>>>>> Summaries in my experience are sentence fragments at best.  As such, I 
>>>>> don't think the period on top of two CRLFs is necessary.  
>>>>>
>>>>> Note that by not *demanding* a period, the spec is not saying "no 
>>>>> periods allowed".  I think at least one response earlier seemed to imply 
>>>>> that not having in the spec would somehow mean it would be prohibited 
>>>>> instead.
>>>>> CRB
>>>>> *about.me/ashnazg <http://about.me/ashnazg>*
>>>>>
>>>>>
>>>>> On Sat, Oct 27, 2018 at 2:15 PM Woody Gilk  wrote:
>>>>>
>>>>>> Optional can't be enforced with style checks. Hence, I would rather 
>>>>>> have a required specification.
>>>>>> --
>>>>>> Woody Gilk
>>>>>> https://shadowhand.me
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 27, 2018 at 12:28 PM Robbie Averill <
>>>>>> rob...@silverstripe.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> While I rarely use full stops at the end of sente

Re: [PSR-5][PSR-19] Standard for describing properties with the @var tag

[Chuck Burgess]

Thanks for the thread, Andrew.

I've added to my TODO notes for the @var Tag that an example of a full
DocBlock needs to be the basic example (like your first example), with the
one-line DocBlock variant being an allowed alternative syntax.

More generally addressing your question for the One True Way, in this
instance, I see *all* the ways as OK.  Here's why:

* The DocBlock level Description is optional and available, regardless of
the Tags in the DocBlock... the fact that this this particular DocBlock is
only for an element that the @var Tag itself will describe is irrelevant,
even if it seems redundant.

* The @var Tag level Description is optional and available, because not all
well-named elements with properly shown @var data Type will need such
description... the fact that the DocBlock itself has an optional
Description is irrelevant, even if it seems redundant.

* The one-line DocBlock format variant doesn't allow for Summary or
Description, so the @var Tag level Description is the only place to put one
if such a description is needed.

Now, if we were to consider trying to remove the variations and force a One
True Way here, I fear we will find three statistically equal camps out in
the wild with regard to how projects use this Tag and its DocBlock.

However, if the Working Group did wish to try tightening up this case of
description redundancy, then presumably the cleanest way to do so is to
drop Description completely out of the @var Tag itself, since we can't
really force dropping it from the DocBlock overall just because it's
an @var Tag DocBlock.

Working Group and ML readers:  further thoughts?

CRB
*about.me/ashnazg *


On Mon, Nov 5, 2018 at 9:58 PM Andrew Goode  wrote:

> I'm mostly used to seeing class properties documented like, e.g.:
> /**
>  * Summary of property.
>  *
>  * @var array
>  */
> protected $data = [];
>
> In the current PSR-5 and PSR-19 drafts, all the examples for @var show the
> single-line syntax like, e.g.:
> /** @var array Description of property (from tag). */
> protected $data = [];
>
> It's currently not clear where the property's description SHOULD be placed.
>
> I've seen three editor implementations that show different results in the
> autocomplete hint for the property:
>
>1. shows the DocBlock summary/description but not the @var tag
>description.
>*e.g. "Summary of property." (or empty)*
>2. shows the @var tag description but not the DocBlock
>summary/description.
>*e.g. "Description of property (from tag)."** (or empty)*
>3. shows both the DocBlock summary/description and the @var tag
>description.
>*e.g. "Summary of property. Description of property (from tag)."*
>
> So depending on which of the above documentation styles has been used,
> some editors show no description for the property. I came looking at the
> PHPDocumentor docs and the latest PSR drafts to find out which
> implementation was correct, but there doesn't seem to be any
> standard/recommendation that answers this question.
>
> It would be good to address these issues in the new PSRs:
>
>- Should PHPDoc implementations show *both *the DocBlock
>summary/description *and *the @var tag description, or just *one *of
>them, and if so, which one?
>- If there can only be one DocBlock with only one @var tag before a
>property/variable:
>   - Does it make sense to have two different ways to do the same
>   thing (describe the property)? Should the @var tag description be 
> removed
>   from the spec?
>   - If the @var tag description shouldn't be removed because it's
>   required for other usages of the @var tag, should the PSRs specify a
>   different *meaning/context *of the @var tag description compared to
>   the DocBlock summary/description, that would make it clear:
>  - when to use the tag description *instead *of the DocBlock
>  summary/description, or
>  - whether to provide *different contextual content *in the tag
>  description than in the DocBlock summary/description?
>
> --
> 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/90b68cca-00ed-4cb1-ad17-6a4e02e2cc47%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 

[PSR-19] Working Group Plan

[Chuck Burgess]

Ok, Working Group, let's start small...

I've gone through the tag catalog (phpdoc-tags.md), and made notes on each
tag as it is *currently* shown in the catalog.

I see these tags as being perfectly fine, needing no changes: api [1],
author [2], copyright [3], todo [4].

I'd like the group to look specifically at those sections only, and decide:
- does anything need to be removed
- is any wording unclear
- does it *not* fit with *your* implementation

As we reach consensus on each section, I'll do a PR to mark the section as
"approved by WG"... these markers will be removed before the acceptance
vote.

Once we're past this step, I'll bring up specific things on another tag
section or two. This way, we keep the amount of open topics from getting
unwieldy.

Granted, the amount of ML threads is beyond such control, so join those
discussions as you are able.

Does this approach sound ok to the WG?
CRB
*about.me/ashnazg *


[1] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#51-api
[2] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#52-author
[3] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#54-copyright
[4] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#520-todo

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

[PSR-5][PSR-19] Weekly Update - 2018-10-31

[Chuck Burgess]

Hello everyone,

Over the past week, the Working Group [1] continues to review a few of the
tags in the tag catalog, as a small starting point toward marking specific
sections of the PSR-19 catalog as "approved by WG".  Again, the rationale
is that by working just a few tags at a time for sanity, we hope to bring
the drafts up to a "minimum baseline" of acceptance before diving heavily
into more expansive topics of discussion.

The last remaining cleanup Pull Request [2] has been updated based on some
feedback regarding an "Inline PHPDoc" example... it is awaiting WG
approvals.

On the ML, we have several open threads of discussion [3], including a new
thread on the DocBlock "Summary".  Everyone interested in contributing to
discussions should get involved on these threads.

My plan for the next week is to continue nudging the WG towards reviewing
and signing off on the few tags we're currently focused on, so that I can
mark those as done, and then move on to a few other tags that may require a
tad more discussion and/or edits.  In this manner, I hope to keep any given
week's level of WG work limited to just a few minutes of *click-it &
look-at-it & ( ok-it | slack-about-it ).  *Again, this is strictly to get
the drafts up to a minimum baseline of content and consensus.

Aside from contributing, if you have feedback on the structure or content
of this update email, please let me know.
Chuck Burgess, Editor
*about.me/ashnazg <http://about.me/ashnazg>*

[1] --
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-meta.md#
5-people

[2] -- https://github.com/php-fig/fig-standards/pull/1097 -- "Downstream
changes from phpDocumentor/fig-standards fork"

[3] --
https://groups.google.com/forum/#!topic/php-fig/KckIDHss-QI -- "PSR-19]
deprecate double closing brace on inline internal tag"
https://groups.google.com/forum/#!topic/php-fig/5A5ytQyV6Oo -- "[PSR-5]
Nullable type shorthand in PHPDoc (e.g. `@return ?string`)"
https://groups.google.com/forum/#!topic/php-fig/zFMcfjYAS7M -- "PSR-5]
Variadic Parameters"
https://groups.google.com/forum/#!topic/php-fig/vi0ymMCydDA -- "[PSR-5][PSR-
19] Is there a way to annotate interface that acts as iterator over some
type?"
https://groups.google.com/forum/#!topic/php-fig/W1VyAtoqGQ8 -- "[PSR-5]
Intersection Types"
https://groups.google.com/forum/#!topic/php-fig/59qEeX-VkZU -- "[PSR-5]
Summary"

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

Re: [PSR-5] Summary

[Chuck Burgess]

Yes guys, I understand you both.  My comments are directed at the angle of 
discussion that the spec *should* **require** periods.  My argument is that 
they don't need to be explicitly required... but the spec doesn't care if 
they *are* used.  The spec should only care about the two CRLFs between 
Summary and anything after it, IMO.

I believe this is really the only open question right now... periods 
explicitly required to be in spec, or spec doesn't specify anything with 
regard to periods... all the examples can certainly include them.
CRB

On Monday, October 29, 2018 at 2:23:53 PM UTC-5, Ian Littman wrote:
>
> A full stop is consistent with other PSRs, as is two line breaks between 
> summary and description. Particularly after PR 1107 is merged. I'm not 
> commenting on whether the full stop should be required or optional, but 
> requiring it to not exist would, as mentioned further up the thread, fly in 
> the face of what's built out currently.
>
> On Monday, October 29, 2018 at 2:12:38 PM UTC-5, Miguel Rosales wrote:
>>
>> Just to make things clear, the "complaint" in my first comment wasn't 
>> about the fact that the spec should require full stops, but only about the 
>> fact that the PR supposedly created to correct the misleading 
>> 2-line-breaks-after-summary recommendation, was also deleting full stops 
>> from lots of summaries in the examples, when there was no need for that at 
>> all!  
>>
>> If you ask me, I'd require full stops, but I do see how it may be 
>> overkill - what I do think is at least the examples should include them, as 
>> a suggestion for best practices, imho anyway.
>>
>> El lunes, 29 de octubre de 2018, 17:45:36 (UTC), Chuck Burgess escribió:
>>>
>>> If enough people feel strongly about requiring the period, I won't stand 
>>> in the way... but I think it's overkill for the spec.  I think just saying 
>>> that "if any content (Description, tags) follows the Summary, there MUST be 
>>> two CRLFs delineating the Summary from the rest" should be sufficient.  I 
>>> don't think the spec insisting that the Summary be a proper sentence is 
>>> necessary... it's good form, sure, but no static tools are going to tell me 
>>> "Young man, this is Harvard University... we do not end our sentences with 
>>> a preposition!!!".  I'd bet that 50% of the docblock Summaries in my 
>>> experience are sentence fragments at best.  As such, I don't think the 
>>> period on top of two CRLFs is necessary.  
>>>
>>> Note that by not *demanding* a period, the spec is not saying "no 
>>> periods allowed".  I think at least one response earlier seemed to imply 
>>> that not having in the spec would somehow mean it would be prohibited 
>>> instead.
>>> CRB
>>> *about.me/ashnazg <http://about.me/ashnazg>*
>>>
>>>
>>> On Sat, Oct 27, 2018 at 2:15 PM Woody Gilk  wrote:
>>>
>>>> Optional can't be enforced with style checks. Hence, I would rather 
>>>> have a required specification.
>>>> --
>>>> Woody Gilk
>>>> https://shadowhand.me
>>>>
>>>>
>>>> On Sat, Oct 27, 2018 at 12:28 PM Robbie Averill <
>>>> rob...@silverstripe.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> While I rarely use full stops at the end of sentences in doc blocks 
>>>>> myself, I acknowledge that I probably should. They are sentences rather 
>>>>> than titles, so should probably have one.
>>>>>
>>>>> I think though that enforcing them might be a little strict, perhaps 
>>>>> suggesting it or mentioning that they are optional would be better.
>>>>>
>>>>> Regards
>>>>> Robbie
>>>>>
>>>>> On Fri, 26 Oct 2018 at 16:56, Woody Gilk  wrote:
>>>>>
>>>>>> Larry,
>>>>>>
>>>>>> My survey was obviously not big enough. Having reviewed the existing 
>>>>>> phpdoc demos [1] and Symfony API documentation [2], removing the period 
>>>>>> would be a major BC break, as you stated on the PR.
>>>>>>
>>>>>> I have updated the PR to require that a summary be separated by two 
>>>>>> line breaks instead.
>>>>>>
>>>>>> Now... to go update a bunch of docblocks. ;)
>>>>>>
>>>>>> [1]: 
>>>>>> http://demo.phpdoc.org/Respons