and not a bit a more readable or at least an UTF-8 encoded name?
\n(as far as I can see the file is new in Symfony 6.1.0).
It's a \"cookie\" class, one with a unique distinct super-short name, internal also, needed for technical reasons (namely minimizing the size of the serialized payload).
\nI made it non-utf8 on purpose, to have a single-char class-name that has low collision chance.
-
|
Is there a special reason why there is in the file: src/Symfony/Component/Cache/Traits/ValueWrapper.php the ISO-8859-1 encoded line: and not a bit a more readable or at least an UTF-8 encoded name? |
Beta Was this translation helpful? Give feedback.
-
|
It's a "cookie" class, one with a unique distinct super-short name, internal also, needed for technical reasons (namely minimizing the size of the serialized payload). |
Beta Was this translation helpful? Give feedback.
-
|
its not something to be fixed on the symfony side, but just to give you an idea: the autoloader in the REDAXO project uses a json cache file for the autoloader, which does not work with non-UTF8 stuff. I try to fix it at the REDAXO end though. see german issue: redaxo/redaxo#5780 |
Beta Was this translation helpful? Give feedback.
-
|
By using such a character, you deliberately break PSR-1. https://www.php-fig.org/psr/psr-1/
I don't think it is very unreasonable that other tools expect to see UTF-8 everywhere in 2025. It is one option to state "all those other tools are at fault, they should be generalised enough to support all kinds of charsets." Another option would be to stop using the character and do UTF-8 like everyone else. |
Beta Was this translation helpful? Give feedback.
It's a "cookie" class, one with a unique distinct super-short name, internal also, needed for technical reasons (namely minimizing the size of the serialized payload).
I made it non-utf8 on purpose, to have a single-char class-name that has low collision chance.