gt; - myself (Sponsor)
> - Stefano Torresi
> - Matthieu Napoli
> - Korvin Szanto
> - Glenn Eggleton
> - Oscar Otero
> - Tobias Nyholm
>
> The by-laws do not stipulate a time-frame for how long the vote must
> run, though 2 weeks is the standard period. As such, th
t; > We are still in the process of forming a working group regarding a
>>> Service
>>> > > provider PSR.
>>> > >
>>> > > I've had the chance to speak about this with several Symfony
>>> contributors,
>>> > > and while di
I have to agree with Larry, having the behavior of a standard depend on
some configuration is risky. If the goal of the PSR is to be used by
libraries or frameworks (not end users) then it's fine to force a choice
IMO.
I have minor comments about the proposal, maybe it's too early to get into
Hi Michael, those are interesting points, my answers inline:
On Sunday 21 may 2017 10:43:57 UTC+2, Michael Mayer wrote :
>
>
> On Saturday, May 20, 2017 at 10:33:33 PM UTC+2, Matthieu Napoli wrote:
>
>> Rasmus:
>>
>> I can see the handler-interface having 3
Hi everyone,
I've been following that discussion, I just want to react to a few things:
Woody:
This works perfectly well for simple systems and not so well for more
> complex systems. For instance, if we have a complex application where there
> is a "user" part and an "admin" part, the admin
>
> > This is Symfony's HttpKernelInterface and StackPHP and it has already
> been discussed at length
>
> Same principle, yes, but what I recall being discussed at length was the
> lambda-style vs double-pass aspect, which seems unrelated to this
> discussion.
>
> I found one or two older
Hi,
This is Symfony's HttpKernelInterface and StackPHP and it has already been
discussed at length, I'm not sure why we are starting it all again?
Matthieu
Le vendredi 21 avril 2017 17:42:11 UTC+2, Rasmus Schultz a écrit :
>
> I hate to do this at a time when the middleware PSR is probably
Larry,
> Unsurprisingly I'd favor PR 3: Explicit exception.
>
> I'll be honest that I'm still very confused why there's so much
> resistance from the Editors on using exception types for what they're
> supposed to be used for. Different error condition, different
> exception. In 20
Hi everyone,
Here are my votes:
- Matthew Weier O’Phinney
- David Négrier
- Sara Golemon
- Beau Simensen
- Lukas Kahwe Smith
- Gary Hockin
- Cees-Jan Kiewiet
- Michael Heap
Matthieu Napoli
Le vendredi 9 décembre 2016 17:47:36 UTC+1, Michael Cullum a écrit
Hi,
This is a good point. However there's a discussion about removing the
delegate lookup entirely from PSR-11
here: https://groups.google.com/forum/#!topic/php-fig/9YAFG4Xw2zo That
would remove that issue I think.
Cheers
Matthieu
Le samedi 3 décembre 2016 18:10:16 UTC+1, Michael Mayer a
> This way I can catch all container exceptions using
> ContainerException, or the individual exception I am interested in. In
> your example, it would not be possible to catch only exceptions raised
> by the container, as other Exceptions could be raised (if for example
> pulling service config
I'm fine with both option (include or don't include it in PSR-11).
As you said David, it's a design pattern. We don't *need* to standardize it
to use it. Containers that want to do stuff like that can, it's not
required for decoupling frameworks from containers.
If it's really needed it could
>
> https://github.com/php-fig/fig-standards/pull/844
>
> As far as use case, beyond the semantic distinction "missing" implies the
> caller is doing something wrong. "Broken" means the configuration is
> wrong. (Even if the configuration in this case is a hard-coded class, it's
> still
Hi Chuck, good point I've opened a PR to fix
that: https://github.com/php-fig/fig-standards/pull/832
For those not aware I just wanted to point out that topics in this thread
are being discussed in separate threads on the mailing list. That helps to
keep up with each discussion. If a topic was
gt; May you give me a hint where Joel mentioned this? – I can't find it.
>
> Michael
>
> Am Donnerstag, 3. November 2016 08:47:15 UTC+1 schrieb Matthieu
> Napoli:
>> Definitely agree with making PSR-15 about server side middlewares
>> only. Joel mentioned several reason
Hi Niklas, I think there is a misunderstanding.
- if you use the interface, then you use the parameters defined in that
interface => so yes, you should NOT pass extra parameters (we agree on
that, that doesn't make sense)
- if you don't use the interface but the implementation directly, then
Splitting off the main review thread, quoting Larry:
> 1) What other exceptions might get($id) throw besides NotFoundException?
\Exception (because any exception could be thrown when creating services)
=> are you suggesting we should document it in the standard?
> 2) I would much prefer to
Hi Rasmus,
I was going to mention Puli too. Not because of all its features, but
because it contains a very simple solution to a wider problem: locating
resources.
Puli encourages to have a `res/` directory containing all resource files
(just like `src/` contains all source files). Resources
Hi!
This is a lot of text, I'm still not sure I understand the problem we are
trying to solve in this thread?
> The `ParentAwareContainerInterface` is a formal way of saying "this
container can have a parent". Nothing more, nothing less.
Then we are back to discuss "marker-interface" VS
> Given that most of PSR-11 was developed "off in a corner" from a FIG POV,
> I'd strongly suggest that anything people ask about here be taken as a need
> for clarification in the metadoc (if something isn't there already). "This
> GitHub link in this other group you wouldn't know to look
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
>
> 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.
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
Hi Woody,
This is not about personal preferences, this is about solving a pain point for
everyone. That example is pretty much explicit:
public function __invoke(ServerRequestInterface $request, ResponseInterface
$response, callable $next) : ResponseInterface
{
}
Activé 18 août 2016 à
`, that sounds like
an improvement to me (I have nothing better to suggest), what do others
think?
Le mercredi 17 août 2016 16:05:57 UTC+2, Matthew Weier O'Phinney a écrit :
>
> On Sun, Aug 14, 2016 at 12:47 PM, Larry Garfield <la...@garfieldtech.com
> > wrote:
> > On 08/14/20
<pmjone...@gmail.com> wrote:
>>
>> > On Aug 15, 2016, at 14:10, Matthieu Napoli <matth...@mnapoli.fr>
>> > wrote:
>> >
>> > Hi,
>> >
>> > PSR-11, aka ContainerInterface, has been sleeping for too long.
>> > Let's ge
Hi all,
This is a 2 weeks discussion before going to a vote.
The "Interface" suffix has been questioned a few times already, I'm
suggesting we put that up to a vote and avoid future debates. Here are
relevant threads I could find on the topic:
-
Hi,
PSR-11, aka ContainerInterface, has been sleeping for too long. Let's get
that PSR moving!
Here is a change I would like to suggest: *remove the interface
ContainerException*.
After years of using container-interop and ContainerInterface I have not
seen a use case for that exception. We
Thanks Woody for your answer. Such information should be in the META
document, else we are bound to discuss all this over and over.
Back to the topic: I don't see how the interface helps. If I'm writing a
server middleware stack, I'll type-hint against ServerMiddlewareInterface
(and vice-versa
Sorry for bringing that topic up again but I'll make it clearer:
*I think the StackInterface should be removed.*
- I don't see what it has to do with PSR-15 (interoperability for *invoking*
middlewares)?
- even if it was a separate PSR, I don't see the problem it is solving (and
the META
The term "Frame" is extremely confusing, I think it's a big issue with the
current version. I'm sure if you showed the current signature to PHP
developers a majority of them would not understand what that parameter is.
On the other hand `$response = $next($request)` is so simple and widespread…
>
> Michael,
>
> Please self-throttle a bit. It seems you are over-communicating/defending
> rather than allowing members to flesh this out.
>
It says right there in his previous email that he realizes he sent 2 emails
in this thread today and that he will self-throttle. Additionally the
Thanks. However I'm still looking for a good reason why we have this
interface: why not simply `callable $next` ?
- FrameInterface doesn't represent any actual usage or existing middlewares
today
- FrameInterface is more complex than `callable`
Matthieu
Le mardi 12 juillet 2016 16:39:53
Hi everyone,
I had a look at the spec and at the metadocument, but couldn't find an
answer to my questions about PSR-15 (HTTP middlewares for those mixing up
the numbers like me):
- why are middleware stacks not middlewares too?
- as corollary, why StackInterface exists at all?
interface
34 matches
Mail list logo
