Hey Ilija.
On 11.03.22 18:13, Ilija Tovilo wrote:
Hi everyone
It's been a while. Hope you are doing well.
Last year I sent an e-mail to the mailing about the current state of
string interpolation in PHP. I have now created an RFC to better
explain the current behavior and why it would make sen
On Sat, Mar 12, 2022 at 3:11 AM BohwaZ wrote:
> This RFC is confusing two different things:
>
> 1. variables inside strings (options 1, 2, 3)
> 2. dynamic variables names (option 4)
>
> The 4th one is very useful.
>
> $v = ${'param_' . $name};
>
Please don't ever ever ever write code like that!
+1 on removing variable variables as soon as possible.
On 12 March 2022 02:11:38 GMT, BohwaZ wrote:
>This RFC is confusing two different things:
>
>1. variables inside strings (options 1, 2, 3)
>2. dynamic variables names (option 4)
>
>The 4th one is very useful.
>
>$v = ${'param_' . $name};
>
>There is no other practical way to do that, so removing t
> The RFC is *only* about how variables are interpolated *inside quoted
> strings*.
Then it doesn't seem clear in the RFC that it's limited to variables
inside strings, maybe it should be made clearer that it's only proposed
to deprecate that syntax inside strings, and not the variables
variables
On 12.03.2022 09:42, Andreas Heigl wrote:
First of all it would make it much easier for me to see what impact this
RFC has if there were any numbers in it of how many large-scale
repositories on for example github are affected by this.
I just checked my projects' vendor folders and I found a d
On 12 March 2022 11:30:15 GMT, BohwaZ wrote:
>> The RFC is *only* about how variables are interpolated *inside quoted
>> strings*.
>
>Then it doesn't seem clear in the RFC that it's limited to variables
>inside strings
In not quite sure how you missed it, because the word "string" is there in th
Hi everyone, thanks for the feedback! I'll be responding to everyone
in the same e-mail to minimize noise.
---
Hi Rowan
> I presume the intent here is that the engine will generate an
> E_DEPRECATED each time such a string is encountered. Do you know yet if
> that will be easy to implement? I th
I've started voting for the Allow null and false as stand-alone types RFC:
https://wiki.php.net/rfc/null-false-standalone-types
Voting will last for 2 weeks until 26th of March.
Best regards,
George P. Banyard
At present, PHP cannot be built using LTO (Link Time Optimization).
LTO is a compiler feature that can improve performance by optimizing at
link time.
Chromium is also using this feature.
https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html
The reason for the LTO failure appears to be the Zen
Maybe I'm a little late to this discussion, but is there any reason why
*false|null* is allowed but *true|null* is not?
I can think of few cases where *true|null* could be interesting, but I've
been through situations like this.
Atenciosamente,
David Rodrigues
Em sáb., 12 de mar. de 2022 às 14
On Sat, 12 Mar 2022 at 18:18, David Rodrigues
wrote:
> Maybe I'm a little late to this discussion, but is there any reason why
> *false|null* is allowed but *true|null* is not?
>
> I can think of few cases where *true|null* could be interesting, but I've
> been through situations like this.
>
tr
In fact, it does not seem to work very well.
Hi Go Kudo,
I read about the LTO feature from GCC in the past, and in my opinion,
LTO works have many years of improvement in the GCC, it works pretty
good nowadays. But programmers of Open Source projects were really
clever the last twenty years
Hello,
What I am trying to do is hold onto another PHP object in an internal
struct.
I.E:
position = new Vector3();
$camera3d->position->x++;
The reason for this is that the Camera3D struct has additional data I
need to track, so it cannot be an object of raw values.
// Vector3, 3 components
14 matches
Mail list logo
