> On Mar 26, 2022, at 6:15 PM, Rowan Tommins wrote:
>
> On 25/03/2022 14:38, Arnaud Le Blanc wrote:
>> I find that sprintf() is easier to read in most cases. One reason for this is
>> that the text is separated from the code.
>
>
> Funnily enough, I find sprintf() *harder* to read for the same
Hi,
> A large part of that is because the placeholders are positional rather
> > than named, so you have to keep track of which is which; but by the time
> > you've got named placeholders, you might as well have variable
> > interpolation.
>
> I feel the same way. PHPStorm has a feature that highl
> All the other languages I looked at have support for full expressions in
> their interpolation forms:
Thank you Rowan, I added the comparison of other languages to the RFC.
> A large part of that is because the placeholders are positional rather
> than named, so you have to keep track of which
On 25/03/2022 14:38, Arnaud Le Blanc wrote:
I find that sprintf() is easier to read in most cases. One reason for this is
that the text is separated from the code.
Funnily enough, I find sprintf() *harder* to read for the same reason -
particularly once there are more than two or three parame
Hey Ilija.
On 25.03.22 15:38, Arnaud Le Blanc wrote:
Hi Ilija
I find that sprintf() is easier to read in most cases. One reason for this is
that the text is separated from the code. It's also easier to review for
humans and linters.
The strtoupper example would look like this with sprintf:
Hi Ilija
I find that sprintf() is easier to read in most cases. One reason for this is
that the text is separated from the code. It's also easier to review for
humans and linters.
The strtoupper example would look like this with sprintf:
$world = 'world';
echo sprintf('Hello %s!', strt
On 21/03/2022 10:27, Robert Landers wrote:
> The downside of a prefix is that it isn't backwards compatible. You
could use # in a suffix so if you need to write backwards compatible
code, you can. So maybe:
>
> echo "{$x#10.3f}";
>
> which can be written like this in backwards compatible code:
On Mon, Mar 21, 2022 at 10:51 AM Rowan Tommins
wrote:
> On 20/03/2022 13:39, Rowan Tommins wrote:
> > Using a second colon would make ternary expressions slightly awkward;
> > C# handles this by requiring them to be parenthesised, so "{$:( $test
> > ? $x : $y )}" would be valid but "{$:$test ? $x
On 20/03/2022 13:39, Rowan Tommins wrote:
Using a second colon would make ternary expressions slightly awkward;
C# handles this by requiring them to be parenthesised, so "{$:( $test
? $x : $y )}" would be valid but "{$:$test ? $x : $y}" would not; we
could use some other delimiter, but they'd p
On 18/03/2022 17:49, Paul Dragoonis wrote:
Writing code in strings is a DX nightmare
Can you expand a bit on what you mean by that? It seems to be common to
assert the opposite, that string interpolation is much more convenient
than the alternatives.
Looking around, it seems nearly all cu
On Fri, Mar 18, 2022 at 11:01 PM Theodore Brown
wrote:
> On Fri, Mar 18, 2022 at 09:02 Chase Peeler wrote:
> > On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown
> wrote:
> > >
> > > Personally I'm really looking forward to having this functionality.
> > > Just a couple days ago I wanted to call a
On Fri, Mar 18, 2022 at 09:02 Chase Peeler wrote:
> On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown
> wrote:
> >
> > Personally I'm really looking forward to having this functionality.
> > Just a couple days ago I wanted to call a function in an interpolated
> > string, and it was really annoyi
i'd write it as
$name = "Theodore Brown";
echo "{$name} has a length of " . strlen ( $name ) . ".";
On Fri, 18 Mar 2022 at 05:49, Theodore Brown wrote:
> On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm
> wrote:
>
> > On Thu, 17 Mar 2022, 23:27 Ilija Tovilo, wrote:
> >
> >> Hi everyone
> >>
> >>
> Le 18 mars 2022 à 18:49, Paul Dragoonis a écrit :
>
> I think the original goal of this RFC is to make PHP more expressive, and
> less clunky (look at Jav). This is a good goal and one much desired by the
> community, but I think the approach here isn't the right fit or way to
> achieve it
I think the original goal of this RFC is to make PHP more expressive, and
less clunky (look at Jav). This is a good goal and one much desired by the
community, but I think the approach here isn't the right fit or way to
achieve it
Writing code in strings is a DX nightmare, and static analysis cha
Le 18/03/2022 à 15:02, Chase Peeler a écrit :
On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown
wrote:
On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm
wrote:
On Thu, 17 Mar 2022, 23:27 Ilija Tovilo, wrote:
Hi everyone
I'd like to start discussion on a new RFC for arbitrary string
interpolat
On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown
wrote:
> On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm
> wrote:
>
> > On Thu, 17 Mar 2022, 23:27 Ilija Tovilo, wrote:
> >
> >> Hi everyone
> >>
> >> I'd like to start discussion on a new RFC for arbitrary string
> >> interpolation.
> >> https://wi
I've wanted this for years!
Robert Landers
Software Engineer
Utrecht NL
On Thu, Mar 17, 2022 at 11:27 PM Ilija Tovilo
wrote:
> Hi everyone
>
> I'd like to start discussion on a new RFC for arbitrary string
> interpolation.
> https://wiki.php.net/rfc/arbitrary_string_interpolation
>
> Let me kn
On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm wrote:
> On Thu, 17 Mar 2022, 23:27 Ilija Tovilo, wrote:
>
>> Hi everyone
>>
>> I'd like to start discussion on a new RFC for arbitrary string
>> interpolation.
>> https://wiki.php.net/rfc/arbitrary_string_interpolation
>>
>> Let me know what you thi
That is a cool idea.
But I am not a big fan of having code in strings. Wouldn’t this open the door
to all kinds of new attacks?
// Tobias
> On 17 Mar 2022, at 23:30, Marco Pivetta wrote:
>
> Hey Ilija,
>
> Overall not a fan: want more `sprintf()` and less interpolation, where
> possible 😬
>
Hey Ilija,
Overall not a fan: want more `sprintf()` and less interpolation, where
possible 😬
Couldn't we let the construct slowly decay into nothingness, perhaps?
On Thu, 17 Mar 2022, 23:27 Ilija Tovilo, wrote:
> Hi everyone
>
> I'd like to start discussion on a new RFC for arbitrary string
>
21 matches
Mail list logo