thisisdhaas
commented
9 years ago This looks good--merge away.
I think it's a bit harder to make this work for task types, since task context is often nested and has heterogeneous types (e.g., sentiment analysis requires a string, deduplication needs a list of lists). Pretty hard to capture with a generic map.
It also doesn't seem that bad to have to update the Scala code. The scala is essentially a client library for the python server: when the server updates its APIs, the client library also needs to be updated.
This PR suggests one possible way to deal with different crowds without different subclasses extended from CrowdLabelGetterParameters.
I'm also wondering if we can deal with different crowd task types in a way similar to this, i.e., not using subclasses. Currently, if a user wants to add a new type of task, they not only need to modify the python code, but also need to add subclasses in the scala code, which is not very convenient I think.