Re: [Vote] Require Aura project to replace its representative

-1 from PEAR On Jul 28, 2016 18:56, "Samantha Quiñones" wrote: > All, > > The discussion period having concluded, I am now opening a vote on the > matter of the proposal to require the Aura project to name a new voting > representative. > > The discussion thread is

Re: [PSR-11] Remove ContainerException

ception class (or interface) > in PEAR's container package to satisfy your internal conventions. > > Matthieu > > Le Mer 17 août 2016, à 12:57, Chuck Burgess a écrit : > > PEAR most definitely wants to keep the package-level base exception, as it > is a convention we alw

Re: [Vote] [Member Projects] Membership Application: Phergie

+1 from PEAR On Feb 6, 2017 09:57, "Chris Tankersley" wrote: > It's been well past 2 weeks while having a discussion period on allowing > Phergie as a member project, and here is the voting thread for Member > Projects. > > Please vote with a -1/0/+1, like normal. > >

Re: [REVIEW] PSR-11 Container Interface

I'm good with #3, as it looks like a useful addition that should alleviate some concerns. On Jan 16, 2017 04:58, "David Négrier" wrote: > Ok, we have 3 options, and one day to decide which to choose. > > In order to ease the choice, I opened 3 PRs on Github. > > I'll

Re: [REVIEW] PSR-11 Container Interface (Take 3)

LGTM... On Jan 17, 2017 09:13, "Matthew Weier O'Phinney" wrote: > We are rebooting the PSR-11 review period again as of now; this marks > the third review period, and it will end at 11:59 UTC 29 Jan 2017, > with the prospect of holding a vote starting the following

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

I have to concur with those who classify this akin to "tabs vs spaces", as: - neither choice significantly hinders coding - either choice could win a vote today and lose a revote in several months I see this as one of those "pick one and be done, stick with it, and focus on harder stuff". I

Re: [VOTE] [Bylaw Amendment] Do not require interface suffix on future PSR Interfaces

-1 from PEAR On Sep 4, 2016 11:26, "Michael Cullum" wrote: > Hi all, > > The PSR-11 Editors have requested we open this vote for them as they are > unable to do so not being voting members. > > *Status Quo:* The bylaw states that all interfaces in PSRs published by > the

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

I suppose "container" is too loaded a term... as is "sixpack" :-D I'm cool with collection, as a "collection of collections" is no more odd to me than an array of arrays. CRB On Sep 21, 2016 17:19, "Larry Garfield" wrote: > As there doesn't seem to be a clear consensus

Re: [VOTE] Secretary Election August 2016

>From PEAR: Amanda Folson Matthew 'Matt' Trask Jonathan Reinink Samantha Quiñones CRB On Aug 12, 2016 17:24, "Michael Cullum" wrote: > Hi all, > > So for those unaware, it's that time again. Every 8 months a secretary's > term ends and on this occasion, we have both a

Re: [Important] [Internals] All projects must declare intention to remain members

PEAR will remain a member. On Oct 2, 2016 18:44, "Michael Cullum" wrote: > As per the FIG 3.0 bylaws, all member projects must, between the 1st > October and 31st October, declare they wish to remain a member project of > the FIG. If you don't wish to remain, then it

Re: [REVIEW] PSR-11 Container Interface

Small point: should the has() section in 1.1 say that the entry identifier MUST be a string, similar to how it does so for get()? On Oct 26, 2016 8:28 AM, "Matthew Weier O'Phinney" wrote: > Hello, everyone! > > PSR-11, Container Interface (née container-interop) has

Re: [VOTE][Accept] PSR-13: Link Definition Interfaces

+1 from PEAR On Oct 31, 2016 4:15 PM, "Matthew Weier O'Phinney" wrote: > Per the by-laws, the required review period has passed for the > proposed standard PSR-13 (Link Definition Interfaces). No changes have > been made in the past two weeks since re-opening the

Re: [Internals][FIG 3.0] Extending Nomination Period & Delaying FIG 3.0 Transition

No objection from PEAR... CRB On Nov 9, 2016 11:09 AM, "Michael Cullum" wrote: > Hi all, > > Does anyone have any objections to extending the Core Committee nomination > period one month and pushing the FIG 3.0 implementation timetable back a > month (so the new

Re: [VOTE] First Core Committee Elections

1. Matthew Weier O’Phinney 2. Larry Garfield 3. Sara Golemon 4. Lukas Kahwe Smith 5. Beau Simensen 6. Korvin Szanto 7. Jeremy Coates 8. Chris Tankersley 9. David Négrier 10. Graham Daniels 11. Gary Hockin 12. Samantha Quiñones (from PEAR) On Dec 9, 2016 10:47, "Michael Cullum"

Re: [PSR-8] Working Group?

I'm game to play along  On Jan 12, 2017 16:41, "Larry Garfield" wrote: I feel I need to do this to avoid disappointing a very affectionate Twitter account... PSR-8, like any other in-progress PSR, needs to form a Working Group to remain an active PSR. I am happy to

Re: [REVIEW] PSR-11 Container Interface

On the exceptions, that language just says to me that in my get() method, I have a try/catch around any deeper get() calls, and thus my outer get is going to catch *anything* and wrap it with the package-level exception before throwing it. It's not really about the source exception being

Re: [REVIEW] PSR-11 Container Interface

LGTM from PEAR... On Dec 31, 2016 14:57, "Matthew Weier O'Phinney" wrote: > Greetings, on this last day of 2016! (For some of you, it's already 2017!) > > I'm rebooting the REVIEW period for PSR-11 as of now; review will end > at 11:59 on 13 January 2017, with the

Re: Working Group for PSR-5

I can join... CRB On Jul 10, 2017 5:25 AM, "GeeH" wrote: I am serious about getting PSR-5 moving again and would like to form a working group to get this accepted. From what I can see it's not in a bad place to be finished, it just needs a few more revisions and to have some

Re: Standard for formatting long conditions

That repo is not us... it's not the FIG... see how they describe themselves in their Readme -- https://github.com/php-fig-rectified/fig-rectified-standards/blob/master/README.md On Jun 21, 2017 5:03 AM, "Sergey Karavay" wrote: > Thanks! Pretty much what I'm talking

Re: [PSR-5] Working Group Formation

anyway, as > the content of it shouldn't matter in regard of the vote, which is only > about the willingness of having a PSR on that topic. > > Il giorno martedì 15 maggio 2018 20:34:51 UTC+2, Chuck Burgess ha scritto: >> >> A new working group for PSR-5 is outlined in P

[PSR-5] Working Group Formation

A new working group for PSR-5 is outlined in PR#1026. Is it possible to get the PR merged, and an entrance vote initiated to return it to Draft status? CRB -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe

Re: [VOTE] Secretary Election

1. Margret Staples 2. Alessandro Lai 3. Mark Railton CRB (PEAR) On Oct 19, 2017 16:17, "Michael Cullum" wrote: Hi all, We've been attempting to get more nominations so this has been delayed a few times but we now have three candidates so we're rolling with it. Full

Re: [VOTE][Internals] Secretary election

PEAR: 1. Mark Railton 2. Robert Parker On Jan 12, 2018 08:37, "Alessandro Lai" wrote: Hello everyone, as specified in the previous thread (https://groups.google.com/ forum/?fromgroups#!topic/php-fig/EKDIoSHqMSo), yesterday at midnight the nominations ended, and

Re: Working Group for PSR-5

s awesome Chuck. Will phpDocumentor3 be based on psr-5? > > On Tuesday, 30 January 2018 07:25:54 UTC+13, Chuck Burgess wrote: >> >> Hey everyone, >> I intend to get this rolling again soon. I'm first working on helping >> get phpDocumentor3 finished up, so that I'll h

Re: Working Group for PSR-5

Secretaries, I'd like to request taking over as Editor on PSR-5, and request a new Core Committee sponsor as per the new workflow. I'm not too far off from finishing the preliminary phpdoc3 alpha release steps that I wanted in place before resuming this effort. CRB -- You received this

Re: There MUST be one use keyword per declaration <-- does this still apply in PHP7

PSR2 indeed predates PHP7. CRB On Feb 2, 2018 14:05, "Julian Vidal" wrote: I write my projects using PSR-2 enforced by my IDE (PhpStorm) and have phpcs constantly in the background too. While working today, I found something odd that I would like to discuss in this list.

Re: Working Group for PSR-5

Gary Hockin, Alexander Makarov, Richard Quadling: Are you three still available for the initial working group? Core Committee: Can I get a willing sponsor for PSR-5? CRB -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

Re: Working Group for PSR-5

Hey everyone, I intend to get this rolling again soon. I'm first working on helping get phpDocumentor3 finished up, so that I'll have a baseline implementation to work from. Once that's released, I'll be re-pinging this thread to see about formally building a Working Group. CRB -- You

Re: Working Group for PSR-5

At this point, I have a CC sponsor and one WG member. Joe T., are you still interested? On Jan 31, 2018 09:45, "Gary Hockin" <g...@hock.in> wrote: > Yep, I'll sponsor and be involved in the WG. > > G > > On Wed, 31 Jan 2018 at 15:43 Chuck Burgess <demon.g...@

Re: PSR-16 question

Purpose of the interfaces is to make those exact exception types *catchable*... that's all. On Feb 24, 2018 13:56, "Alice Wonder" wrote: > I have a personal cache class that would be cake to port to use PSR-16, > but PSR-16 also defines two exception interfaces. > >

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

Alessandro Lai Ian Littman PEAR On Sat, Aug 4, 2018, 11:36 Dead Lugosi wrote: > Ohai FIG Humans, > > It's time to cast your votes for new Secretary terms > ! > > We have two openings we are voting on: > >- The Secretary

Re: Abandoned PSR-5

Hey Alice, I'm slowly trying to form a Working Group in order to resurrect PSR-5. CRB On Mar 15, 2018 13:28, "Alice Wonder" wrote: Is there any desire to bring something like PSR-5 back? There are two reasons why I think there should be some standards related to

Re: PSR status update

und some PSR that need a little more participation. Here it is: PSR-5 (PHPDoc) Status: abandoned / regrouping Last time, it was brought up to be resurrected with a new and fresh working group (https://groups.google.com/forum/?fromgroups#!topic/php- fig/bcV4KXIW6dQ): Chuck Burgess expressed his in

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

https://github.com/php-fig/fig-standards/pulls On Sun, Sep 30, 2018, 14:10 Rasmus Schultz wrote: > Hi Chuck, > > I can do a PR, but where's the repository? > > - Rasmus > > On Fri, Sep 28, 2018 at 9:06 PM Chuck Burgess > wrote: > > > > On Tuesday, September

Re: General issues with doc-blocks and annotations in PSRs

On the surface of the argument, I'm thinking you're correct that the interface code docblocks do *not* need to repeat the spec requirements. All three images seem to be the same image, though, so they are not matching your examples. CRB *about.me/ashnazg * On Fri, Oct

[PSR-5][PSR-19] PHPDOC PSRs

Hello everyone, The Working Group for PSRs 5 and 19 has resumed previous work that was left open in the phpDocumentor fork of fig-standards ( https://github.com/phpDocumentor/fig-standards/). Please get involved there with your ideas and feedback for these efforts. I will periodically take

[PSR-5][PSR19] PHPDOC PSRs

Hello everyone, The Working Group for PSRs 5 and 19 has resumed previous work that was left open in the phpDocumentor fork of fig-standards (https://github.com/phpDocumentor/fig-standards/). Please get involved there with your ideas and feedback for these efforts. I will periodically take

Re: [PSR-5][PSR-19] Improvement ideas for annotation typings

Regarding #1, please join the discussion at https://github.com/phpDocumentor/fig-standards/pull/81 CRB *about.me/ashnazg * On Sat, Oct 13, 2018 at 9:32 AM Marco Perone wrote: > Hi, > > I would like to share some (not very refined) ideas regarding the usage of > PHPDoc

[PSR-19] deprecate double closing brace on inline internal tag

Following historical precedence from phpDocumentor 1.x, the inline `@internal` tag used an unusual syntax: `{@internal*}}*` (note the double closing braces) >From the 1.x manual: Unlike other inline tags, {@internal}} may contain other inline tags due to its purpose. To terminate an

[PSR-5] Variadic Parameters

The current draft does not contain references to or examples of variadic parameters, since they entered the PHP language after the early PSR-5 drafts were done. Assuming that folks agree that they should be represented in the spec, this email thread opens the discussion on the syntax to use.

[PSR-5][PSR-19] Weekly Update

the tag catalog requires. From these two cleaned up baselines, discussions on changes will have a better reference point. 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

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

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 */`

Re: Post deleted not 5 seconds efter posting?

I did receive the initial post as an email... and replied to it... It looks like the original *was* deleted, but the thread is safely here -- https://groups.google.com/forum/#!topic/php-fig/wdjT-Orf5XM CRB On Saturday, October 13, 2018 at 3:46:46 AM UTC-5, Rasmus Schultz wrote: > > > it

[PSR-5] Intersection Types

r 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 the Google Groups "PHP Framework Interoperability Group" grou

Re: [PSR-5] Intersection Types

;> (I don't have use-case for this at this point). Also the grammar currently >> requires `|` to be before `&`- so something like `A|C` would not be >> supported - I'm not sure if this is intentional? Maybe it's best to only >> either support `|` or `&`, but n

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

eta.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 > Kor

Re: [PSR-5] Variadic Parameters

On Monday, October 15, 2018 at 4:23:46 PM UTC-5, Stefano Torresi wrote: > > Hey list, > what if one wanted to hint to a varable number of arrays of DateInterval? > > e.g. `func(array ...$intervals) {}` > > Isn't this what `@param DateInterval[] ...$intervals` should actually be > used for? > >

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

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

Re: [PSR-5][PSR-19] PHPDOC PSRs

] -- https://github.com/phpDocumentor/fig-standards [2] -- https://github.com/php-fig/fig-standards/blob/master/README.md#github-usage [3] -- https://github.com/php-fig/fig-standards/tree/master/proposed On Friday, October 12, 2018 at 1:58:57 PM UTC-5, Chuck Burgess wrote: > > Hello ev

Re: [PSR-5] Intersection Types

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

Re: [PSR-5] Summary

Yes, I agree. I believe this requirement in the original draft was in line with phpDocumentor's requirement that a Summary *and* Description should *both* be present in DocBlocks. In that context, the requirement makes sense. Since the spec is only delineating how the pieces in a DocBlock

Re: [PSR-5] Summary

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

Re: [PSR-5] Summary

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

[PSR-19] Working Group Plan

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

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

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

Re: [PSR-5] Summary

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

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

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

Re: [PSR-19] Working Group Plan

ithub.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 throu

Re: [PSR-5] Summary

and.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 expli

Re: [PSR-5] Intersection Types

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

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

'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: >> >&

Re: [PSR-5] Intersection Types

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

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

... > } > > 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? &g

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

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

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

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

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

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

Re: [PSR-19] Class and methods links

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,

Re: [PSR-19] Class and methods links

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

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

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

Re: [PSR-5] Intersection Types

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 is

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

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

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

I now have the old sandbox repo updated, so we can resume using it instead of using the FIG repo itself: https://github.com/phpDocumentor/fig-standards/pulls <https://github.com/php-fig/fig-standards/pulls> CRB On Sunday, September 30, 2018 at 2:13:32 PM UTC-5, Chuck Burgess wrote: >

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

On Tuesday, September 18, 2018 at 3:21:19 AM UTC-5, Rasmus Schultz wrote: > > I believe it's also closer to the current interpretation in PHP Storm. > > So I'd like to propose changing the definitions of these tags: > > The @api tag would be for documentation purposes only - e.g. could be used >

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

On Thursday, September 20, 2018 at 9:26:56 AM UTC-5, Rasmus Schultz wrote: > > > It seems more "secure" to whitelist public thing, rather than blacklist > private thing > > The problem is that you're arguing with the language, where everything is > public - and not just by default. > > To start

Re: [PSR-5] Intersection Types

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

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

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

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

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

Re: PSR-19 Prevent PHPDoc inheritance

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

Re: PSR-19 @triggers tag

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

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

rry 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

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

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

Re: [PSR-5] Intersection Types

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,

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

Vote 1 (PHPDoc PSR-5): Yes Vote 2 (PHPDoc Tags PSR-19): Yes Chuck Burgess On Fri, Sep 14, 2018, 12:40 Michael Cullum wrote: > Hi all, > > PSR-5 has been quiet for a long time and it's recently been revived. The > next step is having an entrance vote for the Core Committee.

Re: Working Group for PSR-5

, 2018, 12:50 Nikolaos Dimopoulos wrote: > Also interested in helping if you need more people. Similar to Joe, i am > new to the WG process but happy to help if you need me > > Nikos > Phalcon Framework > > On Monday, February 12, 2018 at 8:04:45 PM UTC-5, Chuck Burgess wrote

Re: [REVIEW] PSR-14 Event Dispatcher

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

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

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

Re: Proposal: Adopt Code Manifesto

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,

Re: [INTERNAL] Core Committee & Secretary nominations open

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

Re: [INTERNAL] Core Committee & Secretary nominations open

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

Re: [VOTE] Core Committee Election

>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

Re: PSR-19. inline @see tag

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

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

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

Re: A question about PSR-12

et/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 >> wro

Re: A question about PSR-12

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 |

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

+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

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

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

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

+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

Re: [VOTE] Core Committee Election

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

Re: PSR Evolution, PSR-13, and nuance

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

Re: PSR Evolution, PSR-13, and nuance

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

  1   2   >