You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have Keyword model objects both under robot.running and robot.result and they also have a common base class under robot.model. The running side Keyword represent keyword calls like
Log Hello, world!
${x} = Keyword
that consists of only keyword name, argument and possible assignment. At this point the keyword to actually run hasn't been determined so there's no knowledge about its documentation, possible child keywords, and other such info. On the result side Keyword represents an executed keyword and has much more information like documentation, execution times and child keywords.
At the moment our robot.running.Keyword has doc, tags, timeout and teardown attributes that aren't actually used for anything. I noticed them when prototyping to_json functionality as part of #3902. It makes no sense to serialize these unused attributes to JSON, or to load them from JSON, and I believe it's best to remove them altogether.
These attributes should also be removed from the robot.model.Keyword base class and moved fully to robot.running.Keyword. Documentation needs to also be enhanced to make it explicit that on the running side Keyword represents a keyword call and on the result side it represents an executed keyword. In a retrospect the running side object perhaps should be called KeywordCall, but changing that would be too badly backwards incompatible change (it would break all visitors) that it makes no sense.
Also removing these attributes is a backwards incompatible change because someone may have programmatically created running side Keyword objects with them or someone may inspect them using visitors or otherwise. Backwards incompatible changes aren't great in a non-major release, but because these attributes aren't used for anything, it's unlikely users actually set or access them either. Such a usage could be considered a bug and should be fixed anyway. If we do the change early in RF 6.1 development cycle, users have a possibility to test preview releases and we can revert the change if needed. In that case these attributes would nevertheless be removed in RF 7.0.
The text was updated successfully, but these errors were encountered:
We have
Keyword
model objects both underrobot.running
androbot.result
and they also have a common base class underrobot.model
. The running sideKeyword
represent keyword calls likethat consists of only keyword name, argument and possible assignment. At this point the keyword to actually run hasn't been determined so there's no knowledge about its documentation, possible child keywords, and other such info. On the result side
Keyword
represents an executed keyword and has much more information like documentation, execution times and child keywords.At the moment our
robot.running.Keyword
hasdoc
,tags
,timeout
andteardown
attributes that aren't actually used for anything. I noticed them when prototypingto_json
functionality as part of #3902. It makes no sense to serialize these unused attributes to JSON, or to load them from JSON, and I believe it's best to remove them altogether.These attributes should also be removed from the
robot.model.Keyword
base class and moved fully torobot.running.Keyword
. Documentation needs to also be enhanced to make it explicit that on the running sideKeyword
represents a keyword call and on the result side it represents an executed keyword. In a retrospect the running side object perhaps should be calledKeywordCall
, but changing that would be too badly backwards incompatible change (it would break all visitors) that it makes no sense.Also removing these attributes is a backwards incompatible change because someone may have programmatically created running side
Keyword
objects with them or someone may inspect them using visitors or otherwise. Backwards incompatible changes aren't great in a non-major release, but because these attributes aren't used for anything, it's unlikely users actually set or access them either. Such a usage could be considered a bug and should be fixed anyway. If we do the change early in RF 6.1 development cycle, users have a possibility to test preview releases and we can revert the change if needed. In that case these attributes would nevertheless be removed in RF 7.0.The text was updated successfully, but these errors were encountered: