On Fri, Feb 7, 2025, at 5:47 PM, Christoph M. Becker wrote:
> On 07.02.2025 at 23:54, Rob Landers wrote:
>
>> Put another way, what is the order of operations for this new operator?
>>
>> For example, what is the output of
>>
>> $x ? $y |> strlen(…) : $z
>>
>> $x + $y |> sqrt(…) . EOL
>>
>> Etc.
On 07.02.2025 at 23:54, Rob Landers wrote:
> Put another way, what is the order of operations for this new operator?
>
> For example, what is the output of
>
> $x ? $y |> strlen(…) : $z
>
> $x + $y |> sqrt(…) . EOL
>
> Etc.
According to the reference implementation[1], that would be equivalent to
On Sat, Feb 8, 2025, at 00:19, Larry Garfield wrote:
> On Fri, Feb 7, 2025, at 4:54 PM, Rob Landers wrote:
>
> > Put another way, what is the order of operations for this new operator?
> >
> > For example, what is the output of
> >
> > $x ? $y |> strlen(…) : $z
> >
> > $x + $y |> sqrt(…) . EOL
>
On Fri, Feb 7, 2025, at 4:54 PM, Rob Landers wrote:
> Put another way, what is the order of operations for this new operator?
>
> For example, what is the output of
>
> $x ? $y |> strlen(…) : $z
>
> $x + $y |> sqrt(…) . EOL
>
> Etc.
>
> I noticed this seems to be missing from the RFC. As a new ope
On Fri, Feb 7, 2025, at 22:04, Larry Garfield wrote:
> Merging a few replies together here, since they overlap. Also reordering a
> few of Tim's comments...
>
> On Fri, Feb 7, 2025, at 7:32 AM, Tim Düsterhus wrote:
> > Hi
> >
> > Am 2025-02-07 05:57, schrieb Larry Garfield:
> >> It is now back
Merging a few replies together here, since they overlap. Also reordering a few
of Tim's comments...
On Fri, Feb 7, 2025, at 7:32 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-02-07 05:57, schrieb Larry Garfield:
>> It is now back with a better implementation (many thanks to Ilija for
>> his help an
On Fri, 7 Feb 2025, 21:27 Thomas Hruska, wrote:
> The repeated assignment to $temp in your second example is _not_
> actually equal to the earlier example as you claim. The second example
> with all of the $temp variables should, IMO, just be:
>
> $temp = "Hello World";
> $result = array_filter(
On Fri, Feb 7, 2025, at 10:51 AM, Christoph M. Becker wrote:
>> Of particular note, since the last RFC I have concluded that a compose
>> operator is a necessary complement to a pipe operator. However, it's also
>> going to be notably more work, and the two operators don't actually interact
>>
On 2/6/2025 9:57 PM, Larry Garfield wrote:
Hi folks. A few years ago I posted an RFC for a pipe operator, as seen in many other
languages. At the time it didn't pass, in no small part because the implementation was a
bit shaky and it was right before freeze. Nonetheless, there are now even m
On 07.02.2025 at 05:57, Larry Garfield wrote:
> Hi folks. A few years ago I posted an RFC for a pipe operator, as seen in
> many other languages. At the time it didn't pass, in no small part because
> the implementation was a bit shaky and it was right before freeze.
> Nonetheless, there are
Hi there
On Fri, Feb 7, 2025 at 4:07 PM Tim Düsterhus wrote:
>
> I believe Ilija has some proof-of-concept regarding file-private
> classes, which would sidestep the above problem of disambiguating static
> member access.
Indeed. I shared a draft internally and responses were mixed.
https://wik
On Fri, Feb 7, 2025, at 16:05, Tim Düsterhus wrote:
> Hi
>
> Am 2025-02-07 15:23, schrieb Rob Landers:
> > Instantiation is done by static access: new Outer::Inner(1), which is
> > currently a syntax error.
>
> How would I access static members on an inner class without having
> ambiguity? `Out
On 2025-02-07 06:57, Larry Garfield wrote:
Hi folks. A few years ago I posted an RFC for a pipe operator, as seen
in
many other languages. At the time it didn't pass, in no small part
because the implementation was a bit shaky and it was right before
freeze.
Nonetheless, there are now even mo
Hi
Am 2025-02-07 16:03, schrieb Marc Bennewitz:
Is that something feasible and how complicated would that be to
implement?
Supporting this might cause conflicts when full-blown tagged-unions are
proposed, because those would actually support properties and semantics
might need to be differen
Hi
Am 2025-02-07 15:23, schrieb Rob Landers:
Instantiation is done by static access: new Outer::Inner(1), which is
currently a syntax error.
How would I access static members on an inner class without having
ambiguity? `Outer::Inner::Const` already is valid syntax.
If this is a big "NO" (or
Hi all,
Enums are not allowed to include object properties and with property
hooks it's now possible to define get-only dynamic properties.
I just come across the following example and wonder if this could be
allowed in the future:
enum Month:int {
case January = 1;
case February =
Hey internals,
You may remember my RFC about Records (https://wiki.php.net/rfc/records). There
was something intentionally left out, and due to life events, I am quite behind
schedule on this one. BUT, what I left out (and the main reason for the short
syntax) is the ability to have locally sco
Hi
Am 2025-02-06 23:24, schrieb Christoph M. Becker:
request permission to add it to the general "Deprecations for PHP 8.5"
RFC[1] which is still in draft status (although it erroneously says
"Pending Implementation").
Just go ahead and make sure to add your name to the section you add.
We'll
Hi
Am 2025-02-07 05:57, schrieb Larry Garfield:
It is now back with a better implementation (many thanks to Ilija for
his help and guidance in that), and it's nowhere close to freeze, so
here we go again:
https://wiki.php.net/rfc/pipe-operator-v3
There's some editorial issues:
1. Status: D
On Wed, 5 Feb 2025, Christoph M. Becker wrote:
> There is some discussion on a recent bug report[1] about
> filter_input() and related functionality. The bug report had been
> closed, because this functionality has already been added to the
> general deprecation RFC for PHP 8.5[2]. Then the O
> Hello,
>
> I feel like that is more of an architecture problem than a programming one
> though. Instead of constantly checking if the conditions are right, use php's
> type system instead, so it would read more like:
>
> if ($response instanceof SuccessfulResponse) {
> return $response->data-
On Fri, Feb 7, 2025, at 10:21, MrMeshok wrote:
> >
> > Examples of potentially using in PHP:
> > Without this operator we writing this code:
> >
> > $foo = ...
> >
> > if ($foo === null) {
> > throw new FooIsNullException();
> > }
> >
> > $foo->bar.
> >
> > With this operator:
> >
> > $foo!->ba
>
> Examples of potentially using in PHP:
> Without this operator we writing this code:
>
> $foo = ...
>
> if ($foo === null) {
> throw new FooIsNullException();
> }
>
> $foo->bar.
>
> With this operator:
>
> $foo!->bar
> $foo!->someProperty->method();
> $foo!->someProperty->anotherProperty!->m
On Fri, Feb 7, 2025, at 1:36 AM, Eugene Sidelnyk wrote:
> Hi, Larry, That's super! I hope it will pass!
>
> Oladoyinbo, IMO the way it is described right now (e.g. explicit
> closures) is much more elegant than a new way of doing things that's
> not so obvious and will be necessary to keep in min
On Fri, Feb 7, 2025, at 05:57, Larry Garfield wrote:
> Hi folks. A few years ago I posted an RFC for a pipe operator, as seen in
> many other languages. At the time it didn't pass, in no small part because
> the implementation was a bit shaky and it was right before freeze.
> Nonetheless, t
> this email concerns my PR https://github.com/php/php-src/pull/17459,
> which extended the cli-SAPI’s `--ini` flag to print any INI settings
> that differ from the built-in default. There was some discussion around
> which flag to use, which didn't result in particularly strong opinions,
Even bef
26 matches
Mail list logo
