Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
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 annoying to have to wrap the function in a
> > closure in order to use it.
> >
> > If this RFC is accepted I'd be able to replace code like this:
> >
> > $name = "Theodore Brown";
> > $strlen = fn(string $string): int => strlen($string);
> > echo "{$name} has a length of {$strlen($name)}.";
> >
> > with
> >
> > $name = "Theodore Brown";
> > echo "{$name} has a length of {$:strlen($name)}.";
>
>
> Out of curiosity, why not:
>
> $name = "Theodore Brown";
> echo "{$name} has a length of ".strlen($name).".";
>
> or even
>
> $name = "Theodore Brown";
> $len = strlen($name);
> echo "{$name} has a length of {$len}.";
Concatenation works fine for a simple example like this, but it can
get a lot messier when there are more than a few embedded variables.
It's particularly an issue with heredoc strings which are far more
cumbersome to concatenate.
Yes, it's possible to add extra variables before the string like in
your second example, but this feels like unnecessary work, especially
when you already have all the variables you want and just want to
apply a function to them at several places in a template string.
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
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
> >>
> >> 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 think.
> >
> > 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?
>
> Do you have an example of a new kind of attack this would allow?
> The proposal doesn't enable interpolation of strings coming from
> a database or user input - it only applies to string literals
> directly in PHP code.
>
> 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 annoying to have to wrap the function in a
> closure in order to use it.
>
> If this RFC is accepted I'd be able to replace code like this:
>
> $name = "Theodore Brown";
> $strlen = fn(string $string): int => strlen($string);
> echo "{$name} has a length of {$strlen($name)}.";
>
> with
>
> $name = "Theodore Brown";
> echo "{$name} has a length of {$:strlen($name)}.";
>
>
> Sincerely,
>
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
> 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
>
> Writing code in strings is a DX nightmare, and static analysis challenge.
>
> PHP is improving onto a more verbose, typed, but exprsssive language, and
> this change would make that harder.
>
> I'm also thinking if this could become a LCE/RCE vulnerability in a type of
> eval() situation. Not a huge point but just an observation.
>
> Happy to re evaluate a new approach to solve the same problem that doesn't
> involve coding inside strings.
Although I agree that code execution in strings is not a great idea, it should
be noted that this is already possible today, so that this proposal does not
add a new capability. Indeed, the proposed syntax:
"{$:/* arbitrary expression here */}";
is equivalent to:
$expr = fn($_) => $_;
"{$expr(/* arbitrary expression here */)}";
—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
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 challenge.
PHP is improving onto a more verbose, typed, but exprsssive language, and
this change would make that harder.
I'm also thinking if this could become a LCE/RCE vulnerability in a type of
eval() situation. Not a huge point but just an observation.
Happy to re evaluate a new approach to solve the same problem that doesn't
involve coding inside strings.
On Fri, 18 Mar 2022, 14:09 Pierre, wrote:
> 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
> interpolation.
> https://wiki.php.net/rfc/arbitrary_string_interpolation
>
> Let me know what you think.
> >>> 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?
> >> Do you have an example of a new kind of attack this would allow?
> >> The proposal doesn't enable interpolation of strings coming from
> >> a database or user input - it only applies to string literals
> >> directly in PHP code.
> >>
> >> 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 annoying to have to wrap the function in a
> >> closure in order to use it.
> >>
> >> If this RFC is accepted I'd be able to replace code like this:
> >>
> >> $name = "Theodore Brown";
> >> $strlen = fn(string $string): int => strlen($string);
> >> echo "{$name} has a length of {$strlen($name)}.";
> >>
> >> with
> >>
> >> $name = "Theodore Brown";
> >> echo "{$name} has a length of {$:strlen($name)}.";
> >>
> >>
> > Out of curiosity, why not:
> > $name = "Theodore Brown";
> > echo "{$name} has a length of ".strlen($name).".";
> >
> > or even
> > $name = "Theodore Brown";
> > $len = strlen($name);
> > echo "{$name} has a length of {$len}.";
>
> I guess it's a matter of taste and convention.
>
> Sometime, it make sense and it's just easier to just use string
> interpolation (for example with multiline templates).
>
> Regards,
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
[PHP-DEV] Re: Deprecated partially supported callables: should is_callable() throwa deprecation notice ?
On 18-3-2022 14:37, Christoph M. Becker wrote:
On 16.03.2022 at 06:52, Juliette Reinders Folmer wrote:
I've just been looking in detail at the Partially Supported Callables
deprecation RFC:
https://wiki.php.net/rfc/deprecate_partially_supported_callables
The RFC explicitly excludes the `is_callable()` function and the
`callable` type from throwing deprecation notices.
The |is_callable()| function and |callable| type remain side-effect
free and do not throw a deprecation warning. They will continue to
accept these callables until support is removed entirely.
While I can fully support this for the `callable` type, I wonder if the
decision to not throw a deprecation on use in `is_callable()` is the
right one (though I understand the desire to keep it side-effect free).
Consider these code samples:
function foo(callable $callback) {}
foo('static::method');
This function call not throwing a deprecation is not problematic as in
PHP 9.0 the function will start throwing a TypeError.
if (is_callable('static::method')) {
static::method();
}
The second code sample, however, is problematic, as in PHP 9.0, the
behaviour of this code will be silently reversed for those callbacks
which would previously result in `is_callable()` returning true, which
makes this a potentially dangerous change without deprecation notice.
Would anyone care to enlighten me as to whether this was given due
consideration ?
Frankly, I don't know. Apparently, there was almost no discussion about
that RFC. Part of the reasoning to not raise E_DEPRECATED when calling
is_callable() was likely the typical use case
$callable = …;
if (is_callable($callable)) {
call_user_func($callable);
}
what would report the deprecation when actually calling the callable.
Not sure what to do regarding your given use case(s).
--
Christoph M. Becker
Unfortunately, those aren't the only places I see this happening and my
example is not a stand-alone case either.
I came across the above code sample ( is_callable('static::method') /
is_callable(['parent', __FUNCTION__]) with variable method calls) in a
number of different packages when testing a (PHPCompatibility) sniff I
am writing to detect the deprecation, so this code pattern looks to be
relatively common.
Some examples:
*
https://github.com/symfony/service-contracts/blob/bc0a2247c72d29241b5a06fb60dc1c9d9acf2a3a/ServiceSubscriberTrait.php#L39
*
https://github.com/mockery/mockery/blob/c10a5f6e06fc2470ab1822fa13fa2a7380f8fbac/library/Mockery/Mock.php#L960
*
https://github.com/simplepie/simplepie/blob/dacf0ed495d2e8fb306e526ca3f2a846af78a7c9/tests/oldtests/absolutize/RFC3986.5.4/base.php#L13
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
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
interpolation.
https://wiki.php.net/rfc/arbitrary_string_interpolation
Let me know what you think.
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?
Do you have an example of a new kind of attack this would allow?
The proposal doesn't enable interpolation of strings coming from
a database or user input - it only applies to string literals
directly in PHP code.
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 annoying to have to wrap the function in a
closure in order to use it.
If this RFC is accepted I'd be able to replace code like this:
$name = "Theodore Brown";
$strlen = fn(string $string): int => strlen($string);
echo "{$name} has a length of {$strlen($name)}.";
with
$name = "Theodore Brown";
echo "{$name} has a length of {$:strlen($name)}.";
Out of curiosity, why not:
$name = "Theodore Brown";
echo "{$name} has a length of ".strlen($name).".";
or even
$name = "Theodore Brown";
$len = strlen($name);
echo "{$name} has a length of {$len}.";
I guess it's a matter of taste and convention.
Sometime, it make sense and it's just easier to just use string
interpolation (for example with multiline templates).
Regards,
--
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
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://wiki.php.net/rfc/arbitrary_string_interpolation
> >>
> >> Let me know what you think.
> >
> > 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?
>
> Do you have an example of a new kind of attack this would allow?
> The proposal doesn't enable interpolation of strings coming from
> a database or user input - it only applies to string literals
> directly in PHP code.
>
> 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 annoying to have to wrap the function in a
> closure in order to use it.
>
> If this RFC is accepted I'd be able to replace code like this:
>
> $name = "Theodore Brown";
> $strlen = fn(string $string): int => strlen($string);
> echo "{$name} has a length of {$strlen($name)}.";
>
> with
>
> $name = "Theodore Brown";
> echo "{$name} has a length of {$:strlen($name)}.";
>
>
Out of curiosity, why not:
$name = "Theodore Brown";
echo "{$name} has a length of ".strlen($name).".";
or even
$name = "Theodore Brown";
$len = strlen($name);
echo "{$name} has a length of {$len}.";
>
> Sincerely,
>
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
[PHP-DEV] Re: Deprecated partially supported callables: should is_callable() throwa deprecation notice ?
On 16.03.2022 at 06:52, Juliette Reinders Folmer wrote:
> I've just been looking in detail at the Partially Supported Callables
> deprecation RFC:
> https://wiki.php.net/rfc/deprecate_partially_supported_callables
>
> The RFC explicitly excludes the `is_callable()` function and the
> `callable` type from throwing deprecation notices.
>
>> The |is_callable()| function and |callable| type remain side-effect
>> free and do not throw a deprecation warning. They will continue to
>> accept these callables until support is removed entirely.
>
> While I can fully support this for the `callable` type, I wonder if the
> decision to not throw a deprecation on use in `is_callable()` is the
> right one (though I understand the desire to keep it side-effect free).
>
> Consider these code samples:
>
> function foo(callable $callback) {}
> foo('static::method');
>
> This function call not throwing a deprecation is not problematic as in
> PHP 9.0 the function will start throwing a TypeError.
>
> if (is_callable('static::method')) {
> static::method();
> }
>
> The second code sample, however, is problematic, as in PHP 9.0, the
> behaviour of this code will be silently reversed for those callbacks
> which would previously result in `is_callable()` returning true, which
> makes this a potentially dangerous change without deprecation notice.
>
> Would anyone care to enlighten me as to whether this was given due
> consideration ?
Frankly, I don't know. Apparently, there was almost no discussion about
that RFC. Part of the reasoning to not raise E_DEPRECATED when calling
is_callable() was likely the typical use case
$callable = …;
if (is_callable($callable)) {
call_user_func($callable);
}
what would report the deprecation when actually calling the callable.
Not sure what to do regarding your given use case(s).
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Convert return to expression like throw
On 18/03/2022 10:18, Florian Stascheck wrote:
function getUnreadDocuments(): int {
$documents = Auth::user()?->getDocuments() ?? return 0;
// actual logic of the function
return 42;
}
I think I'd probably reject that example as too cryptic in a code
review; the mixture of assignment and control flow is hard to follow,
even more so than this, which is already possible:
if ( ! $documents = Auth::user()?->getDocuments() ) return 0;
I can imagine some people would like it, though, particularly those used
to the Perl "doSomething() or die;" idiom.
The throw expression has uses in things like lambdas and match
expressions, which only accept expressions not statements. I can't think
of any examples where "return" would be useful in such contexts, and in
fact wonder what they'd even do:
return $foo = match(1) { default => return 42; }
$foo = fn() => return 42;
function foo() { return return 42; } // presumably you could stack this
endlessly, "return return return return 42;"
function foo() { yield return 42; }
Throwing exceptions already aborts the control flow, so doing so in the
middle of an expression is easy to understand; having an early return in
the middle of an expression is harder to understand.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Convert return to expression like throw
Hello,
We remember the old days, when we had to do:
function getUnreadDocuments(): int {
$user = Auth::user();
if (is_null($user)) return 0;
$documents = $user->getDocuments();
if (is_null($documents)) return 0;
// actual logic of the function
return 42;
}
And it was already really nice to do:
function getUnreadDocuments(): int {
$documents = Auth::user()?->getDocuments();
if (is_null($documents)) return;
// actual logic of the function
return 42;
}
But I think it could be written even more concise with just reusing
existing syntax elements:
function getUnreadDocuments(): int {
$documents = Auth::user()?->getDocuments() ?? return 0;
// actual logic of the function
return 42;
}
This is exactly the type of change that PHP 8.0 introduced for throw (
https://wiki.php.net/rfc/throw_expression) and to me it feels very natural
to write code that has this change also made for the return statement. In
the example above, depending on developer preference, the same result could
be achieved with " || return 0;" instead of the ?? operator.
Was there any previous discussion about this and was there maybe a good
reason it hasn't been implemented? I couldn't find anything when searching.
What are your thoughts on this?
-Florian
Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation
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 know what you think. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
