Can I use value classes in shared code from Swift? I defined in my shared code this: ```@JvmInline ...

# multiplatform

[Stefan Oltmann]

Can I use value classes in shared code from Swift?

I defined in my shared code this:

@JvmInline
value class PhotoUri(val value: String)

In Swift PhotoUri is not defined according to the error message.
Attributes that use it seem to be of type Any now.

If I change that to an data class it's available.

How can I use value classes with Kotlin v1.6.10?

[hfhbd]

You can't: https://kotlinlang.org/docs/native-objc-interop.html#unsupported

[Stefan Oltmann]

Damn. 😕

[Paul Woitaschek]

Well it kind of works, but only if it's not nullalbe iirc.

[Stefan Oltmann]

What does "billable" mean?

[Paul Woitaschek]

Autocorrect, nullable

[Paul Woitaschek]

Depending on the context it exports either as the backing data type or of Any

[Paul Woitaschek]

Iirc if the backing type is primitive and nullable it's of type any

[Stefan Oltmann]

That would be really helpful.

[Stefan Oltmann]

Actually in my context it's not nullable, but still an Any

[Paul Woitaschek]

How does your context look like?

[Stefan Oltmann]

I might remember wrongly, but I think there was something about support for value classes... Phillip pointed me to the inline (the former construct) classes which are not supported.

[Paul Woitaschek]

Anyways, it will cause you issues, so rather go with a regular data class or an expect typealias that resolves to a proper class for ios

[Stefan Oltmann]

My context looks like that I have a data class called Photo which has a non-nullable field PhotoId - and that should be a value class.

[Paul Woitaschek]

And not in a generic?

[Stefan Oltmann]

Yes, I use data classes now - but I'm well aware of all the GC this procuces. Not a problem right now, but I try to avoid memory issues in the first place.

[Paul Woitaschek]

I don't find value classes to helpful anyways. It's more often than not that they box for us

[Stefan Oltmann]

I don't really understand your question. 🙈

I want to pass around an PhotoSourceId instead of the int to be type safety.

data class PhotoSource(

    val id: PhotoSourceId,

    val type: PhotoSourceType,

)

value class PhotoSourceId(val value: Int)

[Stefan Oltmann]

You know... if you have a method that takes xId, yId, and zId and that are all ints how easy it is to mess that up. 😉

[Paul Woitaschek]

Then a data class it is

[Stefan Oltmann]

data class produces a new instance every time. value class in my understanding will be treated as an int an completely disappears at byte code level

[Stefan Oltmann]

Using data class produces garbage here. int would be better for performance. But I'm for clean code, so I prefer type safeness.

[Paul Woitaschek]

No not really. Sometimes. But if you put stuff in a list iirc it boxes. An instance here and there doesn't create memory pressure

[Stefan Oltmann]

It does not box if you use trove4j for that. 😉

[Paul Woitaschek]

https://typealias.com/guides/inline-classes-and-autoboxing/

[Stefan Oltmann]

But that's another topic ^^

[Stefan Oltmann]

Good article, thanks for sharing. 🙏

[hfhbd]

And I am doing the same thing at the moment 😄 Adding an ID class for each DTO class to prevent mixing different ids

[Stefan Oltmann]

It's a good practice. In the past years I learned that the hard way by doing it wrong.

First I used the actual instances, which was fine for some time. But then I needed to call the methods from places where I did not have them and loading the instance from a database to pass it to a method that eventually only needs the ID is expensive - so I used "fake objects" that just had the ID set. It did not take long before other people thought it was a real full object and used attributes that just were the default value (because not loaded from database).

After that I replaced everything with the IDs... but then I had methods that took 3 different objects, all referenced by ID as int... and people started to mix that up by not paying attention.

This both paths lead to hell 🙈

[Stefan Oltmann]

So yes, having a MyObjectId class for every MyObject produces more GC, but it's the safest and cleanest thing to do in the long term.

[Stefan Oltmann]

I was thrilled reading about value objects to solve that GC overhead and I'm a bit disappointed to see that I can't use them because of the missing Swift support.

[Stefan Oltmann]

But Paul has a good point here...
While I expect every developer to know that putting an int into an List<Integer> will autobox and create a new Integer object (a long as the number is not so small that in can be taken from the constant pool of course) having a PhotoSourceId which in reality is an int hides this and may have unexpected results for everyone that did not look up what type of class my PhotoSourceId actually is.

[Stefan Oltmann]

So, thank you, Paul, for bringing that up 🙏

[Paul Woitaschek]

I'm only arguing that probably the perf overhead if most of the time negligible. Proper classes for ids is 👍

[Stefan Oltmann]

Ok, if that wasn't your point you still brought me to this. 😉