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

Make reactions.go and other similar methods interrupt action block execution #82

Open
nikvoloshin opened this issue Oct 14, 2020 · 2 comments

Comments

@nikvoloshin
Copy link
Contributor

For now, the user must ensure by himself that there is no code after reactions.go, otherwise, this code will be executed, moreover, it will be executed before toState action block. Although it breaks reactions.go semantic and documentation that states the following: "Changes the state of scenario and executes it's action block immediately".
For example, such a code:

action {
	reactions.go("somewhere")
	reactions.say("Shouldn't get to this")
}

will produce the output: Shouldn't get to this.

I think, that it's not the desired behaviour and we should think about, for example, making reactions.go and other go-like methods return kotlin.Nothing. It will make user and compiler sure, that current action block execution interrupts after reactions.go

@morfeusys
Copy link
Contributor

@nikvoloshin I'm not sure it should be implemented this way. Go-like functions are dialogue-related and shouldn't declare the way user should write their action's code. Moreover, there could be some cases when the user could place go before the main action's logic.
I suppose it could be suitable to prevent other reactions to be executed once go was invoked, but not to interrupt entire action block at all.

@nikvoloshin
Copy link
Contributor Author

@morfeusys Thanks for your feedback!
Well, it's about the semantic of go. We definitely can stay with the current implementation, but then I think, we should properly describe its semantic by rewriting documentation and/or changing go (and others) name (e.g. setNextState, afterActionGo, goNext, etc.). Because the current name and documentation may, and will, confuse users.

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

No branches or pull requests

2 participants