The standard symbol for the metric prefix kilo- is k not K (so kB for kilobyte, not KB)

[hikari-no-yume]

As pointed out on reddit: https://www.reddit.com/r/PHP/comments/3yq3yx/byteformatter_is_a_psr2_compliant_library_that/cygfps8

[Bilge]

Thanks Andrea, I appreciate you creating the issue, however it would be helpful if you linked a source that verifies this claim so I don't have to Google it myself :wink:

[hikari-no-yume]

It turns out both kB and KB are used. k- is the SI prefix, but K is often used in computing: https://en.wikipedia.org/wiki/Kilobyte

[Bilge]

Can you recommended an action for resolution?

[hikari-no-yume]

Since both are valid, offer the choice of a set with lowercase 'k' and the choice of a set with uppercase 'k'.

[okdana]

It is a weird issue. Microsoft use upper K for base-2. GNU use upper K for both base-2 and base-10, though they make a distinction between stand-alone K and KB (1K is 1024 bytes, 1KB is 1000 bytes). Some other command-line tools like rsync make the same distinction. The JEDEC standard uses upper K for base-2. Mozilla use lower k for base-2. Apple have used upper K for both base-2 and base-10.

I don't think there's a clean answer to how they should be used. If you wanted to be thorough i guess you'd need to provide five different sets of prefixes:

• IEC style, base-2 (Ki == 1024)
• SI style, base-10 (k == 1000)
• SI style, base-2 (k == 1024)
• Computing style, base-10 (K == 1000)
• Computing style, base-2 (K == 1024)

That gets pretty messy though. If you really wanted to make everyone happy i guess what you'd do is provide a mechanism for users to define their own units. In addition to addressing this question you would also eliminate one of the two things that make this library English-specific — French users could specify o instead of B for example. (The other thing that makes it English-specific is the fixed decimal separator.)

idk if you want it to be that fancy though. If you don't, i would suggest just picking one. kB makes the most sense to me, personally

[drrcknlsn]

The consumer already has the ability to define their own decorator, so we're really just talking about making sure the bundled decorators are correct according to their respective sets. The metric/SI prefix for kilo- is k, and so kilobyte is kB. Using KB for kilobyte is perfectly reasonable (it's very common informally), but it shouldn't be presented as part of the metric/SI set, because it isn't.

Personally, I would like to see each base/set pulled into its own decorator. That would give you something like MetricSymbolDecorator (base 10; kB, MB, GB, ...), IECSymbolDecorator (base 2; KiB, MiB, GiB, ...), and InformalSymbolDecorator (base 10; KB, MB, GB, ... with the option to omit the B for just K, M, G, ...).

[okdana]

Sorry, i hadn't looked far enough into the decorators to see that you could extend them easily. That does address that. I agree with your second paragraph, having separate pre-defined decorators would be neat.

[Bilge]

Why are separate classes better?

[okdana]

For my part, it seems like it'd be simplest for the end user if they didn't have to pass in a bunch of constants all over the place.

On balance, though, it might not work. The decorators are designed to accept the base from the formatter (which certainly seems reasonable — otherwise they'd have to know about the mathematics, right? which would make them... not decorators), so it doesn't really make sense to have ones that're inherently tied to a particular base. What if someone did like

(new ByteFormatter(new IECSymbolDecorator())
    ->setBase(10)
    ->format(16384)
;

for example? It wouldn't make any sense. I guess you could have your IECSymbolDecorator throw an exception in that case, and vice versa for your SISymbolDecorator, but that just seems weird, doesn't it?

I don't know