Should there be a `fun <A> Lazy<A>.map...

# getting-started

[Rob Elliot]

Should there be a fun <A> Lazy<A>.map(f: (A) -> B): Lazy<B>? Or am I missing the point / misusing Lazy?

[Casey Brooks]

Lazy is primarily used as a property delegate, not as a full pipeline for lazy calculations. That’s what Sequence is for.

Just set up a second property that’s also lazy, which references the first.

class LazyClass {
    val lazyA: String by lazy { "a" }
    val lazyB: String by lazy { lazyA.uppercase() }
}

[Rob Elliot]

In this case it's only one thing though, and it needs to be passed as a Lazy rather than used as a property delegate.

[Casey Brooks]

It’s the same basic thing to keep the Lazy type

class LazyClass {
    val lazyA: Lazy<String> = lazy { "a" }
    val lazyB: Lazy<String> = lazy { lazyA.value.uppercase() }
}

Though I’d be wary of passing around the Lazy objects themselves. I think that would make your app likely to cause memory leaks because of what’s captured in the lambdas. Again, it’s not really meant to be used in this way. If you want to have a function in your app lazily pulling values from a source, you probably should be using something like Sequence or Flow instead, which are designed for that usecase. Otherwise, get the value at the point you need to pass it around

[Rob Elliot]

It's the result of a successful request to /.well-known/openid-configuration. I want the request to:

• be made successfully once and only once in the lifetime of the process - no need to ever repeat it once you've got the values, in the extremely unlikely case that they change we'll just kill the process and start another
• not be made on startup as the provider being unavailable should not cause the process to exit
• be repeated until it is successful in the event that the provider is briefly unavailable
• have its result (or derivatives of its result - hence the original Q) constructor injected into various singleton services
I've always hated the use of things which imply 0..N cardinality for things which have 1 (or 0..1 I guess, as it may fail eternally) cardinality.

Lazy meets all those criteria for me.

[Casey Brooks]

Yeah, that’s definitely not a good use-case for the Lazy API, especially the bit about retrying on failure and using DI to pass it around. Also doesn’t sound like Sequence or Flow are a good choice either, since you’re not looking for reactivity. A proper caching library would be a better way to go. Caffeine is a popular solution in Java apps, and DropBox’s Store is one I’ve used in the past on Android (and looks like it now supports KMPP)