rapidsai
Make UDF source type parameter strongly-typed
Description
This Pull Request removes the ambiguous is_ptx parameter and replaces it with a clearer enum: udf_source_type.
This is in line with CUDF's convention of using enums in place of booleans when there's a very high likelihood for semantic and type/parameter confusion.
Follows up: https://github.com/rapidsai/cudf/pull/19070#discussion_r2196152080
Checklist
- [x] I am familiar with the Contributing Guidelines.
- [x] New or existing tests cover these changes.
- [x] The documentation is up to date with these changes.
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.
Contributors can view more details about this message here.
![copy-pr-bot[bot] avatar](https://avatars.githubusercontent.com/in/354886?v=4 "Published by a pub.dev verified publisher"){kind=small}
Optional suggestion: Maybe we can update the PR title to something like "Use a strong type to indicate UDF source type instead of a boolean"
@lamarrr Thanks for making the java changes as well. We will need to update this test as well: https://github.com/rapidsai/cudf/blob/branch-25.08/java/src/test/java/ai/rapids/cudf/ColumnVectorTest.java#L93-L94.
If this is a breaking change for features released prior to 25.08, we might need to have a deprecation period.
@bdice What solution are you suggesting?
If this is a breaking change for features released prior to 25.08, we might need to have a deprecation period.
@bdice What solution are you suggesting?
That means instead of removing the old APIs, let's just mark them as "deprecated", keep them but alias to the new ones. By doing so, there will not be breaking change for this release. Then, make a new PR removing the old APIs in the next release.
@lamarrr See libcudf developer docs on deprecation: https://github.com/rapidsai/cudf/blob/branch-25.08/cpp/doxygen/developer_guide/DEVELOPER_GUIDE.md#deprecating-and-removing-code
That means instead of removing the old APIs, let's just mark them as "deprecated", keep them but alias to the new ones. By doing so, there will not be breaking change for this release. Then, make a new PR removing the old APIs in the next release.
@ttnghia will same be done for the Java and Python implementations?
