jamesstarr commented on PR #3965:
URL: https://github.com/apache/calcite/pull/3965#issuecomment-2357145268

   > 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.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to