[External] : Re: Scope Locals
Andrew Haley
aph at redhat.com
Tue May 11 09:34:25 UTC 2021
On 4/27/21 9:47 PM, Jack Firth wrote:
> No, what I meant was literally that I think the multi-variable case looks weird if the static entrypoint method for starting a chain of bindings also accepts a binding. I would rather see something like this:
>
> ScopeLocal.builder()
> .with(x, expr1)
> .with(y, expr2)
> .run(() -> ...);
>
> When I used a hypothetical scope() method earlier, I was imagining it would be statically imported.
>
> For context, I work at Google and we use google-java-format <https://github.com/google/google-java-format> for formatting code. One of the lessons we've learned is that trying to keep stuff horizontally aligned interacts badly with refactoring tools and autoformatters. Even if the tools can preserve it correctly, it means that things like renaming a method can have much larger diffs than they otherwise would. If ScopeLocal was renamed to ScopeBuilder, for example, only the ScopeLocal.builder() line would change in my example above. But if the code was written as:
>
> ScopeLocal.with(x, expr1)
> .with(y, expr2)
> .run(() -> ...);
>
> ...then renaming ScopeLocal to ScopeBuilder would require that the whole chain be reindented.
I don't think I'd do that, just preferring to indent four spaces. It
seems odd to add a static builder() method just for the sake of
indentation tools, but I too use such tools all the time, so I'm
for that reason opposed to any syntax that actually *requires*
manual indentation.
> For the one-variable case, I'd probably just prefer an instance method on the variables themselves:
>
> x.runWith(expr, () -> ...);
OK, understood. I'll quite happily go with whatever people prefer.
I agree with the need for the single-argument case, and I've already done one
based on what Brian suggested.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the loom-dev
mailing list