that spawned the question.
Comments/feedback/etc. welcome. As it's a non-trivial change (although
not API changing) it would probably need a vote, but likely an
uncontroversial one.
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Fram
difficulties is that in PHP 5, a failed type check will
trigger an E_RECOVERABLE_ERROR, but on PHP 7 it will now throw a
TypeError. So if the goal is to mimic a type check, it will be wrong in
one version or the other. An assertion, though, can behave the same in
both versions.
--Larry Garfield
--
I hardly think "nonsense [sic]" is an appropriate way to describe
implementations that are following the spec as currently written.
--Larry Garfield
On 07/26/2016 06:06 PM, Daniel Plainview wrote:
Is it bad if you break BC with non-sense implementations?
On Wednesday, July 27, 20
consider them without a BC break.
--Larry Garfield
On 07/26/2016 04:30 PM, Daniel Plainview wrote:
> Throwing `\InvalidArgumentException` is
> another widely used alternative, however, that would be a change in the
> specification (as Calling Libraries would then need to know to catch
in the
first place.
--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
On 07/14/2016 09:27 AM, Ciaran McNulty wrote:
On Tuesday, 12 July 2016 21:19:00 UTC+1, Larry Garfield wrote:
Eh. You can copy any object, though, with an external clone()
call. So
really, all objects are "copyable", aren't they?
--Larry Garfield
You can certain
On 07/27/2016 12:45 PM, Daniel Hunsaker wrote:
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
<http://www.php-fig.org/
Hm. I would be open to this. We can include the sample code to
copy-paste in the errata, and include it in the utlis package.
Does anyone object to this recommendation for the errata? Paul and
Robert especially?
--Larry Garfield
On 07/28/2016 11:19 AM, Brent Shaffer wrote:
If we want
+1
--Larry Garfield, Drupal
On 07/28/2016 06:56 PM, 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 available here:
https
-centric spec. Historically,
that's almost always been our approach, and should remain so.
And now we've repeated in this thread the same conversation we've had
about PSR-12 every time it's come up, to the same result.
--Larry Garfield
--
You received this message because you are subs
lement. Yes its "personal preference", but so is the entire spec.
That's the point. :-)
* The extra space is good, as it makes the entire header section much
more consistent. That's easier to remember and easier to document/specify.
--Larry Garfield
--
You received this message
think it
does?) I'd probably agree with Michael and remove it. Whenever PSR-5
gets reactivated that change should be made there instead.
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To
oject reps have, and that's OK.
That's what the CC is signing up for, and they know it.
--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 fro
fact that there are 9 groups trying to build additional
collaborative standards within FIG should be a sign that people do see
value in FIG, and we're nowhere close to "done". If anything, it's a
sign of a potentially bright future for FIG and PHP, if we approach it
properly
implementation
tools and traits. This serves as a trial implementation, and already
influenced some small changes to the spec as a result. It also includes
a complete (more or less) test suite:
https://github.com/php-fig/link-util
Let the Reviewing (and hopefully quick passage) commence!
--Larry
I hereby nominate Amanda Folson for FIG Secretary. She has expressed
interest to me and others in helping FIG move forward in a constructive
fashion, and I believe she would do well in that task.
--Larry Garfield, Drupal
--
You received this message because you are subscribed to the Google
the Reddit thread stands, though; it was quite
disappointing to see someone try to derail the issue in that way
(apparently with at least some success).
--Larry Garfield
On 07/13/2016 02:24 PM, Tom Etzel wrote:
I've read through every post on this thread. Paul's politics have been
mentioned
that many are tired of. (The links are to the mail
archive, so you can view the context as well, including some replies at
the time in some cases.)
--Larry Garfield
On 07/13/2016 04:41 PM, Jason Coward wrote:
Where are the instances of behavior and/or communication issues within
PHP-FIG
oved?
Or are you content to ignore and dismiss the dozen+ people who have said
they have a problem with your behavior but don't want you removed over it?
The holier-than-thou, "your concerns are beneath me" attitude you're
taking here is exactly what people have a problem with.
--Larry G
On 06/20/2016 03:28 PM, Larry Garfield wrote:
On 06/16/2016 03:38 PM, Matthew Weier O'Phinney wrote:
On Wed, Jun 15, 2016 at 3:31 PM, Larry Garfield
<la...@garfieldtech.com> wrote:
A corresponding PR has been filed here:
https://github.com/php-fig/fig-standards/pull/775
Inc
Robert, any feedback? It sounds like everyone else is on board so I
want to get this Errata to a vote ASAP, then update the util library.
--Larry Garfield
On 08/01/2016 12:08 PM, Robert Hafner wrote:
I haven't had a chance to review this but will make sure to do so this week.
Rob
On Aug 1
For Drupal:
Samantha Quiñones
Amanda Folson
Jonathan Reinink
Matthew 'Matt' Trask
--Larry Garfield
On 08/12/2016 05:23 PM, 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
arate "bottom middleware" interface that I can see.
--Larry Garfield
On 01/24/2017 01:14 PM, Rasmus Schultz wrote:
> While I can certainly see the value in the architecture this would
imply, it's by no means the only architecture
I disagree that this implies architecture.
&quo
then be:
foreach ($requestHandlers as $h) {
$req = $h->process($req);
}
$res = $coreHandler->process($req);
foreach ($responseHandlers as $h) {
$res = $h->process($res);
}
Is that more what you're talking about?
--Larry Garfield
On 02/21/2017 12:21 PM, John Porter wrote:
Sadl
-1
--Larry Garfield, Drupal
On 01/31/2017 09:35 AM, Matthew Weier O'Phinney wrote:
After a couple months of review, and no additional tweaks during the
last couple weeks, we are ready to initiate an acceptance vote for
PSR-11.
Please find the specification here:
-
https://github.com/php-fig
rovide.)
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.
--Larry Garfield
--
You rec
Note: If you're using a single + to indicate a second choice, then I'd
have a single + on PR 1.
--Larry Garfield
On 01/16/2017 12:01 PM, David Négrier wrote:
First of all, thanks a lot for being so quick to comment this issue.
Let's summarize the expressed opinions.
(I'll try to put a note
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 &qu
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 grou
ize (modulo unexpected
vacancies).
--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...@googleg
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.
--Larry Garfield
On 09/04/2016 10:55 AM, Michael Cullum wrote:
Hi all,
Sorry we're announcing this late. It appears the secretaries google
calendar
On 09/01/2016 02:34 PM, Woody Gilk wrote:
On Thu, Sep 1, 2016 at 2:14 PM, Larry Garfield <la...@garfieldtech.com
<mailto:la...@garfieldtech.com>> wrote:
It being under the FIG name in no way prevents or discourages
anyone from "trying it out" if they wish,
eally do not
know how to interpret your desire to "split the baby" by disbanding FIG
in practice if not in name. "You must work elsewhere first" (aka,
independent interop groups) as a policy is effectively the same thing as
just disbanding FIG outright.
Do you have any tech
e four, three are already *-interop
projects, and I think would thrive even in the absence of the FIG.
Is there a reason you excluded PSR-13, which recently entered Review stage?
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Intero
, would be my preference but I know others disagree.)
Further refining the WG workflow seems like something we should
follow-up on later, once the dust has settled a bit.
Kudos to Larry and Michael for all the hard work you both did in
getting this to the table.
Thanks!
--Larry Garfield
--
Yo
+1
--Larry Garfield, Drupal
(I should probably vote on my on vote, shouldn't I...)
On 08/19/2016 01:43 PM, 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
-1
--Larry Garfield, Drupal
On 09/04/2016 11:26 AM, 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 PHP FIG must
with just the CC voting it likely would have failed to
pass.
Yeah, I don't expect the vote ratio to have been different were the CC
in place; it's the lack of quorum that, hopefully, the CC will help to
address.
--Larry Garfield
--
You received this message because you are subscribed to t
thread, is pure noise
serving no purpose whatsoever other than to troll the rest of the list,
create strife, and goad Paul's opponents into saying something he can
pounce on. Again.
If you want to know why people are getting fed up with FIG of late, this
thread is exhibit A.
--Larry Garfi
On 09/13/2016 09:28 AM, Josh Di Fabio wrote:
On Tue, Sep 13, 2016 at 2:50 PM Larry Garfield <la...@garfieldtech.com
<mailto:la...@garfieldtech.com>> wrote:
The standard example we've been using is a domain object of some
sort that then is getting rendered to an HTTP Respo
ollection was the best we came up
with. So I think it's Collection or Catalog at the end of the day.
--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 rece
-specific concretions.
--Larry Garfield
On 09/13/2016 08:18 AM, Josh Di Fabio wrote:
Quoting the meta doc.
> Why is a LinkCollectionInterface needed?
> In many contexts, a set of links will be attached to some other object. Those objects may be
used in situations where all that is relevant
uld help you in making your template engines
more portable to other frameworks/applications in a secure fashion, if
anything?
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe fr
"settling in time". I've no doubt that we'll want to make some point
releases once we've started working in the new model, but let's get it
deployed before we start filing patches.
--Larry Garfield
On 10/03/2016 06:42 PM, GeeH wrote:
To be clear, I am not saying that secretaries sho
+1
--Larry Garfield, Drupal
On 09/16/2016 06:14 PM, Larry Garfield wrote:
I hereby open a vote for the following bylaw changes, colloquially
known as "FIG 3.0". I'm fairly certain anything that needs to be said
has been said by now by all parties.
https://github.com/php-fig/fig
ember 2016.
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
y
OOP array of links.) That's really the problem; the name "collection"
would have likely been fine 3 years ago, but these days we expect more
of that word but have no word to replace its previous, more limited
meaning. :-/
--Larry Garfield
--
You received this message bec
specified, *it is a felony
for you to use it without the prior written consent of the author*. I
never said copyright law was good, but it is what it is. Please license
your code.)
--Larry Garfield
On 08/23/2016 08:24 AM, Keith Casey wrote:
Why does FIG need to own it in this regard?
On Monday,
same
arguments.
This discussion has been going on since the mid-90s when Java was
released, at least. (Maybe longer, but that's when I first encountered
it.) It's a tabs-vs-spaces class of issue.
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups
Can you note anything in particular that is clumsy to read? We were
aiming for explicitness and lack of vagueness, which in prose does tend
to lead to verbosity. To me it still reads fairly well, but as the
author I am of course biased on that front. :-)
--Larry Garfield
On 08/24/2016 05
... :-)
--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 g
Drupal will remain a PHP-FIG member project under the new bylaw structure.
--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, sen
th a non-interoperable
interoperability standard.
2016-11-07 21:34 GMT-02:00 Matthew Weier O'Phinney
<mweierophin...@gmail.com <mailto:mweierophin...@gmail.com>>:
On Fri, Nov 4, 2016 at 7:55 PM, Larry Garfield
<la...@garfieldtech.com <mailto:la...@
Since no one else seems to be doing so, I'll go ahead and do it. :-)
I hereby nominate Matthew "MWOP" O'Phinney for the Core Committee. His
reputation, skill, and existing and ongoing contributions to FIG should
speak for themselves and require no further explanation.
--Larr
Adam, I'm curious. What other conflict of interest issues are you
referring to? You make it sound like we're drowning in conflict of
interest problems, but I don't see that at all.
--Larry Garfield
On 11/06/2016 11:42 AM, Adam Culp wrote:
Thus the spiral of more and more conflict
-catch if I wanted to log it. That's what I am
not comfortable with.
I am generally very skeptical about SHOULD, and favor MUST in nearly all
cases by default. SHOULD should be read as "you're allowed to be
incompatible here", which is a statement a spec should make as rarely as
pos
cope to me as a
consumer.
The only compelling argument I've seen so far is the BC issue for
existing container implementations, which is a valid consideration.
To that end, I'd prefer to get input from Fabien and Taylor, as David
suggests, before weighing in on the listed options.
--Larry Garfield
On
, or not.
Let's leave it alone for now and revisit the question in the spring sometime, once we see how the CC/Secretary split plays out. We'll be able to make a more informed decision then.
--Larry Garfield
On Oct 22, 2016 1:49 PM, Michael Cullum <m...@michaelcullum.com> wrote:Gary,A vote is un
ASCII, that's not enough."
I admit to being quite confused as to how this is a controversial
suggestion, and why people keep misinterpreting it as suggesting to
heavily restrict legal key values.
--Larry Garfield
On 11/11/2016 05:02 AM, Gary Hockin wrote:
This, as in the share
nterInterface off to its own
(small) PSR. I have no problem with small PSRs if they cover their
target case adequately. Someone could certainly then implement both
CounterInterface and SimpleCache\CacheInterface (or CounterInterface and
CacheItemPoolInterface if they were so inclined) and lose noth
nds like a good addition, I'd be curious to hear
other people on this.
Cheers
We discussed this at phpworld. Michael, do you have the notes of that
conversation and what the outcome was? My general recollection was a
consensus around "be consistent with PSR-6 to avoid ugly and confusing
bugs
then your cache server hiccuping would crash your whole application,
which is doubleplusungood.
I believe the same logic applies equally well to PSR-16.
--Larry Garfield
On 11/16/2016 11:19 AM, Jordi Boggiano wrote:
This was also carried over from PSR-6 where Pool::save() returns bool.
I am
I filed a PR here with my recommendation:
https://github.com/php-fig/fig-standards/pull/837
Thanks.
--Larry Garfield
On 11/11/2016 12:43 PM, Matthieu Napoli wrote:
Hi Larry, you are right, let's move forward: what sentence do you
suggest we should add to the spec?
Matthieu
Le 11 novembre
On 11/13/2016 03:16 AM, Matthieu Napoli wrote:
I filed a PR here with my recommendation:
https://github.com/php-fig/fig-standards/pull/837
Thanks.
--Larry Garfield
Thanks, I feel it's easier to discuss that now:
> An entry identifier is a string of at least one character that
uniqu
on in this case is a hard-coded
class, it's still configuration so it's in-scope for PSR-11, not
PSR-11-followup.) Those would imply different people are doing
something wrong, so it's a different person's responsibility to fix.
--Larry Garfield
On 11/11/2016 01:42 PM, Daniel Plainview wr
Per the open meeting at php[world] I have updated the PR again to remove
mention of the character encoding.
--Larry Garfield
On 11/18/2016 04:56 PM, Daniel Plainview wrote:
> In the eyes of interoperability and standard, unless there's a
strong and compelling reason to add "UTF-8"
PSR-6's requirement was simply "at leas a 64 character UTF-8 string, and
these chars are reserved". If you don't want to reserve the same/any
characters that's fine, but at least a character encoding and minimum
legal length should be specified.
--Larry Garfield
On 11/03/2016 03:47 AM,
the caller don't care which type of exception is thrown, well,
that's where interfaces that cover both exceptions are helpful. :-)
--Larry Garfield
On 11/03/2016 03:53 AM, David Négrier wrote:
@Larry: the DependencyNotFoundException was discussed quite recently.
Here is the releva
.
--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 em
ominate Sara Golemon for the Core Committee.
--Larry Garfield, Drupal Representative
--
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
For the record, I modified the PHPStorm/IDEA template to include a blank
line between
--Larry Garfield
On 12/08/2016 09:21 AM, Michael Cullum wrote:
This would be really useful data if you're willing/able to provide it.
It would provide a useful aid to the survey results will be coming out
This sounds reasonable to me. Thanks, Secretaries.
--Larry Garfield
On 12/06/2016 09:24 AM, Michael Cullum wrote:
Hi all,
It was noted by a few individuals that the way the bylaws stand about
fulfilling the initial 12 Core Committee roles as if there is a
12-member vacancy this leads
On 12/09/2016 08:20 AM, Michael Cullum wrote:
Apologies for the delay in getting these out. The notes I have are below.
Welcome from the Secretaries
Present: Gary Hockin (For the PSR-11 excerpt), Larry Garfield, Chris
Tankersley, Brian Retter, David Stockton, William Hurley, Anthony
Ferrara
--Larry Garfield
On 01/12/2017 04:41 PM, 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 continue as Editor. That means
we need
est of the group for some reason. I'm
sure there's nothing to be read into that. :-)
--Larry Garfield
On 12/31/2016 02:57 PM, 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
a
agree that MissingDependency is more
specific and thus a better approach.) If neither of those are
acceptable to you, please offer your own alternative that resolves the
incomplete error handling.
--Larry Garfield
--
You received this message because you are subscribed to the Google Group
as the nominal maintainer of the cache-util package) would
be very welcome.
--Larry Garfield
On 12/05/2016 01:12 PM, Устименко Александр wrote:
Larry, this approach is overcomplicated.
NullObject of any interface can be implemented in single simple way.
My PRs in OverComplexCache are still open and I
We've decided since PSR-3 that such "stock implementations" do not
belong in the spec, but can live in -util libraries. A NullCache
implementation of PSR-6 / PSR-16 would be very welcome for cache-util.
On 12/05/2016 11:47 AM, Alexander Ustimenko wrote:
Another issue that we have now in
file docblock or the
declares should come first. But I do favor the status quo of "one line
between each set of things" as it's less complex to define, read, and
parse than the alternatives.
--Larry Garfield
--
You received this message because you are subscribed to the Google Group
uot; Logging is an
extremely good fit for that. Caching is a reasonable fit for that.
HTTP messages are a decent fit for that. Routing? I don't see that as
fitting that model.
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framewor
to automatically
generate URLs to appropriate controllers etc.
PSR-7 already defines an evolvable Uri object:
http://www.php-fig.org/psr/psr-7/#3-5-psr-http-message-uriinterface
That seems sufficient for most use cases.
--Larry Garfield
--
You received this message because you are subscribed to the Google
. It needs another review period, just like every other recent spec.
(There's still enough time to do so before FIG 3 takes over, don't worry.)
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To u
OK then, here goes.
Hi, I'm Larry Garfield. You may know me from such projects as "GoPHP5"
and "Drupal 8: Wait, what?"
== About Larry ==
I first started writing PHP in 1999, back when PHP 3 was still the new
hotness. (I feel old now.) I freelanced on and off throu
My votes, including some very hard decisions:
Larry Garfield
Matthew Weier O’Phinney
Sara Golemon
Lukas Kahwe Smith
Beau Simensen
Jeremy Coates
Marc Alexander
Samantha Quiñones
Cees-Jan Kiewiet
Korvin Szanto
Michael Heap
Tobias Nyholm
Chris Tankersley
Jason Coward
David Négrier
Graham Daniels
Normally there would be an expectation of a 2 week discussion before
calling the Entrance Vote, but under the circumstances I am fine with
skipping it in this case and just opening a vote to confirm the PSR-15 WG.
Anyone feel a need to wait, or shall we just have Matthew open a CC vote?
On
tp-message/dependents
But again, that on its own tells you very little and comes with a few
dozen asterisks.
--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 r
As a member of the Core Committee I have no problem at all with MWOP as
the Sponsor for continuing PSR-15 work. He's the natural candidate, and
has a long track record of being a calm, level-headed, considered
collaborator.
--Larry Garfield
On 03/21/2017 08:55 AM, Woody Gilk wrote
+1
--Larry Garfield
On 08/03/2017 10:03 AM, Sara Golemon wrote:
> Per http://www.php-fig.org/bylaws/psr-workflow/ This is the entrance
> vote for the HTTP Client PSR Discussion
> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>
>
The key for me is if the various HTTP clients have buy-in to implement
the spec once completed. Is that the case?
I would also ask why this is just for sync HTTP clients, not async.
There's plenty of use cases for the latter. That may be scope creep,
but I feel it's worth asking.
--Larry
tps://github.com/async-interop that sadly has been put on hold.
A fair reason, thanks. It may be worth mentioning in the metadoc,
including what a future Async version MIGHT look like if/when a Promises
PS happens. (You don't need to implement it, just show that it could
still be implemented.)
exceptions on all 4xx/xx right now, but could be convinced
otherwise), but "exceptions sometimes" doesn't seem like a good choice.
That said, that's a detail that doesn't block officially forming the WG;
I'm +1 on approving this as a WG to hash out exactly those sorts of details.
--Larry Garfield
It needs to be at least 5 people (including Sponsor and Editor) to start
with. It can grow and change and such after that as long as it doesn't
drop below 5, but it needs 5 people to kick-off.
--Larry Garfield
On 06/29/2017 04:53 AM, 'Alexander Makarov' via PHP Framework
Interoperability Group
r whatever) removes all ambiguity entirely,
except for having to look up which PSR 15 was. :-)
Also, just to make clear, the PHP runtime doesn't give a crap about the
namespaces we choose. This is entirely a human-consumption question.
(Which totally is important, sure, I'm just making it clear in ca
, but since a lookup for it will always return
a cache miss it doesn't much matter.
> 3) Should getItem() stores instances inside a private property, or
> should it MIUST get it from the cache storage directly ? This is not
> mentioned either.
I'm not sure I follow here. Can you cl
/admin in the
corresponding middlewares? (Other proposals, feel free to offer what
the above scenario would look like in your case for comparison.)
--Larry Garfield
On 05/15/2017 09:00 AM, Michael Mayer wrote:
On Monday, May 15, 2017 at 12:24:47 PM UTC+2, Rasmus Schultz wrote:
Th
+1
--Larry Garfield
On 05/09/2017 01:20 PM, Matthew Weier O'Phinney wrote:
As the two week discussion period regarding the PSR-15 working group
is now over, I am calling an entrance vote for the PSR-15 working
group, with the current membership:
- Editor: Woody Gilk
- Sponsor: myself
:thumbs up emoji:
--Larry Garfield
On 05/09/2017 03:33 PM, Matthew Weier O'Phinney wrote:
Okay, jumped the gun on the send button!
Two more things:
- We also include Tobias Nyholm under the WG members.
- Voting will commence no earlier than 11:59 on 23 May 2017.
On Tue, May 9, 2017 at 3:31
be used half the time anyway?
I'm afraid I'm still confused here about what is being proposed and what
it solves...
--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group an
fine with not
even doing that much.
--Larry Garfield
On 06/08/2017 04:42 AM, Stefano Torresi wrote:
I don't think this detail is worth standardising, ordering is very
situational and can bear a lot of different semantics.
We can surely leave this to common user conventions.
Il giorno gio 8 giu
You post a note to the list saying "we're forming a WG for PSR-12. The
members are . $Person is the Editor. 2 week discussion
period before the entrance vote, go!"
That's the long and short of it at this point, especially for a draft we
know is going to get re-upped.
--Larr
1 - 100 of 323 matches
Mail list logo
