Skip to content
This repository was archived by the owner on May 30, 2024. It is now read-only.

Conversation

@pkaeding
Copy link
Contributor

No description provided.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This expands the API in a backward-compatible way, so the next version will be 0.9.0.

Also, we have a bunch of overloaded custom methods, to set values of different types, but you can only set a list of strings (because of type erasure, we can't have a method named custom that takes a list of numbers).

So, should we encode the type in the method names (eg, customNumber(String, Number) / customNumbers(String, List<Number>), customBool(String, Boolean) / customBools(String, List<Boolean>), customString(String, String) / customStrings(String, List<String>))? Or another idea?

@apucacao
Copy link
Contributor

lgtm

pkaeding added a commit that referenced this pull request Jun 30, 2015
fixed logic for rules written using non-string values
@pkaeding pkaeding merged commit c7b8ef4 into master Jun 30, 2015
@pkaeding pkaeding deleted the pk/fix-non-string-rules branch June 30, 2015 21:59
pkaeding added a commit that referenced this pull request Sep 25, 2015
fixed logic for rules written using non-string values
pkaeding added a commit that referenced this pull request Dec 21, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants