Repository navigation
The standard symbol for the metric prefix kilo- is k not K (so kB for kilobyte, not KB) #5
Description
Activity
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 😉
It turns out both
kBandKBare used. k- is the SI prefix, but K is often used in computing: https://en.wikipedia.org/wiki/KilobyteCan you recommended an action for resolution?
Since both are valid, offer the choice of a set with lowercase 'k' and the choice of a set with uppercase 'k'.
It is a weird issue. Microsoft use upper
Kfor base-2. GNU use upperKfor both base-2 and base-10, though they make a distinction between stand-aloneKandKB(1Kis 1024 bytes,1KBis 1000 bytes). Some other command-line tools likersyncmake the same distinction. The JEDEC standard uses upperKfor base-2. Mozilla use lowerkfor base-2. Apple have used upperKfor 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
oinstead ofBfor 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.
kBmakes the most sense to me, personally- IEC style, base-2 (
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 iskB. UsingKBfor 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, ...), andInformalSymbolDecorator(base 10; KB, MB, GB, ... with the option to omit the B for just K, M, G, ...).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.
Why are separate classes better?
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
IECSymbolDecoratorthrow an exception in that case, and vice versa for yourSISymbolDecorator, but that just seems weird, doesn't it?I don't know
As pointed out on reddit: https://www.reddit.com/r/PHP/comments/3yq3yx/byteformatter_is_a_psr2_compliant_library_that/cygfps8