I am not sure what you mean. but in my particular case the configuration class is a class that reads the fields of a properties file. this properties has a path to an CSV file with a list of IP addresses for IoT sensors and I use that path to fill a list of addresses to send and read some signals to the sensors. So I think both initialization processes can be lazy, even if one depends on another. I suppose that's what you mean by "known at construction time"?
El mié, 24 sept 2025 a la(s) 9:50 a.m., Maurizio Cimadamore ( [email protected]) escribió: > I see where you are headed. > > The question now is: is the configuration known at construction, or is it > only known when we call get() ? > > If the former, then we can express it as a lazy field of some sort > (perhaps one with a weird initialization action). But if the latter, that's > no longer "just" a lazy field, I think. Would you agree? > > Maurizio > > > On 24/09/2025 15:20, david Grajales wrote: > > Hi Maurizio and Minborg. Thank you so much for the response. I will focus > on explaining the part with the parameters for building objects. This > scenario is not as unique at it may seems, I used a singleton because I > thought it would be the easiest example but it's true it may not be the > most representative. I will hold my thoughts until I test the new API. but > I still would like to propose something. The supplier based factory > requires to capture a reference to an external variable in case we need to > set some parameters to create or compute the lazy constant, which can't > hurt performance a little if used often. > > var conf = "conf"; > var foo2 = LazyCosntant.get(() -> { > if (conf.isBlank()) { > // do some validations > } > return new Foo(conf); > }); > > I think it would be worth considering adding a function based factory that > accepts an object T (a configuration class to pass the parameters), and a > function that accepts the parameter and returns the lazy computed value. > > private class Bar{ > public final String confParam1; > public final int confParam2; > public Bar(String param1, int param2){ > confParam1 = param1; confParam2 = param2; > } > } > > > var bar = new Bar("conf1", 42); > var foo2 = LazyValue.get(bar, s -> { > if(/*Set some predicate for validation*/) { > // do something > } > return new Foo(s); > }); > > I think it's cleaner and safer (also a little more performant since the > parameter can be inlined and not captured as an external element, and since > deferred initialization is pretty much about squeezing performance it may > be worth considering this). besides it may internally check for T not null. > > Thank you so much and best regards. > > > > El mié, 24 sept 2025 a la(s) 7:02 a.m., Maurizio Cimadamore ( > [email protected]) escribió: > >> >> On 24/09/2025 11:38, Per-Ake Minborg wrote: >> > I think the other examples you show (albeit I didn't fully get how >> > they were supposed to work) would have issues regardless of whether >> > there were language or library support for lazy computation >> >> I'd like to amplify this point a little. >> >> Your example shows the use of a singleton -- an object that is >> constructed once, then stashed in a static final field. >> >> However, the construction of the singleton (getInstance method) depends >> on a parameter. >> >> This means that, effectively, getInstance will capture whatever >> parameter value was passed the first time it was constructed. >> >> Now, there might be use cases for this, but such a use case would also >> not be supported if using Kotlin's lazy, Scala's lazy val, or our >> LazyConstant API (all of them are equivalent from an expressiveness >> point of view). >> >> So, your claim that >> >> > this may indicate that a keyword or annotation-based solution could be >> > a better fit. >> Feels a bit off -- either the example you provided is not what you >> really had in mind, or, when you say _keyword_ you mean something other >> than a lazy-like keyword (but as Per explained, while there are some >> more obscure keywords in other languages that might provide more >> flexibility, the semantics associated with such keywords feels a bit >> ad-hoc, and surely not something we would like to permanently bolt onto >> the language). >> >> Cheers >> Maurizio >> >> >>
