# RFC proposal.

- Thread: https://externals.io/message/88694
- Original archive: https://news-web.php.net/php.internals/88694
- Started by somebody anon on 2015-10-06T11:42:17+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #88694 — somebody anon — 2015-10-06T11:42:17+00:00

URL: https://externals.io/message/88694#88694

> 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

---

## #88696 — johannes@schlueters.de — 2015-10-06T14:01:08+00:00

URL: https://externals.io/message/88694#88696 · In reply to: #88694

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

---

## #88701 — Sergey Vanyushin — 2015-10-06T16:02:18+00:00

URL: https://externals.io/message/88694#88701 · In reply to: #88696

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.
>
> > […]
> but I
> > […]
>
> 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