Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow BT::AnyTypeAllowed as port type and setOuput using BT::Any #894

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

robin-mueller
Copy link
Contributor

@robin-mueller robin-mueller commented Dec 10, 2024

This pull request enables to use BT::AnyTypeAllowed when specifying the type of a port, basically meaning that this port has no static type and the node will determine the type of the variable dynamically.

See #893

@robin-mueller robin-mueller changed the title Fix #893 Allow BT::AnyTypeAllowed as port type and setOuput using BT::Any Dec 10, 2024
@facontidavide
Copy link
Collaborator

thanks for the suggestion. I wonder how this should be documented in the tutorials.

What will it be the expected difference when usinf Any or AnyTypeAllowed?

@robin-mueller
Copy link
Contributor Author

robin-mueller commented Dec 13, 2024

I also find it quite difficult to comprehensibly document the feature of allowing dynamically evaluated port types with the current implementation. My suggestion is more of a workaround to at least not break the scripting language when trying to do that. As I said, it would be more intuitive, if there was a single type that should be specified when declaring the port and when calling setOuput.

What was the initial intention behind allowing BT::Any in setOuput? Maybe we only allow BT::AnyTypeAllowed beside the common types when declaring a port. To me it feels wrong to allow BT::Any if it breaks the scripting language. Then we would have a more concise way of implementing that idiom.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants