Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128043
Precedence: bulk
MIME-Version: 1.0
References: <CAOV5rgZjxhe+75YD13wWFRNghbS4fbUrJVouPtbUv9RdpKSAXw@mail.gmail.com>
 <348856E5-6A4E-455A-81AE-882832170168@rwec.co.uk> <CAOV5rgaKkR-y3Hu9Fs0_ty2wT5MoYLDJ_OTH-nDBA-g__t4VEA@mail.gmail.com>
 <AE53E18F-A195-4D40-8BD1-D75AAFE07F92@rwec.co.uk> <CAOV5rgYNXLvBaBW50KpzNTFC7wEVBC0+QdSPmKhqsdGyc3uPWQ@mail.gmail.com>
 <38e57171-fc2e-4d79-8614-0b1c5a2efc72@app.fastmail.com> <CAOV5rgbCVFHPivdKn7oWbKbOD9yaGXu2h5jgoGg9vmBz=mq3Gw@mail.gmail.com>
 <e0a9d131-f24d-4d0d-83f9-08f023530d21@app.fastmail.com> <CAOV5rgaCbUmSsh=YGPtbvijOa+fCZKMPudGnzhThCg54tt89FA@mail.gmail.com>
In-Reply-To: <CAOV5rgaCbUmSsh=YGPtbvijOa+fCZKMPudGnzhThCg54tt89FA@mail.gmail.com>
Date: Tue, 15 Jul 2025 00:26:36 +0300
Message-ID: <CAPhkiZz4951RNix1pH+kAk0EbOTN6icj0Q3NkV59cG8heuMjSg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API
To: ignace nyamagana butera <nyamsprod@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003c9c040639ea5144"
From: narf@devilix.net (Andrey Andreev)

--0000000000003c9c040639ea5144
Content-Type: text/plain; charset="UTF-8"

Hi all,

I have a few suggestions, starting with naming improvements:
- Forgiving instead of Lenient (align with
https://infra.spec.whatwg.org/#forgiving-base64)
- Shorten the option names; one example would be Variable/Constant instead
of Unprotected/ConstantTime, but I think most could be rethinked
- $input or $data instead of $decoded (could actually do the same instead
of $encoded, but that one doesn't feel as wrong)
- Not strictly about naming, but it similarly feels wrong that
UnableToDecodeException extends EncodingException (which seems to have no
purpose)

However, I'm not a fan of how these simple functions have so many option
flags ... it feels forced, trying to accomodate too much at once. I'd
rather have discrete functions, like base64_*() and base64url_*() - I chose
this example because base64 and base64url also have arguably different
desirable defaults for padding; almost all pad-stripping I've seen in the
wild has been for the purposes of converting to base64url.
On a semi-related note, I'm not sure if including the IMAP variant isn't
complicating things for no good reason (it is extra-niche, and we have
imap_binary/base64() already).

Also, the RFC doesn't specify whether DecodingMode::Strict would cause an
error in case of missing padding?

That being said, I'm very glad to see this!

Cheers,
Andrey.

--0000000000003c9c040639ea5144
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>I have a few suggest=
ions, starting with naming improvements:</div><div></div><div>- Forgiving i=
nstead of Lenient (align with <a href=3D"https://infra.spec.whatwg.org/#for=
giving-base64">https://infra.spec.whatwg.org/#forgiving-base64</a>)</div><d=
iv>- Shorten the option names; one example would be Variable/Constant inste=
ad of Unprotected/ConstantTime, but I think most could be rethinked</div><d=
iv>- $input or $data instead of $decoded (could actually do the same instea=
d of $encoded, but that one doesn&#39;t feel as wrong)</div><div>- Not stri=
ctly about naming, but it similarly feels wrong that=20
UnableToDecodeException extends EncodingException (which seems to have=20
no purpose)</div><div><br></div><div>However, I&#39;m not a fan of how thes=
e simple functions have so many option flags ... it feels forced, trying to=
 accomodate too much at once. I&#39;d rather have discrete functions, like =
base64_*() and base64url_*() - I chose this example because base64 and base=
64url also have arguably different desirable defaults for padding; almost a=
ll pad-stripping I&#39;ve seen in the wild has been for the purposes of con=
verting to base64url.</div><div>On a semi-related note, I&#39;m not sure if=
 including the IMAP variant isn&#39;t
 complicating things for no good reason (it is extra-niche, and we have=20
imap_binary/base64() already).</div><div><br></div><div>Also, the RFC doesn=
&#39;t specify whether DecodingMode::Strict would cause an error in case of=
 missing padding?</div><div><br></div><div>That being said, I&#39;m very gl=
ad to see this!</div><div><br></div><div>Cheers,</div><div>Andrey.</div></d=
iv>

--0000000000003c9c040639ea5144--