21870-Fix-Base64-madness-for-good

[svenvc]

https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good

Reimplement ByteArray>>#base64Encoded using ZnBase64Encoder and update comment

Reimplement String>>#base64Decoded using ZnBase64Encoder and update comment - changing the return type from String to ByteArray

Remove String>>#base64Encoded

Fix Base64 users in image

Add Base64Tests to explicitly cover #base64Encoded and #base64Decoded

[dionisiydk]

Very good.
But could you explain difference between:

aString base64Decoded

and

ZnUtils decodeBase64: aString

Why in some places you use first version but in other places you use utils version?

[akgrant43]

+1 to Denis comment (I assume it is for the case where you really do want a string back after decoding the base 64).

It would be good to add comments to ZnUtils class>>en/decodeBase64:, and maybe to #base64Decoded / #base64Encoded pointing users to ZnUtils

[svenvc]

Excellent question, Denis !

ZnUtils class>>en/decodeBase64: act like the old methods (String<->String) but with an explicit use of ZnNullEncoder to indicate better what is happening - some internet protocols, like HTTP, use this in some places.

It was not strictly necessary to go via ZnUtils, but I felt it was appropriate in those few cases.

[svenvc]

And yes, Alistair, an extra comment could help. I will try to remember to add it.

[svenvc]

Thanks

[dionisiydk]

I have impression that it is better to write such string conversion just in place and avoid ZnUtils class:

aString decodedBase64 asString

It really shows the purpose in places like http where it is needed. But ZnUtils version only raises questions like "Why use utils instead of string method?".

ZnUtils decodeBase64: aString

It provides zero information about expected logic and expected value.
And generally it is confusing to see utils in one place in system and string based code in another place.

So I would deprecate these utils methods. Besides both expressions have equal size.

[dionisiydk]

Also using #asString in such "protocol" places (like http) is not nice. It would be better to introduce explicit asAsciiString and use it instead of #asString where we really need ascii string.