Wip scope populator

[jamesstarr]

No description provided.

[julianhyde]

Looks pretty good.

I'm tempted to make the following next steps:

• Rework it to make SqlValidator implement ScopeMap, and reduce the amount of noise. (I take your point that maybe the interfaces should be decoupled eventually.)
• Make ScopeMapImpl package-private
• Make ScopeMapImpl it immutable (with the mutable bits in a builder)
• Address the Checkerframework issues (yes they are painful, but they generally point to real problems in lifecycle)

[jamesstarr]

Looks pretty good.

I'm tempted to make the following next steps:

• Rework it to make SqlValidator implement ScopeMap, and reduce the amount of noise. (I take your point that maybe the interfaces should be decoupled eventually.)
• Make ScopeMapImpl package-private
• Make ScopeMapImpl it immutable (with the mutable bits in a builder)
• Address the Checkerframework issues (yes they are painful, but they generally point to real problems in lifecycle)

@julianhyde, the ScopeMap interface is already read-only, which provides most of the clarity we gain from immutability. The additional clarity from introducing an explicit immutable version of ScopeMap is marginal, while the complexity introduced is significant. This is due to your desire for a redelegation layer in SqlValidator, the existing circular dependencies between ScopeMap, namespaces, and SqlValidator, and the non-trivial methods in ScopeMapImpl, which need to support downstream overriding while not have code duplication. In addition, the scopeMap reference would have to mutate within SqlValidatorImpl, which would create a complex lifecycle and essentially negate the intended clarity.

Allowing downstream projects to override ScopeMapImpl is why it's currently package-scoped. Moreover, several methods in ScopeMap and ScopeMapImpl are public or protected, so we'd need to provide an API for overriding those methods moving forward, unless we plan to offer an upgrade path for projects that have customized them.

Given the complexity of these interactions and the time it would take to implement, I’m not willing to introduce an immutable version of ScopeMap at this time. However, the work on the ScopeMap interface will make it easier to add an immutable version later, once the circular dependencies are resolved.

I can add a redegalation layer to SqlValidator, but please be very explicit on why you want this, because I do not understand. All it seems to do is adding 200 lines of boilerplate while making api opaque and creating future work.

[sonarcloud]

Quality Gate passed

Issues
19 New issues
0 Accepted issues

Measures
0 Security Hotspots
91.7% Coverage on New Code
0.2% Duplication on New Code

See analysis details on SonarCloud