Question about binary variants

[evilertoaster]

Is this intended behavior?

$bin=Binary("0x01")
dim $copy
$copy&=$bin
MsgBox(0,"",IsBinary($copy));returns 0

[martin]

Is this intended behavior?

$bin=Binary("0x01")
dim $copy
$copy&=$bin
MsgBox(0,"",IsBinary($copy));returns 0

I think so. Variable type are converted when a value is assigned so the binary value 0x01 is converted to an integer if you used += , but if you use &= it assumes you want a string. Variables default to strings (I think) when they are declared.

To make sure you have a binary value do this

$bin=Binary("0x01")
dim $copy = Binary(0);<--force a binary type variable
$copy += $bin
MsgBox(0,"Binary",IsBinary($copy)=1)
Dim $copy1
$copy1 &= $bin
MsgBox(0,"string",IsString($copy1)=1)
Dim $copy2 
$copy2 += $bin
MsgBox(0,"Int",IsInt($copy2)=1)

[evilertoaster]

I think so. Variable type are converted when a value is assigned so the binary value 0x01 is converted to an integer if you used += , but if you use &= it assumes you want a string. Variables default to strings (I think) when they are declared.

To make sure you have a binary value do this

Hum, yes we know this. But I'm moreso asking if it's intended from a design perspective(or if you think it should,which you did comment on) for the & operator to assume a string instead of a binary variant if nothing is assigned. If it where to do this all the time you could not concat two binary variants at all...

They do defualt to string types, eg-

dim $a
MsgBox(0,"",IsString($a))

but I would assume them to behave more dynmically (like a variants do it most other cases) based on thier assignments... Well, could be something to bring up in a feature request maybe. Anyone else have any comments?

Edited May 19, 2008 by evilertoaster

[Jon]

All concatenations are done as strings unless both are binary variants in which case it will do a binary concat.

[evilertoaster]

That seems to clarify the case.

So the counterintuitive thing for me then is simply that the string type takes predicence on unassigned variants when pairing up.

Would it be precident for them (unassigned variants) to simply take a null or 'no type' by default, which would translate to the 'no value' type for whichever variant type it's matched with? e.g. for float parings it would become 0, string parings would be null string and binary pairings would be null (null binary as the langauge percieves it?).

Perhaps then, his is more of a feature request... (Unless Jon/Dev, you have an answer outright?)

Edited May 19, 2008 by evilertoaster

[Jon]

Concatenation is a string operation, so I'm not sure I see the problem.