An interesting idea. Do you have any idea of the values $format and $unit would accept? Would it handle both decimal-based GB etc and binary-based GiB etc [1]?
What about other units that can be scaled in the same way, like metres? Would it make more sense to make it a unit-formatting function or library - and if so, does it need to be in core, or could it just be a lightweigh Composer dependency people could grab when they needed it?
[1] https://en.m.wikipedia.org/wiki/Binary_prefix
I've implemented this function and two other size-related in php [1], but I
think they should be in php core to avoid implementation of them by
thousands of people. This draft is only for demonstation purposes. There
are presented three functions:
a. size_format([$format,] $bytes [, $unit]): string
Formats size in appropriate or specified in $unit unit like sprintf() does.
For example, default format is "%.3F Ui" which means:
-
%.3F is a sprintf-macro that will be replaced by size value
-
U means upper-cased unit (MB, GB and so on)
-
i means binary prefix
So, formatted string will be like "1.457 KiB"
b. size_parse($string): integer
Parses string that contains size value and unit in integer containing size
in bytes.
c. size_transform(float $size, $from, $to): float
Translates size in one unit to another.
You can see examples of usage in test file [2]. They all support size units
up to YB and both decimal (GB) and binary (GiB) prefixes and can translate
size values between prefixes.
[1] https://github.com/wapmorgan/ext-size
[2] https://github.com/wapmorgan/ext-size/blob/master/test.php
Please fix your mail program to provide a name and In-Reply-To and
References headers so that we can address somebody and your mails are
sorted correctly.
I've implemented this function and two other size-related in php [1], but I
think they should be in php core to avoid implementation of them by
thousands of people. This draft is only for demonstation purposes. There
are presented three functions:a. size_format([$format,] $bytes [, $unit]): string
If we do it this must be generic and work for "everybody". This is not
trivial. i.e. for 1001 bytes depending on context any of these might be
"correct":
- 1001 byte
- 0.98 KiB
- 0.98 kB
- 0,98 kB
- 1 KiB
- 1 KB
- 1 Ko
- ...
Also one often wants different precision depending on the value - 100 MB (not 100.23 MB)
- 1.44 MB (not 1 MB)
Feel free to come back with a more complete proposal and provide a name,
a proper subject etc. (... and even then I doubt this has to be part of
the core distribution, we should only add things which can't be done in
userland (due to libraries or performance requirements or similar) as
userland code is more flexible to change/improve and simpler to debug
for users and especially with PHP 7 fast enough for mot things)
johannes
2015-10-06 17:01 GMT+03:00 Johannes Schlüter johannes@schlueters.de:
Please fix your mail program to provide a name and In-Reply-To and
References headers so that we can address somebody and your mails are
sorted correctly.I've implemented this function and two other size-related in php [1],
but I
think they should be in php core to avoid implementation of them by
thousands of people. This draft is only for demonstation purposes. There
are presented three functions:a. size_format([$format,] $bytes [, $unit]): string
If we do it this must be generic and work for "everybody". This is not
trivial. i.e. for 1001 bytes depending on context any of these might be
"correct":
- 1001 byte
- 0.98 KiB
- 0.98 kB
- 0,98 kB
- 1 KiB
- 1 KB
- 1 Ko
- ...
Not all of them are correct. 0.98 kB for 1001 b is not correct, for example.
But with current behavior I got these results without any modification of
source code:
"1001 b"
"0.98 KiB"
"0.98 kb"
"1.00 kb"
"1 KiB"
"100 MiB"
"1.44 MiB"
Also one often wants different precision depending on the value
- 100 MB (not 100.23 MB)
- 1.44 MB (not 1 MB)
Feel free to come back with a more complete proposal and provide a name,
a proper subject etc. (... and even then I doubt this has to be part of
the core distribution, we should only add things which can't be done in
userland (due to libraries or performance requirements or similar) as
userland code is more flexible to change/improve and simpler to debug
for users and especially with PHP 7 fast enough for mot things)
I don't think that some people prefer kB. Also, what "ko" is?
johannes