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 optio
Any reason not to consider another variant which may be clearer than either
of the current proposals? For example:
* @param DateInterval[...] $intervals
This syntax indicates the value is an array, but is generated as such from
a variadic list, rather than passing an actual array. That then allow
Wait, `::class` works on objects?
On Mon, Aug 20, 2018, 09:38 wrote:
> To use `::class`, the event object must have already been created. To that
> I wonder if, when attaching events to listeners by name, should this really
> be a hard requirement (i.e. the event object being created)?
>
> On Mo
This last point feels like an agreement for not having a coding standards
PSR at all... "Just preprocess all the code you ever work with so it
follows whatever style you personally prefer" is pretty much where we
started before PSR-2. Not something I disagree with, mind - that kind of
flexibility i
y quick example only
included the one type.
On Sun, Apr 22, 2018, 22:08 Greg Sherwood wrote:
> On Monday, 23 April 2018 14:00:11 UTC+10, Daniel Hunsaker wrote:
>>
>> Multiple spaces before (or, less often, after) an operator can be useful
>> when attempting to align
Multiple spaces before (or, less often, after) an operator can be useful
when attempting to align operands.
wrote:
> Agreed! When does *more* than one space (aside from newlines) ever make
> sense? i hope these details get resolved...
> -jlt
>
>
> On Sunday, 22 April 2018 20:08:00 UTC-4, Greg Sh
On Thursday, April 13, 2017 at 8:55:25 AM UTC-6, Michael Mayer wrote:
>
> We should distinguish 3 cases:
>
>1. non-BCs, like adding methods etc.
>2. BCs for some PHP versions, like adding parameter type declarations
>3. BCs for all PHP versions, like adding return type declarations
>
>
I can't sponsor, but I'll gladly join the WG.
On Thursday, January 12, 2017 at 3:41:15 PM UTC-7, 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
> remai
That's probably because the PSR hasn't been finalized/released, yet. Once
that happens, you'll probably see these otherwise-compliant implementations
inherit from the PSR interface, too.
On Fri, Jan 6, 2017, 04:00 'seva dolgopolov' via PHP Framework
Interoperability Group wrote:
> looks good, b
On Sunday, November 27, 2016 at 9:07:26 AM UTC-7, Nicolas Grekas wrote:
>
>
>
>> couldn't all these new interfaces move in the Psr\Cache namespace (thus
>>> releasing them as psr/cache 1.1 on packagist?)
>>>
>>
>> That's an interesting idea, but also kinda confusing for users because
>> Psr\Cac
Certainly feels as though the separation of container-get from
container-set has caused a lot of disagreement, here. It also looks like
there's a *lot* of feedback here saying there need to be at least two
interfaces in container-set - SharedContainer and FactoryContainer - and
that many projects
On Thursday, October 6, 2016 at 12:46:28 PM UTC-6, Pedro Cordeiro wrote:
>
> I understand the reasoning now. It saddens me a little (as an end user)
> that I still won't be able to have truly agnostic implementations that
> depend on a container (because I need to set the entries, after all, so
On Saturday, September 24, 2016 at 7:29:55 AM UTC-6, Rasmus Schultz wrote:
>
> Hey FIG,
>
> This week, I found myself doing some work with native PHP stream
> resources. This particular work had no relation to HTTP at all, but to SMTP
> as it happens. While writing this project, I thought, I shou
>
> >> I'd expect an object implementing a CollectionInterface to be iterable
> and
> >> to already contain the items in question. The current implementation of
> the
> >> LinkCollectionInterface though looks more like a CollectorInterface.
> >> Something that collects linkInterfaces and can
On Sunday, September 11, 2016 at 8:44:29 AM UTC-6, Alexander Deruwe wrote:
>
> On Sun, Sep 11, 2016 at 4:05 PM, Adam Culp > wrote:
> > Let's stop applying the rules of "serious" PSRs to such a thing and
> > get rid of it.
>
> This. It's so obvious, please.
>
It's also a very dangerous precede
>
> > We [secretaries] discussed PSR-8 a while back and we've also been part
> of numerous conversations with Larry [PSR-8 Editor] and other folks and we
> came to the conclusion that it doesn't appear there is really a way to
> withdraw PSRs for the moment.
>
> Interesting; was that brought u
>
> > Hopefully should FIG 3 pass the Core Committee can take up this question
> > more effectively, but I don't know that there's a reason to bother if
> > we're not even going to make quorum.
>
> TBH, I find this a bit scary. In fact if FIG 3's Core Committee was
> already in place, there's
To reiterate, this change would *not* affect finalized, approved PSRs at
all. It is *explicitly* only for future PSRs.
For my part, I've always been annoyed by including the type of item in the
name of the item itself (Interface, Trait, Controller, Model, etc),
especially when the namespace alrea
other member projects in the first place, and only discovering that fact
after sending the PSR to the CC for approval. But I also expect the CC
would point this out during the initial acceptance vote on whether a PSR
should even be created, if the WG didn't already note such scope in their
pr
>
> Er. Except that's not true. PHP itself throws exceptions only in two
> very specific cases:
>
> * PDO, if configured to do so.
> * random_int()/random_bytes(), if no entropy source can be found.
>
Hrm. Must've been working inside frameworks too long. Of course PHP
doesn't throw exceptio
On Wednesday, July 27, 2016 at 9:38:48 AM UTC-6, Takashi Matsuo wrote:
>
>
> On Tuesday, July 26, 2016 at 4:01:17 PM UTC-7, Larry Garfield wrote:
>>
>> From http://www.php-fig.org/psr/psr-6/#error-handling
>>
>> " For that reason Implementing Libraries MUST NOT throw exceptions other
>> than tho
requirements.
>
+1 from non-project dev (I'm arguably one of the most-active devs on
PHP-Resque, but that's not a member project, so doesn't qualify)
Also, +1 each on both side points above.
- Daniel Hunsaker
--
You received this message because you are subscribed to the
terface
LinkCollectionWithInterface extends LinkCollectionInterface
This does have the side effect of diminishing the focus on the key
difference between the interfaces, though, by "burying" it in the interface
name. So it may not be ideal.
Just some thoughts (provided mostly by burying my head
23 matches
Mail list logo
