You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
String constants are ubiquitous, and right now it requires significant ceremony to use them--you have to pass the constant from whatever method you're using from where you're computing it out to a static block where you initialize it.
It seems easy enough for the class builder to make this simpler. Could, for instance, have a method that can be called from anywhere, which handles setting up the constants, so that they can be used.
Which could do much the same thing, but allow inline definition at the point of use. In this case, the stringConstant call would have a side-effect of registering the constant, and return a StaticFieldReference as if we'd called getStatic. The advantage would be that it's concise, but I'm not sure multiplying the ways to do things is worth it.
The text was updated successfully, but these errors were encountered:
String constants are ubiquitous, and right now it requires significant ceremony to use them--you have to pass the constant from whatever method you're using from where you're computing it out to a static block where you initialize it.
It seems easy enough for the class builder to make this simpler. Could, for instance, have a method that can be called from anywhere, which handles setting up the constants, so that they can be used.
We could also support an api like:
Which could do much the same thing, but allow inline definition at the point of use. In this case, the stringConstant call would have a side-effect of registering the constant, and return a
StaticFieldReference
as if we'd calledgetStatic
. The advantage would be that it's concise, but I'm not sure multiplying the ways to do things is worth it.The text was updated successfully, but these errors were encountered: