Hi, all.
Given that there have been no objections or additional comments, we will
proceed to remove
the default implementation classes of the affected classes. Thank you to
everyone who was
involved.
--
Best！
Xuyang
在 2025-01-03 13:41:16，"Ron Liu" <ron9....@gmail.com> 写道：
>Hi, Xuyang
>
>Thanks for initialized this proposal. +1 for remove the default
>implementation because 2.0 is breaking change, we don't need to keep api
>compatibility.
>
>Best,
>Ron
>
>Feng Jin <jinfeng1...@gmail.com> 于2025年1月3日周五 13:36写道：
>
>> +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
>> >
>>
