[HN Gopher] Java: New Draft JEP: "Computed Constants"
       ___________________________________________________________________
        
       Java: New Draft JEP: "Computed Constants"
        
       Author : mfiguiere
       Score  : 19 points
       Date   : 2023-08-03 22:00 UTC (59 minutes ago)
        
 (HTM) web link (minborgsjavapot.blogspot.com)
 (TXT) w3m dump (minborgsjavapot.blogspot.com)
        
       | snihalani wrote:
       | feedback: pls move java syntax towards python. thx
        
         | vore wrote:
         | Pros: maybe subjectively feels better for some people?
         | 
         | Cons: extremely painful amounts of churn for everyone
        
         | marginalia_nu wrote:
         | So code in jython?
        
       | recursivedoubts wrote:
       | please for the love of gosling give us reasonable data structure
       | literals nobody cares about this stuff i just want to be able to
       | create a map or list w/o ceremony please
        
         | whywhywhydude wrote:
         | Perhaps you are using the wrong language. You should probably
         | just stick with python or javascript where they just have
         | simple lists and maps and pretty much nothing else.
        
           | quickthrower2 wrote:
           | Boss says ... ... "no"
        
         | thfuran wrote:
         | You mean List.of and Map.of?
        
           | recursivedoubts wrote:
           | yes, but real syntax
        
         | ptx wrote:
         | Kotlin (which has very smooth interoperability with Java) makes
         | it pretty easy:                 mapOf("a" to 1, "b" to 2)
         | 
         | ...where "to" is actually an infix extension function that
         | creates a Pair object, so there is no special syntax for maps.
        
       | p2detar wrote:
       | Looks similar to the java.util.function.Supplier interface.
        
         | samus wrote:
         | It's that, plus caching. It's basically what a thunk is called
         | in Haskell land. You could also describe it as a Future, but
         | with a vastly simplified API (no exceptions to catch when
         | calling `get()`) thanks to being intended for the single-
         | threaded case.
        
       | lolinder wrote:
       | It looks like this is going to be the Java version of Kotlin's
       | lazy [0] and Scala's lazy val [1].
       | 
       | [0] https://kotlinlang.org/docs/delegated-
       | properties.html#lazy-p...
       | 
       | [1] https://www.baeldung.com/scala/lazy-val
        
         | mfiguiere wrote:
         | There were another JEP draft [1] recently that was proposing to
         | introduce a lazy keyword for static fields. This new JEP looks
         | like an alternative without any language change, and seems more
         | likely to prevail.
         | 
         | [1] JEP draft: Lazy Static Final Fields -
         | https://openjdk.org/jeps/8209964
        
       | java-man wrote:
       | Wouldn't this be better:                 private static final Log
       | log = const Log.getLog("yo");
       | 
       | instead of all that rigmarole around ComputedConstants?
        
         | lolinder wrote:
         | This proposal is trying to implement lazy evaluation without
         | adding any new syntax. Your version would require a change to
         | the parser, where this is just a new standard class.
         | 
         | A commenter above points out that there's a competing proposal
         | that does introduce new syntax in the form of a `lazy` keyword:
         | 
         | https://news.ycombinator.com/item?id=36993023
        
         | samus wrote:
         | The architects are wary about introducing new syntax into the
         | Language. If it can be accomplished with an API, it should be
         | done that way. Also, this keyword would probably use something
         | like ComputedConstants in the background, and doing it this way
         | would sweep that under the rug, which is also generally not how
         | most Java features work. The delayed nature of this
         | initialization is also not explicitly highlighted (unlike the
         | lambda we would have to use with ComputedConstants), which
         | _will_ eventually bite people.
        
       ___________________________________________________________________
       (page generated 2023-08-03 23:00 UTC)