\LazyJsonMapper\MagicSpecialOperators

encodeOperators()

encodeOperators(string  $str) : string

Encode special operators.

Parameters

Returns

Output string.

decodeOperators()

decodeOperators(string  $str) : string

Decode special operators.

Parameters

Returns

Output string.

_buildTranslations()

_buildTranslations() 

Build the table of special operator translations.

PHP doesn't allow these special operators in function names, so we cannot legally generate such function names. Instead, we'll encode the operators with a sequence that will never appear in our normal algorithm's output.

For example, if the user has a property named en-US, our special operator translation will give it a function name of getEn_x2D_US() to safely encode the arithmetic minus symbol.

This encoding scheme was deliberately chosen thanks to the fact that it will never conflict with anything else that's legitimately generated by our algorithm. Because if the user has a property that's actually named en_x2D_US, then that one would be encoded as getEnX2D_US() (by the main PropertyTranslation algorithm), which is obviously not the same thing and will never confuse our parser in decoding later. And if they sent us en__x2D_US, it would be encoded as getEn_X2D_US(), which is yet again different (the X is uppercase in that situation too).

Therefore, our special encoding of _x[HEX]_ will never be generated by any legitimate user property names, even if those names do contain that sequence on-disk. They'll all be encoded to something else. The only thing that can put a lowercase x in this particular arrangement is our own operator symbol translator here.

As for why we need that long sequence instead of something shorter, it's unfortunately the only way that we can guarantee uniqueness. It relies on the principle that _x in the user's own properties would ALWAYS be encoded as X. Most programmers are familiar with hex codes and will recognize the sequences we've chosen: getEn_x2D_US(), where x stands for "hex", and 2D is the hex character value for the minus symbol.

This particular encoding also allows us to easily encode future illegal characters of any length (even multiple bytes such as _xFFFF_ if ever necessary) without needing to change the encoding scheme again.