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 the API more idiomatic as a Go library #17

Open
3 tasks done
kirsle opened this issue Feb 1, 2017 · 3 comments
Open
3 tasks done

Make the API more idiomatic as a Go library #17

kirsle opened this issue Feb 1, 2017 · 3 comments

Comments

@kirsle
Copy link
Member

kirsle commented Feb 1, 2017

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:

  • More functions should return error objects to communicate failure conditions rather than relying on "magic" return values like empty strings.

    • e.g. func ClearUservars(username string) error could return an error when the user had no vars to clear.
    • e.g. 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.
  • User variable getter functions should be refactored to make more sense for "API context" vs. "internal use w/ <get>"

    • The public API functions like GetUservar() should follow Go idioms and return "", error in case of errors rather than "undefined", error
    • The internal use of the functions for the <get> types of tags would handle the mapping of "" to "undefined" for their own use.
  • 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 the config.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.

    bot := rivescript.New(rivescript.BasicConfig())
@rmasci
Copy link

rmasci commented Feb 5, 2020

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.

@kirsle
Copy link
Member Author

kirsle commented Feb 6, 2020

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.

@rmasci
Copy link

rmasci commented Feb 6, 2020

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.

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

No branches or pull requests

2 participants