Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support binary and decimal bytes (i.e. 1 kibi = 1024 b and 1 kb = 1000 b) #24

Merged
merged 28 commits into from Jan 4, 2020

Conversation

@omar
Copy link
Owner

omar commented Dec 1, 2016

Breaking Changes:

  • Drop support for all platforms except netstandard2.0.
  • Namespace changed to ByteSize from ByteSizeLib.
  • ByteSize renamed to NonStandardByteSize but keeps same functionality.

New Features:

  • DecimalByteSize object: 1 KB = 1000 B with abbreivations KB, MB, etc.
  • BinaryByteSize object: 1 KiB = 1024 B with abbreivations KiB, MiB, etc.
@omar omar force-pushed the metric-byte branch from 44330f2 to 166ccbb Dec 1, 2016
@shinji144
Copy link

shinji144 commented Nov 28, 2018

Looking forward to when this gets merged

@omar omar force-pushed the metric-byte branch from 166ccbb to fc5ad2e Dec 6, 2018
omar added 8 commits Dec 21, 2018
@omar
Copy link
Owner Author

omar commented Dec 24, 2018

I decided to make this v2 given the changes that went into. An alpha is up on NuGet https://www.nuget.org/packages/ByteSize/2.0.0-alpha1

@omar omar mentioned this pull request Jan 6, 2019
README.md Outdated
`ByteSize` assumes `1 kilobyte` = `1024 bytes`. See [why here](http://omar.io/2017/01/16/when-technically-right-is-wrong-kilobytes.html).
`ByteSize` comes with 3 different ways to represent bytes:

- `DecimalByteSize` which assumes `1 kilobyte` = `1000 bytes` with 2 letter abbrevations `b`, `B`,`KB`, `MB`, `GB`, `TB`, `PB`.

This comment has been minimized.

@lostbeaver

lostbeaver Feb 20, 2019

I've started to use your alpha-version and faced with problem with naming KB for Decimal. It seems that for Decimal it should be 'kB' instead of 'KB'.
https://en.wikipedia.org/wiki/Kilobyte
https://en.wikipedia.org/wiki/Mega-

This comment has been minimized.

@lostbeaver

lostbeaver Feb 20, 2019

It will be cool if you'll build version new alpha version before completing PR 😎

@sandrock
Copy link

sandrock commented Mar 15, 2019

I observed the BinaryByteSize DecimalByteSize NonStandardByteSize thing and I think it is wrong. Let me explain.

Have you ever worked with the DateTime struct? It represents a point in time. And it supports many many string representations that can all be parsed and rendered. There is even a calendar thing that can display a point in time from any calendar. And there are not many structs to work with it; there is just one.

I suggest keeping only one struct that can do all the desired jobs.

  • ToString() and ToStandardString() can be used to display a standard format
  • ToWindowsString() can be used to display the unacceptable but long-loved format (find another name if you wish. I do blame MS for this)
  • ToDecimalString() can be used to display the decimal format
  • ...

There are already some methods like these. FromKibiBytes and FromKiloBytes can be great together in the same class.

If you want compatibility for those who refuse the standard, you can make a static switch that will change the behavior of ToString.

If you don't like having multiple methods to get the string representation, then you can add an enum parameter or a renderer class.

If you still don't like that, you can also create a new format that can be passed to the ToString method (like DateTime). Something like "KiB#3" for "7.012 KiB", "BK" for "7 KB"...

What do you think?

@sandrock
Copy link

sandrock commented Mar 15, 2019

Here is how I tend to display sizes in HTML. Everyone can understand whatever the size is.

preview

There is only one size (1179694). There are many way of displaying it. So there should be one struct and many display methods.

Am I wrong?

@omar omar mentioned this pull request Mar 22, 2019
@Tyrrrz
Copy link
Contributor

Tyrrrz commented Mar 22, 2019

I agree with @sandrock.

Another comparison could be temperature. Temperature is a property of a substance. It can have a value, which is probably represented the most canonically as an average velocity of particles in that substance. But as we all know, the temperature also has many more common representations, i.e. Fahrenheit or Celsius.

The temperature in this context is file size (or "content-length", or, more precisely, "data size"). The base representation is the number of bytes, or just "bytes". Kilobytes, kibibytes, megabytes, mebibytes, etc. are all alternative representations.

It doesn't make much sense to have NonStandardByteSize and StandardByteSize because byte size is always the same, here, on Mars, or anywhere else. Representations, however, can vary.

@omar
Copy link
Owner Author

omar commented Mar 24, 2019

I appreciate the feedback in this thread.

To give some context, I initially had a single struct to manage both decimal and binary values. I went down the route of using separate structs make it explicit what the value being represented. I also wanted to keep backwards compatibility and provide users a way to do it the "wrong" way which is what the NonStandardByteSize struct is for. But thinking through this some more and reading the feedback here, I'm not seeing much value in doing it that way.

Given that, I'm thinking of dropping support for the non standard representation and going with the only decimal (kilobyte) and binary (kibibyte) because this is the trend we're heading down based on the limited research I've done.

So to summarize, alpha 2 of this will look like this:

  • Namespace reverted back to ByteSizeLib.
  • ByteSize struct with all the necessary methods to required for binary and decimals (i.e. FromKibiByte and FromKiloByte).
  • No support for representing a kilobyte as 1024 bytes.

Thanks again for taking the time to give your feedback. I'll get started on the changes above. In the meantime, let me know if you agree/disagree with the direction.

omar added 4 commits Mar 24, 2019
# Conflicts:
#	.travis.yml
#	Makefile
#	global.json
#	src/ByteSizeLib.Tests/ByteSizeLib.Tests.csproj
#	src/ByteSizeLib/ByteSizeLib.csproj
@omar
Copy link
Owner Author

omar commented Mar 28, 2019

I just pushed alpha 2 to NuGet. https://www.nuget.org/packages/ByteSize/2.0.0-alpha2

I realized that I don't have a good API setup for the .ToString to output a binary value. That's something I'll take a look at next.

I'm thinking .ToBinaryString() or just make the useBinaryByte parameter available on .ToString().

omar added 8 commits Jun 5, 2019
@omar omar merged commit 1bbc35a into master Jan 4, 2020
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@omar omar deleted the metric-byte branch Jan 4, 2020
@omar omar changed the title Support metric bytes (i.e. 1 kb = 1000 kb) Support binary and decimal bytes (i.e. 1 kibi = 1024 b and 1 kb = 1000 b) Jan 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.