On Tue, Jul 29, 2025, at 2:22 PM, Hans Krentel wrote:
> On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:
>> Is their use for quick hacky scripts worth the cost of reserving a symbol
>> that could be repurposed for something else more generally useful in the
&
if a variable is a
primitive or not, at the very least.)
--Larry Garfield
On Tue, Jul 22, 2025, at 3:02 PM, Larry Garfield wrote:
> Hi folks. Just a quick update: We've made one small change to the RFC.
> Specifically, in order to prevent accidentally calling optional
> arguments from callback locations like array_map() or array_find(), a
> par
standardized
function for that would be most welcome.
The name is quite long though. :-)
>> - is_representable_as_float()
The same argument applies here, although in most cases is_numeric() is close
enough. A more precise option would not be unwelcome, though.
--Larry Garfield
on, but I cannot.
>
> I was always sure that the reason behind all methods of \Exception
> being final is Larry-Garfield-blogpost length/depth so I never bothered
> to ask and made workarounds.
Hey, I resemble that remark! :-P
(I actually have no idea what the original reason was
On Sun, Jul 27, 2025, at 8:09 AM, Tim Düsterhus wrote:
> Hi
>
> On 7/24/25 15:42, Larry Garfield wrote:
>> Just to clarify here, Single Transferable Vote and Ranked Choice Voting are
>> the same thing. I think it's just another Ameircan-vs-British English
>> qu
; policies, I would
still find Abstain useful. Maybe not critical, but useful. And getting it in
place, and people used to it, could simplify future steps of using Abstain for
those or other things.
--Larry Garfield
will cause an issue. I
do support interfaces and opt-in inheritance, but I don't believe it actually
tags an interface with #[Attribute] anywhere.
--Larry Garfield
on. It's simple enough for a user to
plug those two operations together themselves when appropriate.
--Larry Garfield
rray_find($array, cb(val: ?, key: ?)); // array_find expects
> $value, $key.
Which is valid, but on balance I think it's OK for that case to still be a
manual short-closure in exchange for less confusing behavior of PFA. In
practice, I expect most PFA uses to be creating unary function anyway, followed
by thunks, so it won't greatly matter.
Does anyone else agree/disagree?
--Larry Garfield
On Thu, Jul 24, 2025, at 5:03 AM, Tim Düsterhus wrote:
> Hi
>
> I did not yet have the time to check the changes and your reply in
> detail, but I already wanted to follow-up on some of the points.
>
> Am 2025-07-23 15:55, schrieb Larry Garfield:
>> $c = fn(string
On Thu, Jul 24, 2025, at 4:54 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-07-23 15:57, schrieb Larry Garfield:
>> What other changes there are unaccounted for? I thought we'd kept up
>> on the behavioral ones.
>
> The support for attributes (particularly #[\Sensitiv
t, rather than after those.
* This one is largely uncontroversial, whereas a quorum or "use it or lose it"
policy almost certainly would be.
Those all strike me as good reasons this is fine to adopt stand-alone and get
it out of the way, just as, eg, pipes could be adopted without PFA, on the
expectation of PFA later.
--Larry Garfield
On Thu, Jul 24, 2025, at 4:13 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-07-23 16:05, schrieb Larry Garfield:
>> The only thing I'd add is that in the case of multi-option secondary
>> votes, STV/RCV also be explicitly allowed. (Rank first, second, third,
>> etc.
or STV is kinda clunky on the wiki right now, but we know
how to make it work.) Perhaps even encouraged if "do nothing" is not one of
the options.
An example of both up/down and either/or secondary votes would also be helpful.
--Larry Garfield
On Tue, Jul 22, 2025, at 3:18 PM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-07-22 22:02, schrieb Larry Garfield:
>> It seems the discussion has quieted down and wasn't particularly
>> contentious to begin with (whew), so we're just about ready for a vote.
>
>
On Wed, Jul 23, 2025, at 3:56 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-06-28 07:06, schrieb Larry Garfield:
>> https://wiki.php.net/rfc/partial_function_application_v2
>
> I've now given the RFC an in-depth read. I have the following remarks:
>
> 1.
>
>>
On Sat, Jun 28, 2025, at 12:06 AM, Larry Garfield wrote:
> Hi folks. Arnaud and I would like to present take-2 at Partial
> Function Application.
>
> https://wiki.php.net/rfc/partial_function_application_v2
>
> It is largely similar to the previous PFA proposal from 2021, tho
d be a variable that references a Closure, and often will be. So
it's already quite clear what will happen
If we were to agree that there was a use case for "reverse assignment" (of
which I am not yet convinced), it should be its own stand-alone thing. Just
for argument's s
ther one can pass or fail independently.
https://wiki.php.net/rfc/readonly_hooks
--
Larry Garfield
la...@garfieldtech.com
ort their own RFC is
nonsensical, given that multi-part votes or split votes or secondary votes come
up multiple times every release. Rather, it means the different parts are
related enough and small enough to be digestible in a single RFC, but each can
stand on their own if necessary. In this case, nothing about the get hook
necessitates a set hook, and nothing about the set hook necessitates the get
hook.
--Larry Garfield
gt; PHP 8.5.
At this point, I fully expect the 'get' part of the RFC to not pass. Someone
else is welcome to then work on an init hook. The seemingly less controversial
'set' hook still has considerable value on its own, and hopefully that passes.
--Larry Garfield
s anymore.
Even on set hooks, which do not violate any of the interpretations of what
readonly "means" floating about? As the RFC notes, that's now a necessary
validation step with the improved clone() on its way.
--Larry Garfield
On Sat, Jun 7, 2025, at 11:16 PM, Larry Garfield wrote:
> As Nick has graciously provided an implementation, we would like to
> open discussion on this very small RFC to allow `readonly` on backed
> properties even if they have a hook defined.
>
> https://wiki.php.net/rfc/readon
or "classes.php" file that Composer just front-loads on
every request that contains a bunch of one-liner class definitions (or
functions, or whatever) is perfectly fine, and works today.
The only thing that would need to change is for SA tools (mostly PHPStorm) to
be less whiny if they see a class that doesn't match its file name. But I am
quite confident JetBrains can figure out how to do that.
In short: This is not a real problem. There's no need for us to make it one.
--Larry Garfield
t; 200;
> }
>
>
> --
> Best regards,
> Dmitrii Derepko.
> @xepozz
I have some concerns that there may be edge cases we've not thought about, but
at the moment I am generally in favor. An RFC and implementation would likely
help ferret out those edge cases.
I agree that this combined with single expression functions would go a long way
to making lightweight data structures even easier to create and use.
--Larry Garfield
On Tue, Jun 3, 2025, at 12:11 PM, Dmitry Derepko wrote:
> I've changed the structure, followed the rfc template now.
>
> The voting section isn't available now, because the RFC is under discussion.
Hi Dmitrii. Are you going to continue this? If you want to bring it to a vote
for this release, i
On Sun, Jul 13, 2025, at 6:28 PM, Ilija Tovilo wrote:
> Hi Nick
>
> On Fri, Jul 11, 2025 at 6:31 AM Nick wrote:
>>
>>> On 8. Jun 2025, at 11:16, Larry Garfield wrote:
>>>
>>> https://wiki.php.net/rfc/readonly_hooks
>>>
>>> To not get
Is their use for quick hacky scripts worth the cost of reserving a symbol that
could be repurposed for something else more generally useful in the future?
(Not immediately of course, but eventually.)
--Larry Garfield
get-hook's first return value cached; it
would still be subsequently called, so any side effects would still happen
(though I don't know why you'd want side effects), but only the first returned
value would ever get returned. Would anyone find that acceptable? (In the
typical case, it would be the same as the current $this->foo ??= compute()
pattern, just with an extra cache entry.)
--Larry Garfield
nd.
>
> Cheers,
> Ben
>
> P.S. For legal questions or concerns, I’m working with Pamela Chestek
> of Chestek Legal <https://www.chesteklegal.com> on behalf of the PHP
> Group. You may be familiar with her work as chair of the license
> committee for the Open Source Initiative.
This is long overdue and very welcome. Thank you, Ben!
--Larry Garfield
en?
Repeat all of the above on readonly properties.
I don't know the answer to any of those. We could probably collectively figure
out some answers to that in time, but that's a much larger lift than either
Nick or I have any interest in engaging in at this point, especially when there
is a reasonable solution right in front of us that is trivial to implement.
--Larry Garfield
at the
edge of reasonable complexity more complex.
An init hook would be clearer, certainly, though it also has its own edge
cases. Can you set something that has an init hook? What happens if there's
both a get and init hook? These probably have answers that could be sorted
out, but t
On Tue, Jul 1, 2025, at 9:27 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-06-09 17:11, schrieb Larry Garfield:
>> I also fleshed out the __get mention with an example that shows what
>> you can already do today, and in fact could since 8.1 when readonly was
>> introdu
On Fri, Jul 4, 2025, at 5:27 PM, Rob Landers wrote:
> On Sat, Jun 28, 2025, at 07:06, Larry Garfield wrote:
>> Hi folks. Arnaud and I would like to present take-2 at Partial Function
>> Application.
>>
>> https://wiki.php.net/rfc/partial_function_application_v2
>
On Fri, Jul 4, 2025, at 6:50 PM, Andreas Hennings wrote:
> On Thu, 3 Jul 2025 at 23:44, Larry Garfield wrote:
>>
>> On Thu, Jul 3, 2025, at 12:49 PM, Andreas Hennings wrote:
>>
>> >> A setter method injection is what I did in AttributeUtils, because i
n is one such multi-step case, there are lots of others, so in advanced cases
(most of what I do) the object will always have an incomplete phase, and that's
unavoidable. So I'm not *that* worried about there being a brief
incomplete-gap in time in core, because I'll always have one anyway, and I've
already figured out how to handle it.
--Larry Garfield
e
>> > downside here is that Attribute are, generally, serializable, but a
>> > Reflection object is not. So if someone wanted a serializable attribute
>> > they would have to accept the property, use it, and then remember to unset
>> > it at some point. That'
ocessing either immediately or later in the constructor. The downside here
is that Attribute are, generally, serializable, but a Reflection object is not.
So if someone wanted a serializable attribute they would have to accept the
property, use it, and then remember to unset it at some point. That's clumsy.
--Larry Garfield
ts in their respective driver classes? (If so,
please state that explicitly.)
Everything else seems reasonable to me at the moment.
--Larry Garfield
at has to then be checked for and rejected by the new functions.
That feels like clunkiness that we should be able to avoid. So with that
signature, false would still use the existing "unsafe" mode; there's no enum
case for "old unsafe logic", just for the new-correct modes.
--Larry Garfield
it's been a while) in the
discussion thread of your previous RFC. And voted against the RFC on the
grounds that I didn't feel it was robust enough to effectively replace PSR-7
and HttpFoundation.
--Larry Garfield
> targeted for PHP 9? Or would it be more appropriate to defer the
> deprecation to the PHP 9 cycle, aiming for removal in PHP 10?
> Alternatively, should a second vote be held to determine the
> preferred deprecation timeline?
Since we don't know when PHP 9 will be yet (Grrr...), I'd lean toward a
secondary vote or punting it to the usual mass-deprecation RFC that often
happens. (Side note: This is why we need a regular schedule for major
releases.)
--Larry Garfield
to go along with it so
that people can mock it for testing purposes. I would consider this a hard
requirement for any "user facing" HTTP client.
--Larry Garfield
pt,
don't worry.)
(Eg, I would strongly recommend leveraging properties instead of methods for
any built-in objects, which didn't exist when PSR-7 was written but now so; we
should absolutely use the new built-in URI/URL classes instead of user-space
ones, etc.)
Of course, as you can expect, "design and include request/response objects
powerful enough to supplant PSR-7" is a non-small and highly bikesheddable
topic, and PHP is notoriously structurally bad at being able to have those
conversations. That's part of why it's never happened.
--Larry Garfield
owan/.
>
> Best regards
> Tim Düsterhus
... I think that may be the second time I've confused you two. I have no idea
why I keep confusing you and Rowan. Sorry again. :-/.
--Larry Garfield
es of why that's a bad idea; and even
then, I'd expect to be able to default to it.
For the long-names issue that Tim pointed out, perhaps drop "Variant" from the
enum names? As they're namespaced, `Base32::Ascii` seems fairly
self-explanatory.
I am overall in favor of this RFC, modulo notes above.
--Larry Garfield
On Sat, Jun 7, 2025, at 11:16 PM, Larry Garfield wrote:
> As Nick has graciously provided an implementation, we would like to
> open discussion on this very small RFC to allow `readonly` on backed
> properties even if they have a hook defined.
>
> https://wiki.php.net/rfc/readon
On Mon, Jun 30, 2025, at 2:28 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-06-28 07:06, schrieb Larry Garfield:
>> https://wiki.php.net/rfc/partial_function_application_v2
>
> Some thoughts, I did not yet take an in-depth look:
>
> - Will PFA be available in constant-expres
On Sun, Jun 29, 2025, at 7:29 PM, Ben Ramsey wrote:
> Under the section “func_get_args() and friends,” one of the examples shows:
>
> $f = foo(?, ?, ??);
>
> I assume this is a typo?
One too many ?. :-) Fixed thanks.
--Larry Garfield
it now because, well, it's ready now. If the discussion goes
smoothly, we're OK calling a vote on it for 8.5, especially as it would
complement pipes so well. If the discussion runs longer, we're also OK with
targeting 8.6 instead. We'll see how that goes.
--
no further.
3. We should bundle an HTTP client that wraps Curl (with or without minor
improvements to Curl), exact scope TBD.
Personally, I'm open to either 2 or 3. 3 is more bikesheddable, but possibly
the better end result.
Where does everyone else stand?
--Larry Garfield
t trivial is also
important. Whether that's via a mini-response object instead of a string or
something else is open for discussion, I think.
Other questions:
* We have these shiny new URL/URI objects. Should those be supported directly?
--Larry Garfield
uot; or "what enum do I need that is a string?" unless I already know
> the implementation details by heart. The Info and Pause enumerations
> seem more useful in that regard as they reduce the scope in which I
> need to understand, process and decide.
I will agree here. Splitting enums by type doesn't add much value. Splitting
them by topic might, if the topics are sufficiently distinct that a separate
method makes sense. I don't know Curl's API well enough to make specific
recommendations there.
--Larry Garfield
C
should include examples of), IMO, good ergonomics is more important than
looking like the old, horribly obtuse API.
As a worst case, perhaps the top-20 options or so could be converted to
methods/properties, and the rest left to be ugly flags?
--Larry Garfield
correct,
but empty string may be more ergonomic in practice. I defer to Nicolas who has
probably had to deal with it more than I ever will. :-)
[1] https://www.garfieldtech.com/blog/empty-return-values
--Larry Garfield
On Tue, Jun 24, 2025, at 3:18 AM, Adam Cable wrote:
> On Tue, Jun 24, 2025 at 12:20 AM Larry Garfield
> wrote:
>> On Sun, Jun 15, 2025, at 3:12 PM, Adam Cable wrote:
>> > Hello internals,
>> >
>> > I'd like to present my first RFC - str_icontains, a c
t to determine if they're still relevant?
(I don't recall the details; I think one of them was function count explosion,
but I think there were more.)
--Larry Garfield
as for the lengthy, kind and
> productive discussion we had off list, and for the feedback shared.
>
> Kind regards,
> Volker
Despite my no vote, I am happy to see this pass and look forward to using it.
Congrats!
--Larry Garfield
on:
> *1. General appetite for enhanced debugging functions in core
> 2. Concerns about naming conflicts with existing userland helpers
> 3. Preferred feature scope
>
> Thoughts?
>
> Best regards,
> Braunson Yager
What exactly would dump() offer that's different/better than var_dump() already
does today? Is it just a pretty-printed var_dump()? I don't really see a need
for that.
--Larry Garfield
mPHP, Revolt, etc.) will give you 80% of what you're looking for or better,
today. Talking about anything even more drastic is severely premature until
that model achieves critical mass, and ideally becomes the most widely used
SAPI. Until then, this sort of "change the world" redesign is not feasible.
--Larry Garfield
to be a way to yield
> "all the way", so to speak, similar to what an exception does, and how
> effect handlers work in OCaml [2].
>
> The question is, would this be easy, hard, or very hard to add to the
> current PHP source code? Is it conceptually too different from generators?
> Would it be easier to add a way to "jump back" from a catched exception
> (kinda abusing the exception use-case, but that's how effect handlers work,
> more or less)?
>
> Thanks for reading :)
>
> Olle
Algebraic effects is a... big and interesting topic. :-) If we were to go that
route, though, I would want to see something more formal than just a "yield
far." That's basically another kind of unchecked exception, whereas I want us
to move more toward checked exceptions.
--Larry Garfield
It is, thanks.
For the name, I don't like the idea of this being the first `num_` function.
This feels like a place we want to start a namespace for such system
information functions, where we can then name it in a contextually-informed way.
--Larry Garfield
On Tue, Jun 10, 2025, at 2:45 PM, Dmitry Derepko wrote:
> Thanks for participating, Larry.
>
> On Mon, Jun 9, 2025 at 10:29 PM Larry Garfield wrote:
>> 2. Please link to a PR of your actual implementation. In context it looks
>> like your branch comparison link is to the ve
looks like
your branch comparison link is to the version you said didn't work, so it's not
that helpful.
3. The biggest question that has come up in the past (Ilija and I have
discussed it at length) is, naturally, autoloading. How if at all do you
address that?
4. The other big question was determining when to match a given "method" call
to an extension function, when the type of a variable is not always known at
compile time. How did you address this?
--Larry Garfield
this RFC was originally spun off from the hook-improvements RFC, as it
needed more discussion while the other half of that RFC was uncontroversial.
I've added a link to the prior thread for reference.
--Larry Garfield
As Nick has graciously provided an implementation, we would like to open
discussion on this very small RFC to allow `readonly` on backed properties even
if they have a hook defined.
https://wiki.php.net/rfc/readonly_hooks
--
Larry Garfield
la...@garfieldtech.com
}
Interface properties cannot be declared readonly today:
https://3v4l.org/cXgR0
Which I think is correct behavior.
Make sure to include a test based on the "lazy product" example from the RFC
text. That's the main sort of use case I'd expect we'd want to enable. :-)
--Larry Garfield
you're mapping your query results into an object
(please always do this), then you probably want to cast that into to a bool,
and currently weak mode would let you do that implicitly.
I can't think of a case where a string or float magically casting to a bool is
reasonable.
--Larry Garfield
ere was still an active discussion with Nicolas going on that seemed
rather important. Opening the vote while that was still going on is, as noted
above, problematic.
--Larry Garfield
On Tue, Jun 3, 2025, at 4:33 AM, Christoph M. Becker wrote:
> On 03.06.2025 at 03:36, Anton Smirnov wrote:
>
>> On 02/06/2025 20:01, Larry Garfield wrote:
>>
>>> The result of this RFC is that the following would no longer be an
>>> error, yes?
>>>
&
ation.
Also, Ilija is rather busy on other tasks at the moment, as am I. (Unless
someone else wants to jump in to implement it, which would be fine.)
--Larry Garfield
he trend/track
record has been squeezing the weirdness out of type juggling until weak mode
and strict mode are close enough to touch, and the language is better for it.
--Larry Garfield
But the
whole point of the RFC is to provide a native operator for concatenating
functions. Decomposing/deconcatenating an already composed function chain
is... not a thing.
> By the way, RFC describes userland "compose" function performance
> problems, but there is no suggestion to make it natively, why so?
Uh. That's the entire point of the RFC? Make a native compose operator that
isn't even a function.
--Larry Garfield
On Mon, Jun 2, 2025, at 3:28 PM, Rowan Tommins [IMSoP] wrote:
> On 02/06/2025 17:57, Larry Garfield wrote:
>> Well, now you're talking about something with a totally separate compile
>> step, which is not what Michael seemed to be describing at all. But it
>> seems li
=> htmlentities($data)”)
>
> - it will be possible to re-use the compose function along with the new
> operator $data |> compose(…$functions)
Pipe and compose are importantly different operations. I've had user-space
implementations of both available for years in crell/fp:
https://github.com/Crell/fp/blob/master/src/composition.php
I'd love to have a compose operator natively in PHP, too. The RFC for that is
already written, just needs code. I hope to formally propose it soon:
https://wiki.php.net/rfc/function-composition
--Larry Garfield
n time.
I don't mean to dissuade you from looking into the topic; I just want you to be
aware of the prior art so that we don't end up with multiple conflicting
half-baked approaches instead of a single fully baked approach.
--Larry Garfield
a conflict. I don't know how viable that
is off hand.
--Larry Garfield
d
The result of this RFC is that the following would no longer be an error, yes?
function test(): void {
print "test";
}
// This currently gives an error, but you propose that it
// would change to set $val to null?
$val = test();
--Larry Garfield
On Mon, Jun 2, 2025, at 9:44 AM, Rowan Tommins [IMSoP] wrote:
> On 2 June 2025 14:27:45 BST, Larry Garfield wrote:
>>Were we to do that, then the consumer container-loading needs to take any
>>potential module-definition into account. Eg, if one class from a module is
>>pu
On Sun, Jun 1, 2025, at 5:01 PM, Rowan Tommins [IMSoP] wrote:
> On 01/06/2025 17:05, Larry Garfield wrote:
>> I think there's a key assumption here still that is at the root of much of
>> the disagreement in this thread.
>>
>> Given that code from multiple fi
ing space that is build along
the boundaries established by the module/package authors already. (Note: This
still relies on all of those packages being modularized by their authors, but
again, I think that is a requirement.)
--Larry Garfield
On Mon, May 12, 2025, at 8:57 PM, Larry Garfield wrote:
> I hereby open the vote on the Pipe operator RFC:
>
> https://wiki.php.net/rfc/pipe-operator-v3
>
> The vote will run until 26 May.
The vote is now closed. The final tally is 33 Yes to 7 No, or about 82%. The
RFC pas
am fully on board with the
intent and goal here. +1.
--Larry Garfield
sible to use the compile step
rather than strictly the lexer; moving pipes from strictly lexer to a compile
step was a very smart move, for instance, as it simplified a lot of the
ancillary behavior around debugging and error messages.)
--Larry Garfield
would be easy
enough (at least in concept) to extend whatever translation logic exists to the
rest of that package/module/cluster/thing. Without that, however, I don't know
how that transitive class usage would be addressed.
--Larry Garfield
er.
Please explain further what value this has for core, rather than the parallels
extension. (In the RFC, not just here on list.)
--Larry Garfield
On Thu, May 22, 2025, at 8:53 PM, Anton Smirnov wrote:
> Hi Dmitriy
>
> On 22/05/2025 12:24, Dmitry Derepko wrote:
> > I'm aware that Larry Garfield previously proposed a similar feature
> > several years ago, though it unfortunately didn't pass the vot
unforeseen challenges there. (Eg, I have no idea if bare array
keys would cause issues with constants.) Moreover, we have 15 years of
training and coding standards and automation tools that say to never use
array(), always []. Reversing that would be far more disruptive for the
ecosystem, even if it turns out to be not too disruptive to the code.
I strongly prefer the current syntax, and if the RFC changed to require an
array I would strongly consider voting No on those grounds alone.
--Larry Garfield
rejb for touching up phrasing, correcting spelling
> mistakes and so on: https://wiki.php.net/rfc/clone_with_v2?do=revisions
>
> Kind Regards,
> Volker
For positional parameters, I don't see any way that they'd work or do what
someone expects. So why not just block them entirely instead of relying on
dynamic properties to warn-but-sorta-work?
--Larry Garfield
a constructor as well.
>
> — Rob
The limit of hooks is that they're single-property. So depending on how your
derived properties are implemented, it may be insufficient. I could easily
write such an example (the hooks RFC included some), but how contrived they
are, I don't know.
--Larry Garfield
On Thu, May 15, 2025, at 8:53 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-05-15 00:04, schrieb Larry Garfield:
>> Subtle point here. If the __clone() method touches a readonly
>> property, does that make the property inaccessible to the new
>> clone-with?
>
> Ye
prefers. If that handles only complex cases (eg,
firstName was updated so the computed fullName needs to be updated) and set
hooks handle the single-property ones, that would probably cover all bases
reasonably well.
--Larry Garfield
On Wed, May 14, 2025, at 10:36 PM, Theodore Brown wrote:
> On Wed, May 14, 2025 at 09:08 Larry Garfield wrote:
>
>> On Tue, May 13, 2025, at 5:55 PM, Ilija Tovilo wrote:
>>> On Tue, May 13, 2025 at 3:58 AM Larry Garfield
>>> wrote:
>>>>
>>&g
On Wed, May 14, 2025, at 2:54 PM, Volker Dusch wrote:
> On Wed, May 14, 2025 at 5:40 PM Larry Garfield wrote:
>>> A magic __clone() method will be called before the new properties are
>>> assigned.
>> Why before and not after? I could probably make a good argument e
"unlock scope"? I would expect the latter. A single unlock block would be
confusing to me.
--Larry Garfield
atively, we could drop the variadic syntax and instead only accept an
> array as the second parameter. We're looking for feedback here in the
> discussion.
Oh lord please no. :-) Not using an array here is what I like about this
syntax. An __object parameter is fine with me as a workaround. One shouldn't
be using a named argument for that anyway.
--Larry Garfield
On Tue, May 13, 2025, at 5:55 PM, Ilija Tovilo wrote:
> Hi Larry
>
> On Tue, May 13, 2025 at 3:58 AM Larry Garfield wrote:
>>
>> I hereby open the vote on the Pipe operator RFC:
>>
>> https://wiki.php.net/rfc/pipe-operator-v3
>
> It looks like the exa
On Tue, May 13, 2025, at 1:41 PM, Levi Morrison wrote:
> On Mon, May 12, 2025 at 8:00 PM Larry Garfield wrote:
>>
>> I hereby open the vote on the Pipe operator RFC:
>>
>> https://wiki.php.net/rfc/pipe-operator-v3
>>
>> The vote will run until 26 May.
>
I hereby open the vote on the Pipe operator RFC:
https://wiki.php.net/rfc/pipe-operator-v3
The vote will run until 26 May.
--
Larry Garfield
la...@garfieldtech.com
1 - 100 of 1245 matches
Mail list logo
