Add Boolean method to interpret byte value as boolean?

[Maurizio Cimadamore]

On 20/02/2020 16:02, Ty Young wrote:
>
> On 2/20/20 8:13 AM, Maurizio Cimadamore wrote:
>> Yes - I think 0 == false has enough mathematical backing which would 
>> make sense to add it, IMHO. Other APIs do it too [1].
>
>
> Would 0 == false be a safe implementation of such a method? 
> Hypothetically if whatever command line switch was passed that allows 
> "dirty" memory, I imagine that this could cause issues since dirty 
> memory could be interpreted as true. Boolean.valueOf(<String>) also 
> checks for true instead of false.

I guess what I meant was that, from a mathematical perspective, there's 
enough ground for considering false and 0 as isomorphic. While it would 
be theoretically possible to imagine a language in which true is encoded 
as 0 and != 0 means false, that wouldn't be a very interesting language 
(e.g. because, in such a language, true | false != true)

So, after we buy that valueOf(0) has to be false, there's the separate 
secondary question you mention about what should happen when you provide 
a value that is != 0. Here I don't think there's any clear cut answer - 
and I'm afraid that just assuming e.g. 1 == true could be overly 
restrictive in certain cases (although it has the nice property that, if 
we went down this path, you could also allow for a unique reverse 
mapping, from boolean back to int).

Maurizio

>
>
>>
>> Also, if we had such a method, we could use it to adapt a byte 
>> returning VarHandle/MethodHandle into a boolean returning one.
>
>
> That would be nice!
>
>
>>
>> Maurizio
>>
>> [1] - 
>> https://commons.apache.org/proper/commons-lang/javadocs/api-2.4/org/apache/commons/lang/BooleanUtils.html#toBoolean(int)
>>
>> On 20/02/2020 13:56, Ty Young wrote:
>>> Hi,
>>>
>>>
>>> Many functions use boolean values to determine whether or not an 
>>> operation succeeded(true) or failed(false). Project Panama does not 
>>> actually see booleans however and instead interprets them as byte 
>>> values(which is technically correct). This means that in order to 
>>> convey the correct type as defined in C, you would need to do your 
>>> own check to see if the value is 1.
>>>
>>>
>>> There isn't, however, a standard method of doing this. Boolean only 
>>> has a function for getting a boolean from a string, not a byte. 
>>> Given that the need to convert a byte value to a boolean will be 
>>> more common with Project Panama it seems appropriate that one be added.
>>>
>>>
>>> Could this be done?
>>>
>>>