+1 Directly remove the default implementation, as this allows issues to be detected at compile time rather than at runtime. Even if we keep these methods, it doesn’t seem to make much sense.
Best, Feng Jin On Fri, Jan 3, 2025 at 12:57 PM Xuyang <xyzhong...@163.com> wrote: > +1 to delete the overrided default methods that throw exceptions. > > > > > -- > > Best！ > Xuyang > > > > > 在 2025-01-03 12:55:38，"Xuyang" <xyzhong...@163.com> 写道： > > The discuss will be open for at least 72 hours to collect dicisions. > > -- > > Best！ > Xuyang > > > > > > At 2025-01-03 12:06:38, "Xuyang" <xyzhong...@163.com> wrote: > >Hi, all. > > > >Feng Jing, Ron Liu and I are are currently working on removing deprecated > public APIs from the table module and have encountered an issue. > > > >Take CatalogFactory as an example, the CatalogFactory class implements > both the new api Factory and the deprecated api TableFactory. Within > > > >CatalogFactory, all methods of the new api Factory have default > implementations that currently return errors, providing compatibility with > the old > > > >api TableFactory. As we move forward with the removal of the deprecated > api TableFactory, we are uncertain about whether to remove the default > > > >methods from the new api Factory. > > > >There are two options: > > > >1. Leave it unchanged for now: The advantage of this approach is that we > adhere to the principle of not modifying public APIs at all. However, I > believe that having missed the release-2.0, we may not have another > opportunity to remove it in the near future. Additionally, this option is > not very user-friendly for custom connectors, as they would only discover > the absence of certain methods at runtime. > > > >2. Directly remove the default implementations where throw exceptions > directly: The benefit of this approach is that it informs users at compile > time that they must implement certain methods. The downside is that we are > "slightly" modifying the public API methods. Connectors that are very old > and only compatible with the old API stack without integrating the new API > stack would encounter compile-time errors (although in any case, they would > ultimately face runtime errors, wouldn’t they?). > > > >We would appreciate any insights or suggestions regarding this decision. > Thank you! > > > > > > > > > >Please note that similar situations exist with ModuleFactory and others; > we won't discuss each one individually going forward. > > > > > > > > > >-- > > > > Best！ > > Xuyang >
