Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

2022-04-04 Thread MKS Archive
> 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 reason - 
> particularly once there are more than two or three parameters, and more than 
> a bit of punctuation between them.
> 
> 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.
> 
> As a silly example, I prefer this:
> 
> $sentence = "The {$adjectives[0]} {$adjectives[1]} {$nouns[0]} jumped over 
> the {$adjectives[2]} {$nouns[1]}";
> 
> To this:
> 
> $sentence = sprintf(
>'The %s %s %s jumped over the %s %s',
>$adjectives[0],
>$adjectives[1],
>$nouns[0],
>$adjectives[2],
>$nouns[1]
> );
> 
> I think that's partly a matter of taste, though, because I've definitely seen 
> people happily using both styles. And there are certainly situations (like 
> translation strings) where placeholders of some sort work better than 
> straight interpolation.

Choice of sprintf() vs string interpolation *can* be more than a matter of 
taste, and this from someone who once greater preferred the latter.

There are (at least) two use-cases I am familiar with where using printf() and 
sprintf() with placeholders have benefits over string interpolation.

1.) Internationalization of human-readable strings can be more easily 
facilitated when the literal text is kept distinct from the interpolated values.

2.) Reduced memory allocation and string manipulation when strings are used for 
logging that may be discarded when logging levels are set to less than "log 
everything." 

#fwiw

> That's why I thought it was interesting to see what other languages have 
> done. While PHP and Ruby have obvious links back to Perl, many languages 
> which didn't start off with string interpolation have added it in later 
> versions, e.g. C#, Scala, JavaScript, Python. Clearly there were sufficient 
> voices in favour in each of those communities to add it; and in each case, 
> they added *expression* interpolation, not just the *variable* interpolation 
> supported by Perl and PHP.
> 
> I won't be too upset if this feature doesn't get added, but I do think it 
> would be a nice addition.
> 
> Regards,
> 
> -- 
> Rowan Tommins
> [IMSoP]
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

2022-04-04 Thread Rowan Tommins

On 26/03/2022 22:22, Rowan Tommins wrote:
Maybe I'm trying to be "too helpful" there. Should we just use the 
generic deprecation message, and let people look up the in-depth 
explanation in the manual? 



I've dropped the custom deprecation message from the proposal, as 
there's just not room for the subtlety I was trying to get across.


I will open voting this time tomorrow unless anyone has any further 
comments.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php