<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>I see where you are headed.</p>
<p>The question now is: is the configuration known at construction,
or is it only known when we call get() ?</p>
<p>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?</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 24/09/2025 15:20, david Grajales
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CADFQZ75X3rDmy4OetssbZjTbKH3CaAj1NASuAj0HBSUbOLeHgA@mail.gmail.com">
<div dir="ltr">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.
<div><br>
<div>var conf = "conf";</div>
<div>var foo2 = LazyCosntant.get(() -> {<br>
if (conf.isBlank()) {</div>
<div> // do some validations</div>
<div> }<br>
return new Foo(conf);<br>
});</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>private class Bar{</div>
<div> public final String confParam1;</div>
<div> public final int confParam2;</div>
<div> public Bar(String param1, int param2){</div>
<div> confParam1 = param1; confParam2 = param2;</div>
<div> }</div>
<div>}</div>
<div><br>
</div>
<div><br>
</div>
<div>var bar = new Bar("conf1", 42);</div>
<div>var foo2 = LazyValue.get(bar, s -> {<br>
if(/*Set some predicate for validation*/) {
<div> // do something</div>
<div> }</div>
return new Foo(s);<br>
});</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>Thank you so much and best regards.<br>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">El mié, 24 sept 2025 a la(s)
7:02 a.m., Maurizio Cimadamore (<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>)
escribió:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 24/09/2025 11:38, Per-Ake Minborg wrote:<br>
> I think the other examples you show (albeit I didn't
fully get how <br>
> they were supposed to work) would have issues regardless
of whether <br>
> there were language or library support for lazy
computation<br>
<br>
I'd like to amplify this point a little.<br>
<br>
Your example shows the use of a singleton -- an object that is
<br>
constructed once, then stashed in a static final field.<br>
<br>
However, the construction of the singleton (getInstance
method) depends <br>
on a parameter.<br>
<br>
This means that, effectively, getInstance will capture
whatever <br>
parameter value was passed the first time it was constructed.<br>
<br>
Now, there might be use cases for this, but such a use case
would also <br>
not be supported if using Kotlin's lazy, Scala's lazy val, or
our <br>
LazyConstant API (all of them are equivalent from an
expressiveness <br>
point of view).<br>
<br>
So, your claim that<br>
<br>
> this may indicate that a keyword or annotation-based
solution could be <br>
> a better fit.<br>
Feels a bit off -- either the example you provided is not what
you <br>
really had in mind, or, when you say _keyword_ you mean
something other <br>
than a lazy-like keyword (but as Per explained, while there
are some <br>
more obscure keywords in other languages that might provide
more <br>
flexibility, the semantics associated with such keywords feels
a bit <br>
ad-hoc, and surely not something we would like to permanently
bolt onto <br>
the language).<br>
<br>
Cheers<br>
Maurizio<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
</body>
</html>