On Tue, Jun 20, 2023 at 6:29 AM David Gebler wrote:
>
> On Tue, 20 Jun 2023, 04:10 Levi Morrison, wrote:
>
> > > I like the idea of this RFC - in fact it's one which has been near top of
> > > my wishlist for PHP language features for a long time - but I think this
> > is
> > > an issue with the
On Wed, Jun 21, 2023 at 12:54 AM Máté Kocsis wrote:
> * In order to finally achieve the strategic goal, we deprecate the old
> function along with session_set_handler_callbacks()
> as soon as the right time comes. That may be PHP 9.x or 10.y or 11.z,
> whatever.
For those who use callbacks now,
HI Nicolas and Rowan,
Mate, WDYT of 2)?
Your sentence about better typing rang a bell with me: I think that's the
best argument
for removing the signature accepting callables. But before coming to a
conclusion,
let me answer Rowan's question first:
This is where I don't understand what you or M
On Tue, Jun 20, 2023 at 12:10 AM Levi Morrison wrote:
> > I like the idea of this RFC - in fact it's one which has been near top of
> > my wishlist for PHP language features for a long time - but I think this
> is
> > an issue with the proposed implementation which at the very least
> warrants
>
Good morning, all!
This is a friendly reminder from your RMs that the PHP 8.3 feature
freeze is in ~4 weeks on July 18th [1]. Alpha1 is already out and Alpha2
is scheduled this Thursday.
All new features and RFCs need to be discussed with voting polls closed
on or before July 18th for inclus
On Tue, 20 Jun 2023 at 13:29, David Gebler wrote:
> Yeah I suppose I'm just saying "Interface default methods" can be
> interpreted a few different ways and there's key differences between
> Java-style, versus syntax sugar for mixing an interface and a trait in to
> one unit, versus a user can ef
On Tue, 20 Jun 2023, 04:10 Levi Morrison, wrote:
> > I like the idea of this RFC - in fact it's one which has been near top of
> > my wishlist for PHP language features for a long time - but I think this
> is
> > an issue with the proposed implementation which at the very least
> warrants
> > hig
On Tue, 20 Jun 2023 at 10:25, Ilija Tovilo wrote:
> Introduce a new function (currently named populate_post_data()) to
> read the input stream and populate the $_POST and $_FILES
> superglobals.
>
My initial instinct was to discuss how this could be made more flexible in
terms of input and outp
On Tue, 20 Jun 2023 at 09:22, Nicolas Grekas
wrote:
> > So are you saying we should deprecate the function-based version
> > completely, and not provide any new names at all? I think I would prefer
> > that to the confusing set of aliases the current RFC text proposes.
> >
>
> I was not but I wou
how are errors handled, like if the format of php://input is
unrecognized, not valid multipart/form-data and not valid
application/x-www-form-urlencoded?
errors? exceptions? nothing?
On Tue, 20 Jun 2023 at 11:26, Ilija Tovilo wrote:
>
> Hi internals
>
> A while ago I encountered a limitation of h
Hi internals
A while ago I encountered a limitation of how RFC1867 requests are
handled in PHP. PHP populates the $_POST and $_FILES superglobals when
the Content-Type is multipart/form-data or
application/x-www-form-urlencoded, but only when the method is POST.
For application/x-www-form-urlencod
Hi Juliette,
There are plenty of situations where it is of absolutely no interest to
> get a crypographically secure value, like for generating some
> semi-random test data and I strongly believe the impact of these
> deprecations to be large and fixing it won't always be trivial for
> codebases w
> Then, among both options, we need to select the one with the best future
> > proofness, and that's definitely the OOP one to me, because it comes with
> > more guarantees (type checks).
>
>
> So are you saying we should deprecate the function-based version
> completely, and not provide any new na
On 20/06/2023 07:26, Nicolas Grekas wrote:
Then, among both options, we need to select the one with the best future
proofness, and that's definitely the OOP one to me, because it comes with
more guarantees (type checks).
So are you saying we should deprecate the function-based version
complet
Hi Juliette,
Respectfully though, in my opinion selectively leaving out impact analysis
> without mentioning why they are missing in the RFC, reeks of trying to hide
> information which could influence the vote.
> Maybe just mentioning why the impact analysis is missing in these cases in
> the RFC
On 19/06/2023 22:12, David Gebler wrote:
Sure, but in this example were B::bar() to be a private method,
you would get a scope violation error. You would not if you were to
use a trait, since any methods implemented in the trait would be
executed in the same scope as the class using the trait
16 matches
Mail list logo
