Hi Timo, I am throwing some second thoughts here, as I don't quite see what trait provides over abstract class here for TableEnvironment case. Trait in scala can also have implementation and you can have 'private[flink]' or 'protected' type and method in trait as well.
AFAIK, the differences between Scala trait and abstract class are: 1) you can have constructor for abstract class, but not in trait 2) Abstract classes are fully interoperable with Java. You can call them from Java code without any wrappers. Traits are fully interoperable only if they do not contain any implementation code for scala 2.11. 3) you can do multiple inheritance or mixin composition with trait. In the TableEnvironment case, 1) I don't see a need for mixin, and class hierarchy seems fit better here by design. 2) to better interoperate with Java from scala 2.11, it's better to use abstract class. (But AFAIK, scala 2.12 and java 8 would be compatible, though) 3) you might pay a bit performance overhead with trait (compiled to interface) compared to abstract class, but it's not a big deal here. But in other cases, trait might be a better one if it might be reused and mixined in multiple, unrelated classes. So another option would be to refactor TableEnvironment to clean up or move the 'private[flink]' or 'protected' stuff to the actual implementor (e.g. 'InternalTableEnvironment') as you would do for your trait approach for TableEnvironment. I think this option might help with backward compatibility as well. Thanks. Shuyi On Fri, Mar 2, 2018 at 10:25 AM, Rong Rong <walter...@gmail.com> wrote: > Hi Timo, > > Thanks for looking into this Timo. It's becoming increasingly messy for my > trying to locate the correct functions in IDE :-/ > > This is probably due to the fact that Scala and Java access modifiers / > qualifiers are subtly and fundamentally different. Using Trait might be the > best solution here. Another way I can think of is to move the all > TableEnvironment classes to Java side, but that would probably introduce a > lot of issue we need to resolve on the Scala side though. "protected" is > less restrictive in Java but there's really no equivalent of package > private modifier on Java. > > I was wondering is there any better way to provide backward-compatible > support though. I played around with it and seems like every "protected" > field will create a private Java member and a public getter, should we add > them all and annotate with "@Deprecated" ? > -- > Rong > > On Thu, Mar 1, 2018 at 10:58 AM, Timo Walther <twal...@apache.org> wrote: > > > Hi everyone, > > > > I'm currently thinking about how to implement FLINK-8606. The reason > > behind it is that Java users are able to see all variables and methods > that > > are declared 'private[flink]' or even 'protected' in Scala. Classes such > as > > TableEnvironment look very messy from the outside in Java. Since we > cannot > > change the visibility of Scala protected members, I was thinking about a > > bigger change to solve this issue once and for all. My idea is to convert > > all TableEnvironment classes and maybe the Table class into traits. The > > actual implementation would end up in some internal classes such as > > "InternalTableEnvironment" that implement the public traits. The goal > would > > be to stay source code compatible. > > > > What do you think? > > > > Regards, > > Timo > > > > > -- "So you have to trust that the dots will somehow connect in your future."
