Open kirsle opened 7 years ago
Any work on updated versions of Rivescript? We depend on this for our chatbots we're building at my work place and Rivescript has been a huge in making the chatbot easy for others to get the chatbot to say and do different things without having to be a programmer.
I'm still maintaining this module along with some of the other implementations of RiveScript (Python, JS and Perl) but the RiveScript language itself isn't really getting any new features added as of late.
If you find bugs in the Go version feel free to report them or send a pull request. Some new features may be accepted too -- but see the RiveScript Goals and Scope. I basically want the RiveScript language itself to behave more-or-less the same on all 5 implementations, but added features that don't break the cross-language compatibility can be added to one library or another.
For example, the Python and JavaScript versions got features to store user variables directly in Redis or other DB back-end, at different times in their lifecycles, and these didn't have to do directly with the RiveScript language itself so didn't need feature parity across programming languages.
Sounds good. Thanks for your work on this. The key thing is that in the chatbot I've developed I can then hand it off and my team can extend that chatbot with rivescript. So we've got people with little to no programming skills spinning up chatbots to perform various functions.
This is a blanket ticket for going through the codebase and doing general cleanup and API fixes to make the code more idiomatic from a Go point of view.
Examples:
error
objects to communicate failure conditions rather than relying on "magic" return values like empty strings.func ClearUservars(username string) error
could return an error when the user had no vars to clear.func CurrentUser() (string, error)
where it gives an error when called outside of an object macro context, rather than what it currently does by returning an empty string -- this isn't idiomatic Go.<get>
"GetUservar()
should follow Go idioms and return"", error
in case of errors rather than"undefined", error
<get>
types of tags would handle the mapping of""
to"undefined"
for their own use.[x] Find a way to make the constructor config object easier to get and use. It's stupid to need to import
aichaos/rivescript-go/config
to get theconfig.Config{}
type for initializing RiveScript. The config type should be available directly from the parent package.This might require refactoring to make the parent package include more logic for config handling rather than just proxying all methods through to the
/src
versions, but that's probably a good thing anyway. The/src
package is private use only and I already spelled out in its docs that its API can be changed at any time without notice.