given some constraints, I have to express some logic via boxed primitives It turns out I also have t...

# getting-started

[elect]

given some constraints, I have to express some logic via boxed primitives
It turns out I also have to collect them in a map, but different boxed instance of the same value (ie java.lang.Boolean(true), which returns a boxed Boolean) won't be seen as different keys, that is they would be overwritten
how can I solve it?

[Vampire]

Why should they be seen as different keys?
A true boolean is a true boolean.

[Vampire]

Use something else as key

[elect]

the key is the instance itself, I'll be using referential equality later on

[elect]

the manual solution is to have two lists, one for the keys, one for the values

[Vampire]

Even referential equality might not help you.
Not sure how it is in Kotlin, but in Java you would get the same instance.

[Youssef Shoaib [MOD]]

Box them yourself with something like a Ref type.
Something like this:

sealed class Ref
class IntRef(val value:Int): Ref
class BooleanRef(val value:Boolean): Ref
// etc.

[Klitos Kyriacou]

The expression java.lang.Boolean(true) would indeed create a boxed instance with a unique reference. However, this constructor has been deprecated since Java 9, and may be removed in a future release. Also, you would have to use IdentityHashMap if you use actual Boolean with different identities. Youssef's suggestion of creating your own boxing class is better. However, it seems a very odd thing to do, using keys that rely on referential identity. What is your use case? It sounds like an X-Y problem.

[Vampire]

Ah, right, somehow thought about valueOf

[elect]

@Klitos Kyriacou it's a Terraform DSL.
Imagine something like this:

resource "tls_locally_signed_cert" "example" {
    ...
}
resource "x" "y" {
   booleanProp = tls_locally_signed_cert.example.ready_for_renewal
}

translated in Kotlin to:

val example by tls_locally_signed_cert {
    ...
}
val y by x {
   booleanProp = example.ready_for_renewal
}

ready_for_renewal is a Boolean, but under the hood, when I synthesize the Terraform HCL language (first example), I need to retrieve the right string for booleanProp

[elect]

at first, I tried to lock that boolean variable to the corresponding string somewhere in a top-level property and that's why my request.
But now I'm leaning toward another design, given that those are all delegated props (both left and right), I'm gonna write the string at the top-level for every getValue till the next setValue , which will grab all the strings (it might be a list) and then clear the top-level container prop