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
Hi there! I've been looking at a few embeddable languages in Go and I quite like your project. I was wondering what you think about the use of Generics in the library, and getting rid of the empty Evaluator struct? I've got a branch with the code changes if you'd like to take a gander (I'm not going to bug you with a PR to review).
It breaks having nil be something you can evaluate/return on its own, so I had to delete/exclude some of those tests, and it necessitates a /v2 release of the codebase because it would break backwards compatibility. In exchange for those tradeoffs, though, you get to avoid a lot of the if val, ok := interfaceVar.(string); ok { stuff you might otherwise have to endure
The text was updated successfully, but these errors were encountered:
I'd need to take a closer look at a generic approach, but on first glance, I don't think the advantages outweigh the disadvantages.
It would be a breaking change that requires a v2, only for putting the type assertion inside the evaluator itself.
It would also force everyone to update to go1.18+ (which isn't too bad, but still).
I don't plan on breaking compatibility for adding generics.
Unless it adds additional benefits outside saving a type-cast (which could also be done by a simple wrapper), I don't think it is worth the cost.
Hi there! I've been looking at a few embeddable languages in Go and I quite like your project. I was wondering what you think about the use of Generics in the library, and getting rid of the empty Evaluator struct? I've got a branch with the code changes if you'd like to take a gander (I'm not going to bug you with a PR to review).
It breaks having
nil
be something you can evaluate/return on its own, so I had to delete/exclude some of those tests, and it necessitates a/v2
release of the codebase because it would break backwards compatibility. In exchange for those tradeoffs, though, you get to avoid a lot of theif val, ok := interfaceVar.(string); ok {
stuff you might otherwise have to endureThe text was updated successfully, but these errors were encountered: