Review Request: 7088913/7088952 : Additions to primitive wrappers
Ulf.Zibis at gmx.de
Thu Sep 22 02:40:05 PDT 2011
Am 22.09.2011 01:54, schrieb Mike Duigou:
> I will create a request to add Boolean.SIZE though I am not sure adding a Boolean.BYTES is appropriate for something less than Byte.Size in size. Is it 1-bit? Is it 1-byte? The answer is dependant upon usage and I don't think we can force a single answer.
> On Sep 21 2011, at 03:36 , Ulf Zibis wrote:
>> why don't we have Boolean.SIZE and Boolean.BYTES ?
Yep, not easy to make a right decision here.
One if the questions might be, if SIZE/BYTES are meant as resolution (2**SIZE = number of distinct
values) or as memory usage.
I would say: SIZE should be meant as resolution, but BYTES as memory usage. This would add
additional value to the new introduced constant.
Boolean.SIZE = 1
Boolean.BYTES = 4 (8 for 64-bit build)
> ... At the VM level they map to ints.
This is not always true. Arrays of byte are mapped to byte in VM. For boolean, it's theoretically
possible to map a boolean to one int.
> For that matter I'm not sure the addition of BYTES is worth the effort.
Yes or not, I'm unsure. My first feeling was, there _must_ be some additional APIs to justify the
change to a new release, here 8. ;-)
But I think, it's reasonable to have a short cut when calculating the footprint of some data,
instead repeating SIZE/Bytes.SIZE in code. That said, there should be a clear definition, if BYTES
is meant as VM-memory-footprint or persistent-storage-footprint e.g. by serialization, or we should
More information about the core-libs-dev