Fluid
Fluid copied to clipboard
TYPO3
[BUGFIX] Fix math expression error verbosity
Prevents seeing the “non-numeric value encountered” error from PHP when a template attempts to do math on a variable that is not declared, or does not have the right type. See code comments for exact behavior.
The intention is to match PHP type coercion as close as possible - among other things by inferring NULL as value when a variable is most likely not defined.
In case you didn't notice... this actually sneaks in neat ability:
<f:render partial="MyPartial" arguments="{_all + another}" />
Doesn't allow you to define the array inside the expression, only works on variables - but works.
I did notice and I think this should be done as a separate change to give it the spotlight it deserves. ;-)
Something to consider: should we allow left/right side to be null when the other is an array and the operator is +? In which case, we just return whichever side was not-null (implied coercion of (array) $valueThatIsNull).
I hesitate to do this array union as a separate change exactly because it won't allow the array to be built directly in the expression. It's also not as easily done with another expression node type. It would be far easier to handle if that lexer I'm working on was a reality.
If/when we do that, I expect it will instead look a bit like arguments="{_all} + {foo: 'bar'}" - in other words, a change that affects how arrays are detected and built, not something that affects an object accessor.
With separate change I mean separate PR with exactly the same code as here, not some kind of different syntax or so.
Yes, I understood that, but I'd argue that this isn't a feature or a separate bugfix - it still falls into the category of this same error prevention (by guarding against arrays being divided, for example). You could still do this before, you'd just receive some nasty errors in pretty much all contexts if you didn't do it 100% correctly. Now you don't :)