On 01/16/2017 10:15 AM, Matthieu Napoli wrote:
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 years of writing code I cannot recall ever saying
"damn, this error message is too precise and specific". I have said
the opposite more times than I can count.
David works on his personal time to implement something that you want,
we both say that we are ready to accept that change if you think this
is mandatory for you to accept the spec, I don't see how you can call
that "resistance" but maybe that's just a wording issue and I
shouldn't take too much notice of that.
Also I just want to point out that of course there should be very
precise and explicit exceptions, we all agree on that. It's just that
we don't believe the interface (as such, the spec) makes sense because
you wouldn't need to catch it. Implementors *should* make very
explicit exceptions. Anyway, again this is just my opinion and I
understand you may not share it, I just want to make sure we are
talking about the same thing.
I very much appreciate that we're all working on (mostly) volunteer
time. The resistance to which I refer is the past several weeks, in
which the main refrain has been "we don't want to specify another
exception." It's the position of "yes it's a different error case but
we don't want to specify it" that I find befuddling. History has shown
that imprecise definition of the not-happy path can be a major failing
of a spec. I'm not aware of any instance of error handling being
harmfully over-specified. Thus I am inclined to favor more precision
over less when it comes to error handling.
As noted, PR 1 (being moot on the subject) would clear up my main issue
regarding the "any capital letter but X" problem, despite still leaving
most error handling undefined. That is suboptimal. (To the earlier
question about specifying a CircularDependencyException as well, that's
a complex enough case that I wouldn't insist on it but I wouldn't object
if someone were to add it.)
Similarly, to Matthew's point about it "imposing an implementation
detail", many of our specs do that in practice. PSR-3 has only one
meaningful way to implement all but one of its methods; we provided a
trait for it for that reason. PSR-7's use of immutability around what
amounts to getters/setters for primitives (about half the methods on it)
implies that there's very little flexibility in how much of it is
implemented. There's only one meaningful way to bridge PSR-16 to
PSR-6. Yet all of those were approved, because the awareness that there
would be some boilerplate in any valid implementation didn't preclude
there still being multiple valid and distinct implementations and there
being value in standardization of the interface.
Certainly that can be a fuzzy area (there were people saying PSR-7
implied only one possible implementation entirely), and rational people
can disagree on where that fuzzy line is. For me, implying that
everyone's get() implementation has a try-catch block in it warrants a
¯\_(ツ)_/¯.
PR 1 would resolve the awkward wording, although I do feel it is the
inferior approach as it is less precise and provides less contextual
information for callers. (That we don't at the moment know when a
caller would want that extra information is, IMO, irrelevant as it's
so easy to provide.)
PR 2 actively works to make using the spec harder, and I cannot get
behind that at all.
I am admittedly unlikely to vote +1 on the spec regardless, but
should it pass anyway I feel it should still be as good (or least
bad) as possible, and that is PR 3.
If I understand correctly you might vote -1 because:
> That is, with that [the dependency lookup feature] removed, what's
left tostandardize? get() and has() are barely an specification.
What do you think of the fact that some frameworks (Slim, Zend
Expressive, Silly…) or some libraries (Behat…) are able to integrate
with any container thanks to ContainerInterface? Do you disagree it
justifies the existence of PSR-11?
I've been highly skeptical of PSR-11 since before it had a number. :-)
Factories along the line of Symfony's ControllerResolver (also used by
Drupal) are the main use case and benefit I can see; in fact I could see
myself using that were it to pass in one side library I have. However,
there are other ways to handle many such cases (which MWOP has in fact
pointed out to me), and I am still concerned about the unintended side
effect of encouraging Service Locator usage (despite the spec's
recommendation to the contrary). Without a major enabling of some other
functionality (such as stitching together complex libraries without
bridge modules to wire up a dozen different containers, which the
delegation concept could have possibly helped with and I thought was its
intent), that risk seems too great to me.
As above, reasonable people can disagree on that point, and that's
fine. But that's where I currently stand.
--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/1a4ecc67-0187-b6bb-823d-24bced7859c8%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
