GitHub user Yicong-Huang added a comment to the discussion: Feature Proposal:
Extend Python UDF operators to allow users to modify parameters without editing
the code
I am afraid I would give a -1 for the current proposal.
I want to repeat a previously mentioned idea/concept before we dive into
support this feature. In my mind, UDFs are designed for developers. The user of
UDF has to understand the code, and because of this, changing a value/parameter
in the editor is the easiest method for those users. For non-coding users who
would like to modify a value is not a recommended user scenario. Instead, the
owner/developer of the UDF should go through a "publish" process to convert a
UDF to a builtin operator. The new builtin operator should have predefined
fields on the property panel, so that non-coding users can modify on the
property panel. The property panel is the defined interface where the developer
to control what parameters for a non-coding user can/should modify. Our
existing plotting operators are great examples of Python UDFs converted to
builtin operators. They are easy to use and can only be modified in the defined
way. (i.e., a non-coding user cannot arbitrarily change an unwanted field mi
stakenly).
With this understanding, I am a bit against the proposed idea in this
discussion. There are a few reasons:
1. The proposed idea requires non-coding users to define parameters in an
upstream operator and pass it to UDF. This is a bit hard to understand and
counter intuitive: why am I editing a property of one operator on another
operator?
2. This adds additional complexity:
- it would be hard for a developer to write: The UDF code would be more
complex as it needs to add handling logic for `tuple['parameters']` column.
- it would be hard for a developer to maintain. suppose as a developer of
UDF, I need to add/remove a parameter, I would need to modify multiple places.
- it would be hard for a user to use/debug: suppose a UDF does not work as
expected and there are a few possible operators passing parameters into this
UDF. It would be hard for me as a user to trace the change.
3. There is no abstract/interface guarantee. Anyone (developer or user) would
be able to change code/parameter, and users may make mistakes when changing the
code/parameter. Alternatively, if developers can "publish as builtin operator",
they can define the parameters and range/scope of the parameters. And the user
can only change the defined parameters in a controlled range, so less mistakes.
GitHub link:
https://github.com/apache/texera/discussions/4154#discussioncomment-15511624
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
