[PSR-5] Iterator Typehinting

[Damian Mooyman]

Hello, I understand that at this time PSR-5 is lacking a sponsor, but I 
trust that it's ok for us to continue discussing ideas.

I would like to add to the list of open issues 
(from 
https://groups.google.com/forum/#!searchin/php-fig/psr-5%7Csort:relevance/php-fig/Rg4fugqGyzU/muMXYZPTeWEJ)
 
a proposal to support a standard phpdoc syntax for typed iterators.

I consider this to really be a separate (but related) discussion to the 
generics proposal at 
https://groups.google.com/forum/#!msg/php-fig/lSfzx7Ubstc/6vjz3ILThS0J;context-place=forum/php-fig

Out in the wild, I've seen two alternative approaches that can be applied 
at the class-level to apply typing to iterators.

1. PHPStorm has a non-standard __iterator 
method https://youtrack.jetbrains.com/issue/WI-18972
2. IteratorAggregate subclasses can override the getIterator() method 
hinting, as commented 
at https://github.com/php-fig/fig-standards/pull/169#issuecomment-46590615

However the problems with the above are, 1. __iterator() isn't a real (or 
magic) method, and 2. getIterator() actually returns an object of type 
Traversable or Iterator, and thus overriding these with another type is not 
strictly correct.

If I wish to propose an explicit syntax, is it ok for me to discuss it 
here, or should I open this on github? I could PR to the current PSR-5 if 
that's the best way to propose a change, maybe after a little bit of 
pre-discussion.

Thanks for hearing me out, and I hope I can actually start contributing to 
the group for once. :)

Kind regards,

Damian Mooyman | SilverStripe

-- 
You received this message because you are subscribed 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/27af85f2-9b0b-458a-95e8-8db3e86e4408%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] "FIG 3.0" Bylaw amendments

[Robert Hafner]

-1 from Stash for similar reasons. I think more time needs to be spent on this.

Rob

> On Aug 19, 2016, at 8:48 PM, Nate Abele  wrote:
> 
> -1 from Lithium. This seems very premature. All I've seen in response to 
> legitimate concerns in hand-waving.
> 
>> On Friday, August 19, 2016 at 2:39:19 PM UTC-4, Larry Garfield wrote:
>> A few days later than planned, but I am hereby opening a vote for the 
>> following bylaw changes, colloquially known as "FIG 3.0". 
>> 
>> https://github.com/php-fig/fig-standards/pull/752 
>> 
>> The vote will be open for 2 weeks, closing on 2 September 2016 @ 23:59 UTC. 
>> 
>> As usual, the vote is open to voting representatives only and is a 
>> simple +1/-1 vote. 
>> 
>> --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/0c8b3740-8fd8-49bc-9e54-4673a8d8ef12%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/93B7C052-26C5-46D3-BA8C-0B9A0FDC529C%40tedivm.com.
For more options, visit https://groups.google.com/d/optout.

Re: [FIG 3.0] Need clarifications about core committee

['Alexander Makarov' via PHP Framework Interoperability Group]

Chris Tankersley, thanks for info. I've somehow missed renewal terms. 
Members are elected for 2 years. That's probably a bit lengthy period.

Do you know why the number of core committee members is exactly 12?

I understood that after work is done, proposal is passed to core committee 
for final vote. I still wonder what happens if current core committee 
members do not have expertise about the topic to vote... they can ensure 
quality of the text itself and its clarity but can't ensure that the 
proposal itself is a good one. Probably not a big issue since proposal 
already passed multiple stages.

*// Just realized I haven't finished 2nd sentence :) Please ignore "To me 
it looks wrong that".*

On Monday, August 22, 2016 at 1:12:42 AM UTC+3, Chris Tankersley wrote:
>
>
>
> On Sunday, August 21, 2016, 'Alexander Makarov' via PHP Framework 
> Interoperability Group  wrote:
>
>> Voting on FIG 3.0 started. I've read diff of the changes (huge one), TLDR 
>> at medium and searched ML but haven't found answers to some questions. 
>> Please help me find the answers. Thanks!
>>
>> 1. What's the reason to limiting core committee to 12 members? To me it 
>> looks wrong that 
>>
>
> If I remember correctly, the idea was to have a smaller, dedicated core 
> group to encourage the members to be more active. All of the work regarding 
> each PSR will be handled by the individual working groups though, which may 
> contain core members but ideally are made up of many different member 
> projects. 
>  
>
>> 2. Why 12 exactly? What if there's a PSR on a topic any of these 12 
>> members don't care about or don't have expertise about?
>>
>
> That's what the working groups are for. The Working Group should be made 
> up of people interested and knowledgeable about the topic. When the PSR is 
> all finished (wording and two implementations) and ready to be finalized, 
> it's passed onto the core committee for a final vote. 
>  
>
>> 3. Have I missed information about how core committee members are rotated 
>> / re-elected?
>>
>
> That info was in the PR for the change. I'm on mobile otherwise I would 
> link to it. 
>  
>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to php-fig+unsubscr...@googlegroups.com.
>> To post to this group, send email to php-fig@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/php-fig/8629479a-0c05-468d-9705-a1003d1bc368%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> 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 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/945b4095-6142-4b38-b4ae-35d7b03bbf25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Daniel Plainview]

This conversion (like some others in this group) looks like the following:

— Why do we need X? 
— Because we can do Y with it!
— Are you sure that Y is a good thing?
— *no answer*.
— OK, let's keep X.

Just for clarity, arguments for this exception are:

* "PEAR most definitely wants to keep the package-level base exception, as 
it is a convention we always expect to be available" -- Because PEAR does 
it.
* "I would also only type-hint against the PSR exceptions for catches." -- 
 Because we can do Y. 
* "having the granularity is nice, and I could potentially see writing 
plugins for systems such as Zend's Z-Ray, Blackfire, etc." -- Interesting 
point. However, I think it has high cost (boilerplate code, noise in shiny 
interfaces, etc.).
* "There are all sorts of unexpected exceptions that an underlying 
implementation might throw .. Those should be made consistent between 
implementations so that I don't have to worry about those differences." -- 
No difference with catch (\Exception)
* "Which would give us a catchable ContainerException, with a 
human-friendly message/code, and access to the underlying 
implementation-specific exception as well if appropriate for debugging." -- 
If the point is to have human-friendly message, you can rethrow it with any 
another exception class, i.e. no difference with throw new 
\RuntimeException('User-friendly message', $e).
 
I have strong feeling that all these exception madness comes from the fact 
that PHP has no concept of checked/unchecked exceptions at language like 
Java, C# and others.
It leads to misunderstandings: do we break BC if we would throw exception 
like \InvalidArgumentException? Should we declare ContainerException in the 
interface? Etc.

If we took into account checked/unchecked separation, we would find out 
that most of noisy and technical exceptions are not supposed to be part of 
public API (interface).
We wouldn't discuss a lot about "Does \InvalidArgumentException break BC?"; 
we wouldn't see many technical notes like this one 

.

Consider NullPointerException from Java.
Does it make sense to rethrow NullPointerException as ContainerException?
Does it OK for you that you'd have bigger trace because of 2 exceptions 
(ContainerException + previous)? It makes debugging harder I think, not 
easier like someone said above. 
Any method can throw NullPointerException. Code must deal with it. It makes 
no sense to convert it to ContainerException.

ContainerException doesn't allow you to understand what exactly is wrong 
with container.
If you just want to prevent program crash because of it, you'd catch just 
\Exception or even \Throwable, no point to catch ContainerException.

ContainerException is unnecessary noise in your shiny interface. Like any 
other noise it moves developer away from the domain (DI containers in this 
case), it makes him think about unnecessary technical details. It doesn't 
help, seriously. 

On Sunday, August 21, 2016 at 11:36:05 PM UTC+3, Matthieu Napoli wrote:
>
> Hi all, thanks for participating in this discussion.
>
> While David and I feel the same, it seems we are alone. We do not see real 
> usage (not implementations or "what ifs" but actual usage) of that 
> interface today (see https://github.com/php-fig/container/pull/2).
>
> However its not worth blocking PSR-11 any longer because of such a detail, 
> so let's go with the majority and move forward!
>
> Matthieu
>

-- 
You received this message because you are subscribed 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/330b6616-55f5-46ee-b9dd-089488309ffc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] "FIG 3.0" Bylaw amendments

[Ben Marks]

+1 Magento

On Saturday, August 20, 2016 at 2:39:19 AM UTC+8, Larry Garfield wrote:
>
> A few days later than planned, but I am hereby opening a vote for the 
> following bylaw changes, colloquially known as "FIG 3.0". 
>
> https://github.com/php-fig/fig-standards/pull/752 
>
> The vote will be open for 2 weeks, closing on 2 September 2016 @ 23:59 
> UTC. 
>
> As usual, the vote is open to voting representatives only and is a 
> simple +1/-1 vote. 
>
> --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/0aca8b80-c192-4453-b0e0-c62760edc17e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [FIG 3.0] Need clarifications about core committee

[Chris Tankersley]

On Sunday, August 21, 2016, 'Alexander Makarov' via PHP Framework
Interoperability Group  wrote:

> Voting on FIG 3.0 started. I've read diff of the changes (huge one), TLDR
> at medium and searched ML but haven't found answers to some questions.
> Please help me find the answers. Thanks!
>
> 1. What's the reason to limiting core committee to 12 members? To me it
> looks wrong that
>

If I remember correctly, the idea was to have a smaller, dedicated core
group to encourage the members to be more active. All of the work regarding
each PSR will be handled by the individual working groups though, which may
contain core members but ideally are made up of many different member
projects.


> 2. Why 12 exactly? What if there's a PSR on a topic any of these 12
> members don't care about or don't have expertise about?
>

That's what the working groups are for. The Working Group should be made up
of people interested and knowledgeable about the topic. When the PSR is all
finished (wording and two implementations) and ready to be finalized, it's
passed onto the core committee for a final vote.


> 3. Have I missed information about how core committee members are rotated
> / re-elected?
>

That info was in the PR for the change. I'm on mobile otherwise I would
link to it.


> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com
> .
> To post to this group, send email to php-fig@googlegroups.com
> .
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/php-fig/8629479a-0c05-468d-9705-a1003d1bc368%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


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

Re: [VOTE] Secretary Election August 2016

[Damian Mooyman]

SilverStripe's votes:

1. Paul 'PMJ' Jones
2. Samantha Quiñones
3. Amanda Folson
4. Matthew 'Matt' Trask
5. Jonathan Reinink

On Saturday, 13 August 2016 10:24:40 UTC+12, 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 term ending (Previously 
> filled by Samantha) and a vacancy to fill (after Joe's resignation), so two 
> secretaries will be elected. Whoever comes first will be in post until 
> August 2018 and the term of whoever is second will end in 8 months.
>
> Samantha is standing for re-election, but she is just as any candidate, 
> and therefore may be elected into either term, or neither. No matter the 
> outcome, I am sure you will all join me in offering a word of thanks on 
> behalf of the FIG to both Samantha and Joe for their work these past 6-8 
> months.
>
> Full information about the Secretary vote and role is visible in the 
> bylaws here: 
> https://github.com/php-fig/fig-standards/blob/master/bylaws/003-membership.md#fig-secretary
>
> I suggest you check out their nomination topics for information about 
> themselves and to ask questions. All candidates except Paul (as his 
> nomination was quite late in the process) have spoken with Samantha or 
> myself about what the role entails and I'd add that they all appear to be 
> aware of both the commitment required and the role/responsibilities defined 
> in the bylaws.
>
> *Nominations List*
>
>- Jonathan Reinink - Topic 
>
>- Samantha Quiñones - Topic 
>
>- Matthew 'Matt' Trask - Topic 
>
>- Phil Sturgeon - Topic 
>
>- Paul 'PMJ' Jones - Topic 
>
>- Amanda Folson - Topic 
>
>
> *How to vote*
> The voting system used is STV[1][2], so basically, *there is no tactical 
> voting possible* (like with FPTP); *vote for who you want*, even if they 
> are a less popular candidates as your vote will move down to a different 
> candidate if you back an unpopular candidate who doesn't have enough votes; 
> if a candidate is elected, their surplus votes are also re-allocated so you 
> are not punished for backing popular candidates either. There is no quorum, 
> you are of course entitled to not vote and it will not count as a missed 
> vote on the voting sheet. *Rank the candidates in order of preference *for 
> example*:*
>
> 1. Luke
> 2. Leia
> 3. Anakin
> 4. Rey
> 5. Padmé
> 6. Finn
>
> *You may, if you wish, not rank all six candidates* (however this is 
> relatively pointless in STV, only do this if your bottom candidates are of 
> equal preference to you). For example:
>
> 1. Luke
> 2. Anakin
> 3. Padmé
> 4. Leia
>
> *The vote ends at 23:59 UTC on the 26th August,* and I will close the 
> vote and *announce the result at some point on the 27th*. At any time, 
> any candidate or voting member may privately ask me to do a count and tell 
> them who would be elected to which term if the vote ended at that point. 
> Please be wary of 'STV calculators' on the internet as there are many 
> different ways of calculating the vote reallocation for STV and many are 
> inaccurate, our methods are dictated in the bylaws.
>
> *Finally*, I will repeat something I have reiterated privately to 
> candidates and in a nomination topic:
>
>> I'd ask everyone keep this election fair and clean. Secretaries are in 
>> the role they are in to be neutral and I'd ask people consider the impact 
>> that bringing (for lack of a better term) politics into a Secretary 
>> election could have on that Secretary's ability to do their job and in the 
>> same way, candidates may very well be expected to soon represent a neutral 
>> position so I would recommend they keep this in mind throughout the 
>> election. In the same fashion, I'd ask that once a Secretary is elected, 
>> whoever they may be, they are given the chance to execute their duties 
>> properly and are given a chance *by all*; nobody wants to see the FIG 
>> split due to who has been elected, or who hasn't been elected, as Secretary.
>
>
> Good luck to all the candidates!
>
> --
> Many thanks,
> Michael Cullum
> FIG Secretary & August 2016 Secretary Election Returning Officer
>
> [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 

Re: [VOTE] PSR-6 Errata

['Alexander Makarov' via PHP Framework Interoperability Group]

- 1 from Yii framework. It's very significant backwards compatibility 
change.

On Friday, August 19, 2016 at 9:44:01 PM UTC+3, Larry Garfield wrote:
>
> I hereby open a vote for the following Errata for PSR-6: 
>
> https://github.com/php-fig/fig-standards/pull/787 
>
> Basically, it's a vote to merge that PR. 
>
> The vote will be open for 2 weeks, closing on 2 September 2016 @ 23:59 
> UTC. 
>
> As usual, the vote is open to voting representatives only and is a 
> simple +1/-1 vote. 
>
> I definitely appreciate the point that an InvalidArgumentException would 
> have been better, and had this issue been brought up during the Review 
> phase I'd probably have gone that direction.  However, adding an 
> exception does count as an API change, albeit a small one, so I am not 
> comfortable with that direction in an Errata. (Obviously if you feel 
> that this is a bad decision, vote -1.) 
>
> --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/f4a7959d-6a99-43e5-acae-d6c6405cb276%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Lukas Kahwe Smith]

> On 21 Aug 2016, at 22:28, Matthieu Napoli  wrote:
> 
> I agree in so far that we need to acknowledge that there will be PSRs 
> superseding previous PSRs and there will be PSRs that are incompatible to 
> previous PSRs.
> 
> Hi Lukas, could you explain what incompatibilities you see?
> 
> Just to be clear there is no plan to change any existing PSR. And there is no 
> plan to replace them with new PSRs that adopt the new convention.
> And if a new PSR depends on another currently existing PSR, it will use the 
> existing names, not new (non-existing) ones. Example: PSR-15 should use 
> `RequestInterface`, it shouldn't use `Request` just because of the new 
> convention (because obviously it will not work: the interface does not exist 
> under that name).
> The goal is not to break anything, if you see such a scenario let's discuss 
> it.

it was a general comment in reply to your general comment that past decision 
should not prevent is from doing something different in the future.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org



-- 
You received this message because you are subscribed 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/4780D36D-7FA1-4ED6-B367-C78F65E63F05%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PSR-11] Remove ContainerException

[Matthieu Napoli]

Hi all, thanks for participating in this discussion.

While David and I feel the same, it seems we are alone. We do not see real 
usage (not implementations or "what ifs" but actual usage) of that 
interface today (see https://github.com/php-fig/container/pull/2).

However its not worth blocking PSR-11 any longer because of such a detail, 
so let's go with the majority and move forward!

Matthieu

-- 
You received this message because you are subscribed 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/449a56fa-defe-48e5-80fc-87348f2409d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthieu Napoli]

>
> I agree in so far that we need to acknowledge that there will be PSRs 
> superseding previous PSRs and there will be PSRs that are incompatible to 
> previous PSRs. 
>

Hi Lukas, could you explain what incompatibilities you see?

Just to be clear there is no plan to change any existing PSR. And there is 
no plan to replace them with new PSRs that adopt the new convention.
And if a new PSR depends on another currently existing PSR, it will use the 
existing names, not new (non-existing) ones. Example: PSR-15 should use 
`RequestInterface`, it shouldn't use `Request` just because of the new 
convention (because obviously it will not work: the interface does not 
exist under that name).
The goal is not to break anything, if you see such a scenario let's discuss 
it.

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/eb99acd6-d4d9-41fa-bd52-3dd16794bd34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Questions on some coding styles

['Alexander Makarov' via PHP Framework Interoperability Group]

Indeed these aren't addressed in PSR-2. There's PSR-12 in the works 
.
 
First two cases aren't addressed as well so I've created issue for these:

- https://github.com/cs-extended/fig-standards/issues/37
- https://github.com/cs-extended/fig-standards/issues/38

Third case is addressed partially.

On Friday, August 19, 2016 at 5:08:13 AM UTC+3, kapitanluffy pirata wrote:
>
> I was looking at PSR-2 and there are no suggestions to the following:
>
> - Should empty lines have tabs that align with lines that have characters 
> or should it be fully empty?
>
> - When assigning variables, I see some aligning the equals sign (=) using 
> spaces while others just use a space before and after the equals sign.
>
> - should the dot have before and after spaces when concatenating strings?
>
>
> I know PSR are just 'recommendations' and everyone can set their own 
> standards along with PSR-2 but it would be great if we have "something to 
> look up to" for a lack of better term
>

-- 
You received this message because you are subscribed 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/304ce5af-9720-420f-8b81-f2883e9f8110%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Lukas Kahwe Smith]

> On 21 Aug 2016, at 22:07, Matthieu Napoli  wrote:
> 
> The question of consistency with existing PSRs has been raised a lot. I don't 
> see that as a problem.
> It's OK to move forward and change a convention if we want to, each PSR is 
> independent from the rest. Consistency for this is a very small detail 
> compared to developer experience, we shouldn't limit improvements for no 
> tangible reason.

I agree in so far that we need to acknowledge that there will be PSRs 
superseding previous PSRs and there will be PSRs that are incompatible to 
previous PSRs.
But overall I have not seen any significant arguments from either side that 
would sway me in either direction and as such I would stick with the status quo.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org



-- 
You received this message because you are subscribed 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/B32229E2-A372-4ED9-9596-727E61A2881B%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Matthieu Napoli]

The question of consistency with existing PSRs has been raised a lot. I 
don't see that as a problem.
It's OK to move forward and change a convention if we want to, each PSR is 
independent from the rest. Consistency for this is a very small detail 
compared to developer experience, we shouldn't limit improvements for no 
tangible reason.

-- 
You received this message because you are subscribed 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/563037a1-0875-4374-b5d2-e662c5ebbc64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] PSR-6 Errata

[Matteo Beccati]

-1 from Revive Adserver.

I feel that failing with an E_USER_ERROR that can't be caught is an even 
bigger API change. Almost evil, I would say.



On 19/08/2016 20:43, Larry Garfield wrote:

I hereby open a vote for the following Errata for PSR-6:

https://github.com/php-fig/fig-standards/pull/787

Basically, it's a vote to merge that PR.

The vote will be open for 2 weeks, closing on 2 September 2016 @ 23:59 UTC.

As usual, the vote is open to voting representatives only and is a
simple +1/-1 vote.

I definitely appreciate the point that an InvalidArgumentException would
have been better, and had this issue been brought up during the Review
phase I'd probably have gone that direction.  However, adding an
exception does count as an API change, albeit a small one, so I am not
comfortable with that direction in an Errata. (Obviously if you feel
that this is a bad decision, vote -1.)

--Larry Garfield




--
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 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/bbb4657b-be65-84ac-1a0a-284548bb5bbf%40beccati.com.
For more options, visit https://groups.google.com/d/optout.